GCC 3.2.1 and static linking
Roger
I've looked back thru this group for previous examples of same
question, but they all seem to refer to earlier versions of GCC. I've
tried a few things (-static, -Bstatic) but without much success. I've
checked the relevant man page for 3.2.1 and static linking doesn't
appear to get a mention (it does in the 2.95.2 man page). I'm working
on Solaris. One previous answer suggested rebuilding GCC with only
static libraries or renaming the offending .so files to force a static
link. Any help would be appreciated.
llewelly
> Can anyone tell me how to force gcc to link libstdc++ statically?
> I've looked back thru this group for previous examples of same
> question, but they all seem to refer to earlier versions of GCC. I've
> tried a few things (-static, -Bstatic) but without much success.
When you use -static, what does ldd tell you about the resulting
executable? On freebsd, using gcc 3.2.1, I get this:
$ cat hello.cc
#include<iostream>
#include<ostream>
using namespace std;
int main()
{
cout << "hello world" << endl;
}
$ g++ -static -o hello hello.cc
$ ldd hello
ldd: hello: not a dynamic executable
> I've
> checked the relevant man page for 3.2.1 and static linking doesn't
> appear to get a mention (it does in the 2.95.2 man page).
See:
http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Link-Options.html#Link%20Options
and search for 'static' .
> I'm working
> on Solaris. One previous answer suggested rebuilding GCC with only
> static libraries or renaming the offending .so files to force a static
> link.
I would advise against renaming your .so files. I don't think it will
result in a static link, and it will break anything you have
already built and installed dynamicly linked to libstdc++.so .
Paul Pluzhnikov
> Can anyone tell me how to force gcc to link libstdc++ statically?
g++ .... -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic ...
> I've
> tried a few things (-static, -Bstatic) but without much success.
The '-static' forces all libraries to be static, which is often
undesirable.
The '-Bxxx' means something totally different to gcc. The command
above passes -B options directly to the linker, bypassing g++
interpretation.
Cheers,
--
In order to understand recursion you must first understand recursion.
Roger
> g++ .... -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic ...
>
"USER_LIBS=-L/source/sp-1.3.4new/lib -L/tool/tiff/lib -lsp -ltiff
-ljpeg -lpthread -lgoo -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic"
This is very frustrating. I've tried variuos combinations and I still
get the message:
ld.so.1: ./vtool: fatal: libstdc++.so.5: open failed: No such file or
directory
when I run the app (vtool).
> The '-static' forces all libraries to be static, which is often
> undesirable.
Yes, if I use -static the linker cannot find library pthread. I
checked /usr/lib and it looks like we only have libpthread.so -
perhaps the reason why the linker gags on -lpthread? I've tried
pointing the linker at pthread with -L /usr/lib but this makes no
difference.
I'm very grateful for your help: any more ideas please?
Paul Pluzhnikov
> Paul Pluzhnikov <ppluz...@earthlink.net> wrote:
> > g++ .... -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic ...
> >
> The link instruction line looks like this:
> "USER_LIBS=-L/source/sp-1.3.4new/lib -L/tool/tiff/lib -lsp -ltiff
> -ljpeg -lpthread -lgoo -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic"
>
> This is very frustrating. I've tried variuos combinations and I still
> get the message:
> ld.so.1: ./vtool: fatal: libstdc++.so.5: open failed: No such file or
> directory when I run the app (vtool).
Yes, my advice didn't work for me either ;-( and getting it wright
turned out suprizingly difficult (I quite understand your
frustration).
Here is a solution that works (at least it works for me):
ln -s `g++ -print-file-name=libstdc++.a` .
g++ junk.C -L.
rm -f libstdc++.a
Roger
> Here is a solution that works (at least it works for me):
>
> ln -s `g++ -print-file-name=libstdc++.a` .
> g++ junk.C -L.
> rm -f libstdc++.a
>
and was able to link OK to libstdc++.a (hooray..). But now if I unset
LD_LIBRARY_LIB the executable cannot find libgcc_s.so and when I look
I see there is no libgcc_s.a to be found. Looking around on this
group I see I'm not the only one who's had this problem. There was a
suggestion that the required bits and pieces might be found in
libgcc_eh.a - but when I link to this the linker grumbles that -lgcc_s
is not found (but i never mentioned that so why is it asking for it?).
It's looking more like I'm going to have to get the compiler
reconfigured for static linking.
Paul Pluzhnikov
> ... the executable cannot find libgcc_s.so ...
Add '-static-libgcc' to your link line.
Roger
>
thanks for your kind help. I forgot to mention in previous post that
this is one of the things I tried. I get the following output:
Undefined first referenced
symbol in file
dlclose /usr/lib/libc.a(nss_deffinder.o)
dlsym /usr/lib/libc.a(nss_deffinder.o)
dlopen /usr/lib/libc.a(nss_deffinder.o)
ld: fatal: Symbol referencing errors. No output written to vtool
collect2: ld returned 1 exit status
make[1]: *** [vtool] Error 1
The relevant part of the g++ command line is:
"-L/source/gcc-3.2.1/lib -Wl,-Bstatic -lstdc++ -static-libgcc"
Roger
Paul Pluzhnikov
> Undefined first referenced
> symbol in file
> dlclose /usr/lib/libc.a(nss_deffinder.o)
Now you are forcing static libc. Don't do *that* ...
> The relevant part of the g++ command line is:
> "-L/source/gcc-3.2.1/lib -Wl,-Bstatic -lstdc++ -static-libgcc"
This is what causes it ^^^^^^^^^^^^
So, to get your link as you want it:
- remove any -static, -Bstatic, etc. flags, any symbolic links
you've created, and relink.
You should get a successfull, completely dynamic link.
- Now add -static-libgcc and relink. The link should still succeed,
and you will no longer depend on libgcc_s
- Now create libstdc++.a symbolic link and relink again. This should
give you the dependencies you want (I think).
Roger
> Now you are forcing static libc. Don't do *that* ...
well, well, a virtual beer to you mate. Thanks very much. I finally
got it to link statically. Brilliant.
Roger