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
