Building projects on i386-pc-solaris2.8
Hey, I rewrote a project's build process to use autotools and libtool. Everything builds fine but the binary seg faults at run time(in i386 solaris2.8 ). Does anyone know of any issues or AC_ AM_ macros that are absolutely required to build shared objects and dynamicly linked binaries(when porting to intel solaris2.8)? The binary builds and runs fine on Redhat 7.2. However when I build the target in i386-pc-solaris2.8 it segment faults when I run it. If I build it with out libtool and autotools it is fine. My make set up builds a few binarys that link to existing libs as well as some of the shared objects and libraries built with in the project. Not sure if the info I have included is helpful or not. Thanks in advance. i386-pc-solaris2.8 gcc version 2.95.3 20010315 (release) libtool 1.4.2 Al ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building projects on i386-pc-solaris2.8
> >On Thu, Jan 31, 2002 at 02:04:27PM -0500, Allan McIntosh wrote: >> I rewrote a project's build process to use autotools and libtool. >> Everything builds fine but the binary seg faults at run time(in i386 >> solaris2.8 ). Does anyone know of any issues or AC_ AM_ macros that are >> absolutely required to build shared objects and dynamicly linked >> binaries(when porting to intel solaris2.8)? >> >> The binary builds and runs fine on Redhat 7.2. However when I build the >> target in i386-pc-solaris2.8 it segment faults when I run it. If I build >> it with out libtool and autotools it is fine. > >Even if you --disable-shared? Then I get ld errors: Undefined first referenced symbol in file url_open /usr/local/lib/libltapi12.a(sgmlfiles.o) Fprintf /usr/local/lib/libltapi12.a(sgmllib.o) strcasecmp8 /usr/local/lib/libltapi12.a(sgmlparse.o) url_merge /usr/local/lib/libltapi12.a(dtd.o) Toupper /usr/local/lib/libltapi12.a(query.o) LTSTD_set_error_handler /usr/local/lib/libltapi12.a(sgmllib.o) LTSTDError /usr/local/lib/libltapi12.a(sgmllib.o) CharacterEncodingName /usr/local/lib/libltapi12.a(sgmlfiles.o) ------ Allan McIntosh, Software Designer http://www.atreus-systems.com Phone: (613) 233-1741, (800) 764-5514 Ext 217 -- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building projects on i386-pc-solaris2.8
On the solaris machine there are 3 linkers: /opt/sfw/bin/ld /usr/ucb/ld /usr/ccs/bin/ld If I do a `which ld` it returns /opt/sfw/bin/ld /opt/sfw/bin/c++ [amcintosh@amcintosh 11:57:49 src]# ls -la /opt/sfw/bin/c++ -r-xr-xr-x 2 root bin74868 May 21 2001 /opt/sfw/bin/c++ [amcintosh@amcintosh 11:58:06 src]# /opt/sfw/bin/c++ -v Reading specs from /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.3/specs gcc version 2.95.3 20010315 (release) Then if I simply compile from the command line: c++ -o libagent.so -fPIC -L/usr/local/lib -G Agent.o AgentObject.o AgentObjectLinux.o AgentObjectFactory.o Vector.o Attribute.o SharedLibrary.o SharedLibraryMgr.o Storage.o StorageFile.o AttributeContainer.o ObjectContainer.o AgentObjectVersion.o ODParser.o XMLParser.o XMLItem.o md5.o -lcrypt -ldl -lltapi12 -lltstd12 -lz The library builds fine. But if I use libtool to build it. I get many undefined symbols. The libtool script has: LD="/usr/ccs/bin/ld" If i change LD="/opt/sfw/bin/ld" is that enough? Or must I define LD_RUN_PATH and recompile libtool? any suggestions? Thanks in advance. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
How about this?
I don't believe my question is bug related. I am just seeking advice, having struggled way to long with this. In my hand written Makefile I have the following: g++ -MD -fPIC -c source1.c g++ -MD -fPIC -c source2.c g++ -MD -fPIC -c source3.c and so on up untill: g++ -o libagent.so -fPIC -L/usr/local/lib -G Agent.o AgentObject.o AgentObjectLinux.o AgentObjectFactory.o Vector.o Attribute.o SharedLibrary.o SharedLibraryMgr.o Storage.o StorageFile.o AttributeContainer.o ObjectContainer.o AgentObjectVersion.o ODParser.o XMLParser.o XMLItem.o md5.o -lcrypt -ldl -lltapi12 -lltstd12 -lz g++ -o g++ -o agent -fPIC AGENT_grammar.o AGENT_tokens.o main.o -lfl -lsocket -lnsl -lagent Providing me with libagent.so and agent. --- Using Autotools and libtool do the following: Makefile.am: lib_LTLIBRARIES = libagent.la libagent_la_SOURCES = Agent.cc AgentObject.cc AgentObjectLinux.cc AgentObjectFactory.cc\ Vector.cc Attribute.cc SharedLibrary.cc SharedLibraryMgr.cc\ Storage.cc StorageFile.cc AttributeContainer.cc ObjectContainer.cc AgentObjectVersion.cc\ ODParser.cc XMLParser.cc XMLItem.cc md5.cc libagent_la_LDFLAGS = -L/usr/local/lib libagent_la_DEPENDENCIES = libagent_la_LIBADD = compile output: source='AgentObject.cc' object='AgentObject.lo' libtool=yes \ depfile='.deps/AgentObject.Plo' tmpdepfile='.deps/AgentObject.TPlo' \ depmode=gcc /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I/usr/local/include -g -O2 -c -o AgentObject.lo `test -f AgentObject.cc || echo './'`AgentObject.cc rm -f .libs/AgentObject.lo g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I/usr/local/include -g -O2 -c AgentObject.cc -Wp,-MD,.deps/AgentObject.TPlo -fPIC -DPIC -o .libs/AgentObject.lo g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../src -I/usr/local/include -g -O2 -c AgentObject.cc -Wp,-MD,.deps/AgentObject.TPlo -o AgentObject.o >/dev/null 2>&1 mv -f .libs/AgentObject.lo AgentObject.lo All the way down to: /bin/sh ../libtool --mode=link g++ -g -O2 -o libagent.la -rpath /home/agent/lib -L/usr/local/lib Agent.lo AgentObject.lo AgentObjectLinux.lo AgentObjectFactory.lo Vector.lo Attribute.lo SharedLibrary.lo SharedLibraryMgr.lo Storage.lo StorageFile.lo AttributeContainer.lo ObjectContainer.lo AgentObjectVersion.lo ODParser.lo XMLParser.lo XMLItem.lo md5.lo -lnsl -lz -lltstd12 -lltapi12 -lfl -ldl -lcrypt -lsocket rm -fr .libs/libagent.la .libs/libagent.* .libs/libagent.* /usr/ccs/bin/ld -G -h libagent.so.0 -o .libs/libagent.so.0.0.0 Agent.lo AgentObject.lo AgentObjectLinux.lo AgentObjectFactory.lo Vector.lo Attribute.lo SharedLibrary.lo SharedLibraryMgr.lo Storage.lo StorageFile.lo AttributeContainer.lo ObjectContainer.lo AgentObjectVersion.lo ODParser.lo XMLParser.lo XMLItem.lo md5.lo -L/usr/local/lib -lnsl -lz -lltstd12 -lltapi12 -lfl -ldl -lcrypt -lsocket -lc (cd .libs && rm -f libagent.so.0 && ln -s libagent.so.0.0.0 libagent.so.0) (cd .libs && rm -f libagent.so && ln -s libagent.so.0.0.0 libagent.so) ar cru .libs/libagent.a Agent.o AgentObject.o AgentObjectLinux.o AgentObjectFactory.o Vector.o Attribute.o SharedLibrary.o SharedLibraryMgr.o Storage.o StorageFile.o AttributeContainer.o ObjectContainer.o AgentObjectVersion.o ODParser.o XMLParser.o XMLItem.o md5.o ranlib .libs/libagent.a creating libagent.la (cd .libs && rm -f libagent.la && ln -s ../libagent.la libagent.la) The lib tool version segfaults on start up. Therefore I can not debug it. What exactly is the difference? I am on the verge of removing the libtool portion of the build process on i386-pc-solaris2.8. Thanks again in advance. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How about this?
> >ld doesn't work for linking c++, so you need to have an >alpha version (or CVS HEAD) of Libtool to do this. > > Robert, Thank you, For now I will not spend any more time on this. Arhhh. Al -- Allan McIntosh, Software Designer http://www.atreus-systems.com Phone: (613) 233-1741, (800) 764-5514 Ext 217 -- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
