SJR> This patch is still RedHat/Fedora specific with no SJR> check to make sure it is only running on that SJR> system. Yep, that's why I sent it to the libtool list and not libtool-patches this tim
This patch is still RedHat/Fedora specific with no check to make sure it is only running on that system. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round th
For what it's worth, in GMP that's what we've done. In principle there could be different libc functions and stuff in different ABIs, so a fresh run of configure is the safest way to be sure of getti
I have a general opensource packaging/build question that is sort of related to libtool (I think) and was hoping someone could answer it or provide me with a pointer. For an opensource package that c
On 2004-12-03T13:03-0600, Bob Friesenhahn wrote: ) On Fri, 3 Dec 2004, Daniel Reed wrote: ) > The patch is specific to GCC, not Linux. Any operating system that uses a ) > multilib-capable GCC should
Red Hat's currently-supported base platforms[*] are RHEL 2.1, RHEL 3, FC 2, FC 3, RHEL 4 (in beta/QA), and FC 4 (in development). As shipping in the latest release/update pack for each: (inherited fr
Crap, I didn't do any final test and managed to exclude a couple of critical changes, and I did a couple of silly mistakes too. Sorry about that. Attached is what I should have sent the first time...
He should be reading this list, if he has time... Anyway, does this work? Cheers, Peter diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 4418a1c..59953d1 100644 -- a/m4/libtool.m4 +++ b/m4/libtool.m4
What for? If you have a look at RH's patch, the actual problems they are trying to solve are: * Setting up sys_lib_search_path_spec, i.e. to retrieve gcc's internal library search path, which, due to
I am not sure. Solaris-gcc applies traditional multilibs, i.e. it is using multilib subdirs (A subdir of PREFIX/lib). I don't know how "multiarchs" are implemented in RH's ix86_64 gcc. /usr/lib64 is
On 2004-08-12T09:00+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) > On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) > ) Daniel Reed wrote: ) > ) > > libtool-1.4.2-multilib.patch ) > ) > This
On 2004-08-12T09:00+0900, Peter O'Gorman wrote: ) Daniel Reed wrote: ) > On 2004-08-11T10:06+0900, Peter O'Gorman wrote: ) > ) Daniel Reed wrote: ) > ) > > libtool-1.4.2-multilib.patch ) > ) > This p
The problem: == Currently, libtool supports several types of libraries (I'm glossing over some stuff here, be gentle): (1) Normal shared libraries (2) Normal static libraries (3) Convenience librarie
Libtool 1.5.10 with .multilib2 (and .nopicfix2) passes all test suite checks on Linux i386 and x86_64 (and ppc, ppc64, ia64, s390, and s390x). As the changed behavior a) is isolated to the discovery
Hi Bob, Joe, libtoolers: 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
Hi Michael :) If I understand the documentation correctly libtool places non-shareable members (.o files) in the src directory and "shareable aka PIC objects in src/.libs". However, libtool makes onl
Hi Michael, IMO, there is no point in having multilib support within libtool for AIX only. If ever, multilib support inside libtool should be implemented in some generic way - to allow for porting to
Hi, In building a development snapshot of one of my projects, to a custom path, on SL6 I am running into what appears to be a linking problem. The libtool command used to link the library is as follo
By looking for undefined symbols matching patterns for symbols from libgfortran. I don't see how querying GCC is ever going to help with this case. The interface -print-search-dirs already exists; yo
Well, my take is that except for people working on the *tools themselves* (meaning gcc, binutils etc), this is not really a problem. Sure, libtool is a tool used by developers, but the end result, DL