Re: libtool for C++
Steve: It is NOT up-to-date for CVS HEAD and alpha versions of Libtool. Robert "Steve M. Robbins" wrote: > > Hello, > > The libtool manual suggests strongly that one not use it > for C++ libraries. > > Is this section of the document up-to-date with the stable > release of libtool? CVS libtool? > > from libtool manual - > > 11.1 Writing libraries for C++ > > Creating libraries of C++ code should be a fairly straightforward > process, because its object files differ from C ones in only three > ways: > > 1.Because of name mangling, C++ libraries are only usable by > the C++ compiler that created them. This decision was made > by the designers of C++ in order to protect users from > conflicting implementations of features such as constructors, > exception handling, and RTTI. > > 2.On some systems, the C++ compiler must take special actions > for the dynamic linker to run dynamic (i.e., run-time) > initializers. This means that we should not call `ld' directly to > link such libraries, and we should use the C++ compiler > instead. > > 3.C++ compilers will link some Standard C++ library in by > default, but libtool does not know which are these libraries, so > it cannot even run the inter-library dependence analyzer to > check how to link it in. Therefore, running `ld' to link a C++ > program or library is deemed to fail. However, running the > C++ compiler directly may lead to problems related with > inter-library dependencies. > > The conclusion is that libtool is not ready for general use for C++ > libraries. You should avoid any global or static variable > initializations that would cause an "initializer element is not > constant" error if you compiled them with a standard C compiler. > > There are other ways of working around this problem, but they are > beyond the scope of this manual. > > Furthermore, you'd better find out, at configure time, what are the > C++ Standard libraries that the C++ compiler will link in by > default, and explicitly list them in the link command line. > Hopefully, in the future, libtool will be able to do this job by itself. > > - > > From this section, it is unclear whether libtool uses the C++ > compiler or "ld" to do the linking. If the former, then it sounds > like the remaining hurdle (from #3) is to discover with which > standard libraries the compiler is linking. Is this accurate? > > -Steve > > -- > by Rocket to the Moon, > by Airplane to the Rocket, > by Taxi to the Airport, > by Frontdoor to the Taxi, > by throwing back the blanket and laying down the legs ... > - They Might Be Giants > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool 1.4 branch and IRIX 6.x
When using CC=cc on IRIX 6.x, ld is used to create shared libraries. However: hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir' This causes -Wl,-rpath to be passed to ld. Unfortunately, ld recognizes -rpath but not -Wl so we get errors like: (null): WARNING 1 : Unknown option: Wl,-rpath (ignored). So, the solution would seem to be the patch below. However, after applying this patch and running 'make check', build-relink2 dies at the end: if test "$shlibpath_overrides_runpath" != yes; then rm -f $objdir/lt-depdemo || exit 1 cp $objdir/depdemo $objdir/lt-depdemo || exit 1 echo "running ../depdemo/depdemo with installed libl3.la" if ./depdemo; then echo "Worked, as expected" else echo "shlibpath_overrides_runpath should be set to yes" status=1 fi rm -f $objdir/lt-depdemo fi For IRIX 6.x: shlibpath_overrides_runpath = no because, according to rld(5): The search path for shared objects is as follows: 1. The path of the shared object, if specified in the liblist. That is, if the soname of the shared object has a path. For more information, see the ld(1) man page. 2. DT_RPATH, if it is defined in the executable or any DSO that rld has opened. 3. Use LD_LIBRARY_PATH, if it is defined in the environment at the time of execution. 4. The default library search path. However: $ elfdump -L depdemo/.libs/depdemo | grep RPATH /opt/build/libtool-1.4.2/depdemo/l1/.libs:/opt/build/libtool-1.4.2/tests/_inst/lib:/opt/build/libtool-1.4.2/depdemo/l2/.libs:/opt/build/libtool-1.4.2/depdemo/l3/.libs:/opt/build/libtool-1.4.2/tests/_inst/lib/extra Both /opt/build/libtool-1.4.2/depdemo/l3/.libs and /opt/build/libtool-1.4.2/tests/_inst/lib/extra contain libl3.so.1.0 so the version in /opt/build/libtool-1.4.2/depdemo/l3/.libs is selected as it is first in the search path. However, before the shlibpath_overrides_runpath test, we broke libl3.so.1.0 earlier in build-relink2 so libl3.so.1.0 does not contain var_l3. This results in: $ .libs/depdemo 174396:./depdemo: rld: Error: unresolvable symbol in /opt/build/libtool-1.4.2/tests/_inst/lib/libl4.so.1: var_l3 174396:./depdemo: rld: Fatal Error: this executable has unresolvable symbols causing the test to fail. So, is build-relink2.test broken? -- albert chin ([EMAIL PROTECTED]) -- snip snip Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/libtool.m4,v retrieving revision 1.166.2.32 diff -u -3 -p -r1.166.2.32 libtool.m4 --- libtool.m4 15 Nov 2001 01:22:58 - 1.166.2.32 +++ libtool.m4 28 Jan 2002 17:37:35 - @@ -1636,10 +1636,11 @@ else irix5* | irix6* | nonstopux*) if test "$GCC" = yes; then archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib' + hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir' else archive_cmds='$LD -shared $libobjs $deplibs $linker_flags -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib' + hardcode_libdir_flag_spec='-rpath $libdir' fi -hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir' hardcode_libdir_separator=: link_all_deplibs=yes ;; ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool for C++
On Mon, 28 Jan 2002, Robert Boehne wrote: > It is NOT up-to-date for CVS HEAD and alpha versions of Libtool. I recall that this documentation was updated in the muti-lingual branch. Perhaps it was not merged over as it should have been? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
HEY YOU .don't miss this
ENTER CYBER EROTICA LOOK FOR THE LINK scroll down and enter http://www.freepornoserver.com/web/hardcore02/sirjive/index.htm IT'S HIDDEN AND IT SAYS JOIN FOR FREE it's totally free come join. http://www.freepornoserver.com/web/hardcore02/sirjive/index.htm ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool