Discussion:
beide and static libs
(too old to reply)
Jøhnny Fävòrítê (it means "halo, then resonate")
2004-02-29 23:46:47 UTC
Permalink
well, i got lucky last time, so i'll press my luck ...

i am working for years on an app which is getting abso-redicu-huge.
like 70mb, when built with debug info. it takes forever to link, and
forever and a half to load into bdb. i want to break it up into static
libs, so i can build most of them without debug info most of the time.

alas, it appears that beide has some sort of bug that doesn't allow it
to link apps against static libs. i thought it was the .a file i'd just
built, so i tried building this tiny little app, and linking it against
libpng.a, which is static:

#include <png.h>

int main(void)
{
png_struct png;
const char* ptr = NULL;
png_chunk_warning(&png, ptr);
return 0;
}

that doesn't work either. i get:

Error : /Liquid/Project/LibTest/(Objects.LibApp)/LibApp.o: In function
`main': /Liquid/Project/LibTest/(Objects.LibApp)/LibApp.o(.text+0x20):
undefined reference to `png_chunk_warning' Error : collect2: ld
returned 1 exit status

i can make this work fine, if i build the app with a makefile, rather
than with beide.

i tried everything i could think of, like putting "-lpng" and "-Xlinker
lpng" in the "More Linker Options" box, to no avail.

if anybody knows the magic incantation, i'd love to hear about it. i'd
sure hate to think this was the end of the road for me and beide.
Alexander G. M. Smith
2004-03-01 12:37:15 UTC
Permalink
Post by Jøhnny Fävòrítê (it means "halo, then resonate")
alas, it appears that beide has some sort of bug that doesn't allow it
to link apps against static libs. i thought it was the .a file i'd just
built, so i tried building this tiny little app, and linking it against
[...]
Error : /Liquid/Project/LibTest/(Objects.LibApp)/LibApp.o: In function
undefined reference to `png_chunk_warning' Error : collect2: ld
returned 1 exit status
I use BeIDE with the zlib static library and it works fine. I include the
x86/libz.a file in the list of input files (in a section I gratuitously
called "Libraries", along with x86/libbe.so etc).

Presumably the header file you are using also works in C++? For a library
like that the "C" calling convention would likely be used, and thus all the
function calls need to be wrapped with the usual extern "C" { stuff }
declaration. Most headers do that for you, with an #ifdef __cplusplus so
they work with both C and C++.

- Alex
Jøhnny Fävòrítê (it means "halo, then resonate")
2004-03-01 13:48:37 UTC
Permalink
thanks for taking a shot.
Post by Alexander G. M. Smith
I use BeIDE with the zlib static library and it works fine. I include
the x86/libz.a file in the list of input files (in a section I
gratuitously called "Libraries", along with x86/libbe.so etc).
as stated elsewhere, my problem was that gcc is sensitive to the order
of .a and .o files it gets on the link command line. i verified this
with extensive script file experiments.

to satisfy my curiousity, is your "Libraries" group before or after your
project's source files?
Alexander G. M. Smith
2004-03-02 13:47:10 UTC
Permalink
Post by Jøhnny Fävòrítê (it means "halo, then resonate")
to satisfy my curiousity, is your "Libraries" group before or after your
project's source files?
It's at the end of the list, guess that's why it works!

- Alex

Jøhnny Fävòrítê (it means "halo, then resonate")
2004-03-01 12:56:44 UTC
Permalink
Post by Jøhnny Fävòrítê (it means "halo, then resonate")
alas, it appears that beide has some sort of bug that doesn't allow it
to link apps against static libs.
answering my own question ...

it looks like gcc is sensitive to the order of object files and static
libs it gets on the link line. if it sees a static .a before the .o
object that depends on it, it goes "heck, i don't need any of those
functions," and throws away everything in the .a without including it.
then it gets to the end and notices it's got unresolved externals and
goes "ooops." apparently this doesn't apply to .so dynamic libs, as it
probably adds references to them no matter what, without checking to see
if any of those functions are needed.

beide doesn't take this into account. it seems to present the .o and .a
files to the linker in whatever order they appear in the project.
adding extra args to the linker command line doesn't help, because they
go at the end and don't affect object link order.

the workaround is to put any .a static libs at the bottom of the beide
project. yukky, but seems to work, in my case at least.
Loading...