Missing ".so" in .la file
Hi, This is a fragment of some libocc_mop.la file created by libtool 1.5.6: # The name that we can dlopen(3). dlname='libocc_mop.0' # Names of this library. library_names='libocc_mop.0.0.0 libocc_mop.0 libocc_mop' # The name of the static archive. old_library='libocc_mop.a' Why no '.so' in dlname and library_names ??? Thanks Grzegorz --- Free C++ frontend library: http://opencxx.sourceforge.net China from the inside: http://www.staryhutong.com Sender of this e-mail: http://www.dziupla.net/gj/cv ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
Hi Bob, Joe, libtoolers: Bob Friesenhahn wrote: > It seems that the only valid test to determine the default output architecture > is to compile code and then use 'file' or some other utility to determine the > architecture. In order to produce multilib output, libtool would need to know > the specific options necessary to obtain each desired variant. These options > are compiler and linker specific. I agree. Much like the options to produce shared libraries at all involves compiler and linker specific options :-) This is libtool's raison d'etre, and we should aim to have support for multilib in our roadmap. It has been in our TODO file for as long as I've been involved with libtool (pushing 7 years now). Joe Orton wrote: > On Fri, Aug 13, 2004 at 03:57:59AM +0200, Ralf Corsepius wrote: > > Solaris-gcc applies traditional multilibs, i.e. it is > > using multilib subdirs (A subdir of PREFIX/lib). > > There is precedent for doing it both ways: IRIX 6.2 and later have > /usr/lib, /usr/lib32 and /usr/lib64 for the three supported ABIs (O32, > N32 and N64 respectively). > > > > How do other Linux vendors (Debian, SuSE etc.) handle this issue? > > I would expect them to be facing the same problems as RH and to have > > similar work-arounds applied to libtool. > > SuSE also ship biarch systems with separate 64-bit /usr/lib64 and 32-bit > /usr/lib, I believe Mandrake do too, and I believe Debian haven't worked > out how (or whether) to do biarch yet. It seems like we can break the back of the problem with support for the two common multilib approaches described here. I also think that by putting early support in libtool before too many ad-hoc solutions develop (particularly from various GNU/Linux vendors) we are probably well placed to help develop some standardisation before we end up having to support the fragmentation that may eventually arise if we waitp However, it is definitely not a 1.5.x issue, and I don't want to delay 2.0 any further. I think we should revisit the issue once the dust has settled on the 2.0 tree, and we start working on features again. Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Missing ".so" in .la file
Does 'make install' result in shared libraries with the ".so" part similarly missing from their names? I ran across a package recently (using libtool) that had this problem under Solaris. Regenerating the build with local auto* tools solved the problem, but if the problem occurs for more than one person, there is certainly a bug somewhere. Bob On Mon, 16 Aug 2004, Grzegorz Jakacki wrote: This is a fragment of some libocc_mop.la file created by libtool 1.5.6: # The name that we can dlopen(3). dlname='libocc_mop.0' # Names of this library. library_names='libocc_mop.0.0.0 libocc_mop.0 libocc_mop' # The name of the static archive. old_library='libocc_mop.a' Why no '.so' in dlname and library_names ??? Thanks Grzegorz --- Free C++ frontend library: http://opencxx.sourceforge.net China from the inside: http://www.staryhutong.com Sender of this e-mail: http://www.dziupla.net/gj/cv ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.8 released.
On Mon, 16 Aug 2004, Gary V. Vaughan wrote: Hi Bob, Joe, libtoolers: Bob Friesenhahn wrote: It seems that the only valid test to determine the default output architecture is to compile code and then use 'file' or some other utility to determine the architecture. In order to produce multilib output, libtool would need to know the specific options necessary to obtain each desired variant. These options are compiler and linker specific. I agree. Much like the options to produce shared libraries at all involves compiler and linker specific options :-) This is libtool's raison d'etre, and we should aim to have support for multilib in our roadmap. It has been in our TODO file for as long as I've been involved with libtool (pushing 7 years now). When building a multilibed library, a variant of the library could be built for every possible architectural option, or a subset of the libraries could be built. It seems to me that being able to choose from a subset of possible library build options is valuable since many build options may offer no value to the user. I am not sure how options would be presented to the installer of the package, but it should be as easy as possible to select which variants are build, and it should even be possible for the person who installs the library to define custom multilib variants to satisfy local requirements. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
