Re: disable static libraries?
From: Ed Hartnett [EMAIL PROTECTED] Date: Tue, 13 May 2008 07:33:02 -0600 (The .a file is always a static library, right?) Not on AIX. A .a file can be a shared library, a static library, or some combination of the two. Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Supporting -export-dynamic on AIX
From: Albert Chin [EMAIL PROTECTED] Any reason we don't use -bexpall to support -export-dynamic on AIX? From ld(1): autoexp Automatically exports some symbols from the output module without having to list them in an export file. (This option does not export all symbols from the output module. Use the -bexpall option to export all symbols.)This is the default. Use this option when linking a main program. The linker assumes that you are linking a main program when you do not specify a module type (with the M or modtype option) beginning with S and you do not use the noentry option. It's needed for things like gaim and galculator to work. -bexpall always seemed to do things a little strange. It doesn't export anything starting with _, and it does export a few symbols it probably shouldn't. I didn't notice that this caused any errors, but it did generate warnings for duplicate symbols. Because of this, I've avoided using -bexpall when building shared libraries, thought I have occasionally used it to build main programs that need to export symbols to it's shared libraries or loadable objects. Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: link-order: skip grep on AIX
Ralf, Make sure you have the fileset bos.adt.syscalls installed. The syscalls.exp file should be in there. Check with: lslpp -l bos.adt.syscalls Dan From: Ralf Wildenhues [EMAIL PROTECTED] By the way, on an AIX 5.3 system I have access to, there is no /lib/syscalls.exp file, so static linking fails completely with libtool. Does anybody know whether this may be an installation error I should report, or AIX changed this somehow since 5.2?
Re: no AIX 5 support? I've got some idea what's needed.
That seems rather odd to me. -G is a linker flag, and no matter which compiler you use, the AIX ld command is what is eventually invoked. Dan From [EMAIL PROTECTED] Tue Dec 3 05:38:03 2002 I've seen reports from Apache-2.0+AIX users that -G isn't added with gcc, but I see it added with xlc_r. By any chance is that something you can confirm or deny? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool, Apache 2.0, AIX
Jeff, You can change the behavior of libtool on AIX by adding a a flag to the LDFLAGS variable. Try this: export LDFLAGS=-Wl,-brtl before doing configure and make. Dan From: Jeff Trawick [EMAIL PROTECTED] Apache 2.0 uses libtool and has for some time now. On AIX we're trying to use libtool 1.4.2 but are running into some issues that perhaps someone can shed some light on. background info: Apache 2.0 uses code in libapr and libaprutil, implicitly loaded with httpd. As always, Apache 2.0 does dlopen() on DSOs configured in httpd.conf. These DSOs reference symbols in the main executable (httpd), libapr, libaprutil, and anything else needed by the DSO. libtool+AIX behaviors which we don't understand: (Some of this we can work-around with AIX-specific logic in our own build. Some of this we might be able to patch into libtool. For all of this, it would be useful if the suggested behavior is inappropriate for some reason.) 1) after building our shared libraries, libtool is putting them in an archive file and that archive file is what gets installed... why is this? while this works on AIX, it is non-intuitive... people expect foo.so, particularly with Apache DSOs like mod_include... currently on AIX I need to use the Apache syntax LoadModule mod_foo libfoo.a(libfoo.so.0) and turn on the dlopen() flag that allows members to be loaded. While the libfoo isn't a major problem for libraries used implicitly by httpd (libapr and libaprutil), it is messy for DSOs because of the Apache configuration file syntax implications. So... really important for us to avoid the archive/member thing for Apache DSOs. nice for us to avoid the archive/member thing for libapr/libaprutil It seems to me that doing run-time linking will trick libtool into skipping the archive/member thing but we don't want run-time linking. 2) export file format libtool seems to be building a nice export file on AIX, but it is missing a small detail which would allow it to be used as an import file remember that on AIX, a shared library which needs symbols from another shared library must use import files to tell the loader which symbols are expected from which shared libraries... Apache builds libaprutil.a(libaprutil.so) which depends on libapr.a(libapr.so). It would be nice if the export file for libapr had #! libapr.a(libapr.so) at the top so it can be used as an import file 3) implicitly specifying import files (closely related to #2 above) libaprutil depends on libapr when I build libaprutil it would be nice for the libapr import/export file to be specified by libtool; it should be able to know that I'm building a shared library (libaprutil) which depends on another shared library (libapr) currently, libaprutil is not usable because the dynamic linker doesn't know how to resolve the symbols 4) it would be nice to get libtool-generated export files for main executables... libtool has the nice logic to generate the export files... I don't know how to get one generated for the main executable (e.g., .libs/httpd.exp to go with .libs/httpd) we do have logic to generate our own export files, but if we get libtool to implicitly use import files libtool would want to use a file it had generated Thanks and best wishes, Jeff -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool does not preserve -xarch=v9
From: Bob Friesenhahn [EMAIL PROTECTED] On Fri, 21 Sep 2001 [EMAIL PROTECTED] wrote: On Thu, Sep 20, 2001 at 09:38:29PM -0500, Bob Friesenhahn wrote: 64-bit compilation under Solaris Sun's compiler requires that the argument '-xarch=v9' be provided when compiling C++ objects. Unfortunately libtool (1.4a (1.641.2.259 2001/06/04 19:32:47)) is discarding this argument (which was passed via LDFLAGS to configure) so objects are built as 32-bit objects instead. Is a fix for this available? Does Sun ld(1) even support -xarch? I just checked the manpage on a Solaris 8/SPARC 64-bit system and didn't see mention of it. I also tried linking a library using ld(1) with -xarch=v9 as an argument and got an error. The way Sun's build environment supports 64-bit compilation, it is only necessary to build all objects using -xarch=v9. The linker is responsible for selecting the correct mode based on the mode of the objects. All linked objects must be built for the same model or linking will fail. Ok, so it sounds like your first problem is that you are trying to pass a compiler flag to the linker. Dan ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool RFE
From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: libtool RFE Date: Tue, 11 Sep 2001 16:05:17 -0500 Are you aware of any OS that supports 32 and 64-bit libraries in the same directory? I know Solaris and AIX don't do this. The libraries that ship as part of AIX (on PowerPC) are actually archives, and most of them do indeed contain 32 and 64 bit objects. Dan albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AIX shared libraries in MLB and 1.4
Hi Albert,
It looks like AIX has been using
version_type=linux
for quite some time. So I guess we should keep using it.
Dan
From: [EMAIL PROTECTED]
On Wed, Apr 25, 2001 at 10:38:31AM -0500, [EMAIL PROTECTED] wrote:
I've been meaning to send in a patch about this:
soname_spec='${libname}${release}.so$major'
is what we finally decided to go with for AIX standard linking.
It is important to get these synched up, or we will have binary
compatibility problems.
And do you plan to leave version_type=linux for 1.4? To keep 1.4 and
MLB the same, we need to decide on whether or not version_type=linux
and what soname_spec is. I'm fine with removing version_type=linux and
making soname_spec equivalent to what you have above (though different
from MLB but I'm assuming you know better what to do).
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: AIX shared libraries in MLB and 1.4
I've been meaning to send in a patch about this:
soname_spec='${libname}${release}.so$major'
is what we finally decided to go with for AIX standard linking.
It is important to get these synched up, or we will have binary
compatibility problems.
Dan
From [EMAIL PROTECTED] Wed Apr 25 08:13:05 2001
I'm looking over the differences in how shared libraries are built
between MLB and 1.4. Some questions:
1. Any reason for version_type=linux in 1.4 and not MLB?
2. Should we sync up shared library names between 1.4 and MLB
(cf soname_spec below). Shared library names in MLB are
libfoo.so.o while in 1.4 its libfoo.so.$major.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.166
diff -u -3 -p -r1.166 libtool.m4
--- libtool.m42001/04/24 23:40:42 1.166
+++ libtool.m42001/04/25 12:51:50
@@ -1832,7 +1832,6 @@ aix3*)
;;
aix4* | aix5*)
- version_type=linux
if test $host_cpu = ia64; then
# AIX 5 supports IA64
library_names_spec='${libname}${release}.so$major
${libname}${release}.so$versuffix $libname.so'
@@ -1854,18 +1853,20 @@ aix4* | aix5*)
fi
;;
esac
-# AIX (on Power*) has no versioning support, so currently we can not hardcode
correct
-# soname into executable. Probably we can add versioning support to
-# collect2, so additional links can be useful in future.
+# AIX (on Power*) has no versioning support, so currently we can
+# not hardcode correct soname into executable. Probably we can
+# add versioning support to collect2, so additional links can
+# be useful in future.
if test $aix_use_runtimelinking = yes; then
- # If using run time linking (on AIX 4.2 or later) use libname.so instead of
- # libname.a to let people know that these are not typical AIX shared
libraries.
+ # If using run time linking (on AIX 4.2 or later) use libname.so
+ # instead of libname.a to let people know that these are not
+ # typical AIX shared libraries.
library_names_spec='${libname}${release}.so$versuffix
${libname}${release}.so$major $libname.so'
else
# We preserve .a as extension for shared libraries through AIX4.2
# and later when we are not doing run time linking.
library_names_spec='${libname}${release}.a $libname.a'
- soname_spec='${libname}${release}.so$major'
+ soname_spec='${libname}${release}.so$major.o'
fi
shlibpath_var=LIBPATH
deplibs_check_method=pass_all
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Configuring libtool HEAD branch.
Actually... Robert Boehne has already merged my changes into the multi-language-branch. Dan From [EMAIL PROTECTED] Mon Apr 16 20:49:52 2001 Do you think there is any chance of getting my AIX changes in? Certainly. Sooner, if you help me with a port to the multi-language-branch... Cheers, Gary. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Configuring libtool HEAD branch.
From [EMAIL PROTECTED] Mon Apr 16 20:49:52 2001 - When building libtool without run-time-linking, my changes do still create a libname.a. However, it is an actual archive containing the shared object (just like the quirky way the rest of AIX does it). What you end up with is a libltdl.a that contains both the shared and the non-shared object. This is not really what was intended, and would likely cause problems if you ever really needed to use the non-shared object, but for the most part it seems to work. The only other thing I can think to do is not bulid the non-shared object in this case. Is this the best approach? (I am not arguing that it isn't... I just want you to reassure me that having distinct linktime vs. runtime library names is more broken on AIX than what you have in your current patch). Hi Gary, Could you explain this a little more, I'm not sure I understand what you are asking? Dan ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Configuring libtool HEAD branch.
From: Russ Allbery [EMAIL PROTECTED] Piggybacking off of Gary's response On Monday 16 April 2001 11:05 pm, [EMAIL PROTECTED] wrote: - When building libtool without run-time-linking, my changes do still create a libname.a. However, it is an actual archive containing the shared object (just like the quirky way the rest of AIX does it). What you end up with is a libltdl.a that contains both the shared and the non-shared object. This is not really what was intended, and would likely cause problems if you ever really needed to use the non-shared object, but for the most part it seems to work. The only other thing I can think to do is not bulid the non-shared object in this case. But isn't this how AIX natively supports having both a shared and unshared version of the library available at the same time? I think this is actually closer to exactly what you want than one might think. I'm only remembering this very vaguely from discussion in other lists, but I seem to recall that AIX's native tools can then select static or shared linking by choosing which objects in the .a they pull in. Well sort of. There are several libraries on AIX that contain shared and non-shared members in the archive. However, the members contain different code. The linker will simply search the members in the archive, in order, for symbols it is interested in. In this case it will always find the symbols it needs in the shared member, and I don't believe it will ever look at the unshared member. Some vague memory also tells me that this is how shared library versioning is done (with differently named shared objects). Yes this is correct. Typically what is done is all but the newest version of the shared members have a special LOADONLY flag set so that the linker will only see the newer member. But the loader can find any of the members at run time. If for some reason you need to link with an older version of the shared library, you generally use an import file. Dan McNichol IBM, Austin Texas ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool AIX
I have a rather extensive patch for libtool on AIX. It fixes a few problems in the code that is currently there, adds support for run time linking, adds support for AIX version 5, adds support for AIX on IA64. I should have it ready soon. Dan McNichol IBM Austin, Texas ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AIX details
Hi Howard, I also have some libtool changes for AIX I have been getting ready to send in. Would you mind coordinating/merging our changes so we don't possibly end up stepping on each other? Dan McNichol IBM Austin, Texas From: "Howard Chu" [EMAIL PROTECTED] I've made some patches to libtool 1.3.3 (and now 1.3.5) for AIX that I'd like to contribute back. In brief: AIX doesn't need the "lib" prefix The -bexpall flag is not really usable for shared libraries; they will tend to export some private C runtime symbols as well, and then runtime linking will fail because these symbols are multiply defined. Fix to always generate and use an explicit export file for shared libraries. Set dlopen_self to true; the test program can't determine this without an export file so just bypass the test. Use the -bexpall flag when linking programs, to support self dlopen. The hardcoded libpath support is messy, I've cleaned it up a little. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Fixing libtool on AIX.
Hello libtool developers, I am rather new to libtool, but I am trying to get it to work better on AIX, as it is severly busted on this platform. I am trying to set it up to do proper run time linking. To do this, shared libraries need to be linked with the "-G" flag (so far pretty easy), but programs that use these libraries need to be linked with a different flag "-brtl" (this is the harder part). So my question is: is there an an easy way to tell the build environment to use one flag when linking a shared library, but a different one when linking a program? Thanks Dan McNichol IBM Austin, Texas
