Re: AIX library creation for dynamic loading
Boehne, Robert wrote on May 24: Any attempt to understand AIX shared libraries should start by reading this: http://www-1.ibm.com/servers/esdd/pdfs/aix_ll.pdf HTH, Robert Robert, Yes, that's very helpful. I now understand the rationale behind the strangeness. Thank you! - Don -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don Anderson[EMAIL PROTECTED] Sleepycat Software Inc. +1-978-287-4781 118 Tower Rd. http://www.sleepycat.com Lincoln, MA 01773 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AIX library creation for dynamic loading
Jeff Trawick wrote on May 24: [EMAIL PROTECTED] (Don Anderson) writes: Hello, I seek your advice on some weirdness I've noticed with AIX 4.3.3. I want to create a shared library for dynamic loading using libtool with the -module option. When the AIX linker (or something in the compiler chain) creates the shared library, it is put into a .a file. That is, it creates libfoo.a, a static archive of one element, which is libfoo.so.0, and that shared object has an SONAME of libfoo.so. Apparently, the linker knows how to link and run against that animal if you just wanted to link. But if you want to dynamically load it (say from java or Tcl), these programs cannot dlopen the .a. So I need to do a post-install step like this: $ ar xv libfoo.a x - libfoo.so.0 $ ln -s libfoo.so.0 libfoo.so This gives me a libfoo.so that I can dlopen directly. A couple of hints: 1) If you want to load a member of an archive on AIX, add the RTLD_MEMBER flag to your normal dlopen() flags. You can then specifylibfoo.a(libfoo.so.0) as the object to load. This would be just the trick, but sadly I can't take advantage of it. We're building a JNI library that must be loaded by an arbitrary Java runtime. That stuff has already been compiled, so we can't mess with the dlopen() flags. 2) As I understand it, libtool doesn't create the non-archive style of shared library on AIX unless it thinks you are using run-time linking (-Wl,-brtl). You may or may not want run-time linking. Now this is interesting. I tried to get it to work for me, without success. This concept looks broken to me (in libtool 1.4.2 and 1.4d, also in the CVS tree). libtool.m4 contains some stuff in the AIX portion that is dependent on whether LDFLAGS contains -Wl,-brtl or -brtl. But it's written so that it evaluates LDFLAGS at config time, not when the resulting libtool is run. If you don't believe me, try creating a libtool on an AIX system. Then set LDFLAGS=-brtl in your environment and configure it again. Hmmm, that libtool script looks mighty different. With the first libtool you made, you'll always get the those .a container libraries made. With the second libtool, you'll never get them, and you'll get the -G option. Is that really what we want? Well it's not what I want, I'm actually building several libraries, some to be linked against and some to be dynamically loaded. Also it seems like this checking of -brtl/-Wl,-brtl flags is not the libtool approach (even if it were done when libtool runs). We should use the -module flag to indicate that someone is building a library that needs runtime linking and loading. I think that's the intent of the -brtl checks, right? - Don -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don Anderson[EMAIL PROTECTED] Sleepycat Software Inc. +1-978-287-4781 118 Tower Rd. http://www.sleepycat.com Lincoln, MA 01773 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MacOSX and autoconf/automake/libtool
[EMAIL PROTECTED] wrote on May 16: Today's Topics: 1. MacOSX and autoconf/automake/libtool (Erik de Castro Lopo) --__--__-- Message: 1 Date: Thu, 16 May 2002 14:27:26 +1000 From: Erik de Castro Lopo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MacOSX and autoconf/automake/libtool Organization: Erik Conspiracy Secret Labs Hi People, I am the author of an LGPL library which is supposed to run on Unix, Win32, MacOS and others. While a do have access to two different Unixen, I do not have access to Win32 or more importantly MacOS. I also run Debian and since upgrading to their Woody release (libtool went from 1.3 to 1.4) I have been unable to generate tarballs which compile on the latest release of MacOSX. It seems that libtool is not setting the right compiler flags. I am currently using: autoconf 2.13 (have also tried 2.53) automake 1.5 (have also tried 1.4) libtool 1.4.2a It seems that there is some stuff about libtool and MacOSX here: http://fink.sourceforge.net/doc/porting/libtool.php Can anybody offer any advice on how to generate a tarball that will compile correctly on MacOSX? Regards, Erik -- I was able to build a library I could link against (a .dylib) just fine. I think you need an up to date version of OS X. On the one I tried, ./config.guess produces: powerpc-apple-darwin5.4 . I think we discovered that once we got the newer OS, libtool 1.4.2 started mostly working. If you want to create a dynamically loaded object (.so), rather than just a library you can link against (.dylib), I just learned a few more things and can offer some suggestions. First, to create a .so, you must use the libtool -module flag. That's in the libtool doc, but it isn't necessary on so many systems that it's easy to miss. Second, to get the .so's to be linked right you need the -module to actually set the -bundle flag for ld. There's a quoting problem in libtool. The symptom is: ./libtool: parse error: condition expected: xyes = [3190] I have a short patch for 1.4.2 if anyone needs it; the real fix is already in the CVS tree for libtool. Finally, if you happen to need a .jnilib (a .so that can be loadable by Java as a JNI), you need some way to produce an output file that ends in .jnilib. Libtool can't do this yet; but you can workaround in Java by using System.load() rather than System.loadLibrary(). - Don -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don Anderson[EMAIL PROTECTED] Sleepycat Software Inc. +1-978-287-4781 118 Tower Rd. http://www.sleepycat.com Lincoln, MA 01773 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Patch for libtool 1.4 on QNX.
Hello libtoolers,
Here is a patch to run libtool 1.4 on QNX. I set
lt_cv_deplibs_check_method to 'unknown' because I was unable to
successfully run the test suite: since I don't have direct access to
the QNX box, I'm working through it with someone else. However, these
changes do allow us to build shared libraries on QNX.
Thanks.
- Don
*** libtool.m4.ORIG Tue Apr 24 19:34:11 2001
--- libtool.m4 Sat Jun 16 16:45:25 2001
***
*** 2183,2188
--- 2183,2198
fi
;;
+ nto-qnx)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}.so$versuffix
+${libname}${release}.so$major $libname.so'
+ soname_spec='${libname}${release}.so$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ ;;
+
*)
dynamic_linker=no
;;
***
*** 3228,3233
--- 3238,3247
[lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [ML]SB
(executable|dynamic lib)']
lt_cv_file_magic_cmd=/usr/bin/file
lt_cv_file_magic_test_file=/usr/lib/libnls.so
+ ;;
+
+ nto-qnx)
+ lt_cv_deplibs_check_method=unknown
;;
osf3* | osf4* | osf5*)
- Don Anderson
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Remember to send requests for assistance on
new problems to [EMAIL PROTECTED]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Anderson[EMAIL PROTECTED]
Sleepycat Software Inc. +1-978-287-4781
118 Tower Rd. http://www.sleepycat.com
Lincoln, MA 01773
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Fix for libtool on freebsd: defer use of -lc until app is linked
Hello libtoolers, Here is a fix for libtool 1.4 running on freebsd. Applications linked with our library (libdb.so, built using libtool) on freebsd have libc.so mistakenly pulled in by libdb.so, even though we don't specify -lc on our command line. The idea on freebsd is to defer the selection of -lc vs. -lc_r until the application is linked. The application builder has a choice to use the -pthread option or not, so they'll get the libc.so or libc_r.so accordingly. Making the attached change fixes the problem. We've also confirmed that all the libtool tests pass with this change on freebsd. Can somebody please incorporate this? We submitted an equivalent patch for a previous version of libtool, but somehow it never got in. Please clue me in if there's a better way to submit patches. Thanks! - Don Anderson *** ltmain.in.ORIG Tue Apr 24 19:10:46 2001 --- ltmain.in Sat Jun 16 16:49:16 2001 *** *** 2405,2411 # Rhapsody C library is in the System framework deplibs=$deplibs -framework System ;; ! *-*-netbsd*) # Don't link with libc until the a.out ld.so is fixed. ;; *) --- 2405,2411 # Rhapsody C library is in the System framework deplibs=$deplibs -framework System ;; ! *-*-netbsd* | *-*-freebsd*) # Don't link with libc until the a.out ld.so is fixed. ;; *) *** ltmain.sh.ORIG Tue Apr 24 19:35:10 2001 --- ltmain.sh Sat Jun 16 16:49:33 2001 *** *** 2405,2411 # Rhapsody C library is in the System framework deplibs=$deplibs -framework System ;; ! *-*-netbsd*) # Don't link with libc until the a.out ld.so is fixed. ;; *) --- 2405,2411 # Rhapsody C library is in the System framework deplibs=$deplibs -framework System ;; ! *-*-netbsd* | *-*-freebsd*) # Don't link with libc until the a.out ld.so is fixed. ;; *) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don Anderson[EMAIL PROTECTED] Sleepycat Software Inc. +1-978-287-4781 118 Tower Rd. http://www.sleepycat.com Lincoln, MA 01773 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Patch for QNX support for libtool-1.3.5
Libtoolers,
Here's a fix submitted by our QNX engineer to get our product
(Berkeley DB) to work with QNX dynamic libraries. Without this patch,
libtool conservatively builds only static archives.
Apparently QNX uses GNU ld, so the fix is straightforward.
Thank you for reviewing this and incorporating into the next
libtool release, if possible.
- Don
*** ltconfig.orig Thu Oct 12 11:57:19 2000
--- ltconfigThu Oct 12 11:57:28 2000
***
*** 2145,2150
--- 2145,2163
fi
;;
+ local change for Sleepycat DB:
+ # Add in the QNX support from QNX.
+ nto-qnx)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}.so$versuffix
+${libname}${release}.so$major $libname.so'
+ soname_spec='${libname}${release}.so$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ deplibs_check_method='pass_all'
+ ;;
+
*)
dynamic_linker=no
;;
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Anderson[EMAIL PROTECTED]
Sleepycat Software Inc. +1-978-287-4781
394 E. Riding Dr. http://www.sleepycat.com
Carlisle, MA 0174
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
