This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Solaris 7 build fails for current cvs resolved, but static/dyn. lib problems


On Fri, 10 Mar 2000, you wrote:
> Plattform: Ultra10, Solaris 7, gcc 2.95.2, gnu make 3.78.1, libstdc++ cvs
> head version
> 
> Hi there,
> 
> initialy i called configure --prefix=/usr (as used on linux) for the
> current libstdc++ cvs head version.
> changing it to --prefix=/usr/local resolved the problem and i got the
> library build.
> 
> Now I have some trouble to successfully link my app and create a working
> executable.
> 
> On linux there were no problems, I used LD_FLAGS=-static and CFLAGS=-Wall
> -g.
> 
> My app is using some socket functions so I set on Solaris
> LIBS=-lm -lsocket -lnsl -lstdc++ -lc
> 
> But during link stage I get unreslved externales for dl_close() etc.. stuff
> from the dynamic linker on solaris
> which are needed by /usr/lib/libnsl.a(netdir.o)
> 
> If I link without LD_FLAG=-static the build completes but the executable
> crashes right from the start with
> 
> (gdb) run
> Starting program: /space/bruno/prj/GuckySys/src/emi/./emi
> 
> Program received signal SIGSEGV, Segmentation fault.
> basic_ios<char, char_traits<char> >::rdstate (this=0x0)
>     at /usr/local/include/g++-v3/bits/basic_ios.h:96
> 96            { return _M_streambuf_state; }

Ya, I had the exact same problem under Solaris 6.  It seems that the libstdc++
libraries have made assumptions about the order of static constructors which
are dependant on the tools used (ie. non-portable assumptions).  While I
couldn't figure out how to remedy the assumptions, I did come up with two
solutions that worked.

(1) You can't use -static because the nsl library requires dynamic linking
only.  What you can do is link the libstdc++.a library explicitly, ie.

	LIBS=/usr/local/lib/libstdc++.a -lsocket -lnsl

This worked, but resulted in larger binary files because of the static linking.

(2) Obtain and install the GNU binutils and rebuild gcc with --with-gnu-ld. 
Make sure the GNU ld is in your path when you link.  It seems the static
constructors are instantiated in the correct dependency order when I build with
the GNU linker instead of the native Solaris one.


Stephen M. Webb

stephen@bregmasoft.com
http://www.interlog.com/~bregma

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]