Tim,
hpux under pa-risc (even 64-bit) still uses the .sl extension even where 64-bit ELF
libraries are concerned. Only under the Intel architecture does it use the .so
filename. If you want to have a look for yourself, HP gives out shell access under
their testdrive program, which gives you
Iaki:
Static libs on every platform need to have this dependency info.
Robert
-Original Message-
From: Iaki Garca Etxebarria [mailto:[EMAIL PROTECTED]
Sent: Friday, September 19, 2003 9:22 AM
To: [EMAIL PROTECTED]
Subject: Link performance: some numbers and a hack
Hi,
Is there any
Alternatively, I think gcc/g++/g77/gcj can use -Xlinker instead of -Wl.
Robert
-Original Message-
From: Peter O'Gorman [mailto:[EMAIL PROTECTED]
Sent: Friday, September 19, 2003 10:20 AM
To: Nicolas Roche
Cc: [EMAIL PROTECTED]
Subject: Re: libtool replace -Xlinker by -Wl can lead to
Sander,
If you can ensure this check is done after the libtool script is created,
you may be able to write a macro similar to AC_CHECK_LIB that uses a
shared library rather than an executable. If it won't link, you can
assume that there isn't a shared version of the dependent library.
If this
: Tuesday, September 16, 2003 5:19 AM
To: Bob Friesenhahn
Cc: Boehne, Robert; [EMAIL PROTECTED]
Subject: Re: Fixing malloc.h related warning
Bob Friesenhahn wrote:
On Mon, 15 Sep 2003, Boehne, Robert wrote:
Dalibor,
This would require a patch that looks for whatever malloc.h is #included
No,
This can be turned off with -avoid-version:
`-avoid-version'
Tries to avoid versioning (see section 6. Library interface versions) for libraries
and modules, i.e. no version information is stored and no symbolic links are created.
If the platform requires versioning, this option has no
No, it doesn't.
-Original Message-
From: Rafael Laboissiere [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2003 1:28 PM
To: Boehne, Robert
Cc: [EMAIL PROTECTED]
Subject: Re: Library symlinks installation
* Boehne, Robert [EMAIL PROTECTED] [2003-09-16 12:03]:
This can be turned
to be defined. IIRC, we had a suggestion to change this very thing in the
past, we did, and it caused other problems so we reverted it.
HTH,
Robert
-Original Message-
From: Martin Frydl [mailto:[EMAIL PROTECTED]
Sent: Monday, September 15, 2003 11:11 AM
To: Boehne, Robert
Cc: [EMAIL PROTECTED
Dalibor,
This would require a patch that looks for whatever malloc.h is #included for
in stdlib.h and prefers it in stdlib.h. So it isn't as simple as s/malloc/stdlib/.
Robert
-Original Message-
From: Dalibor Topic [mailto:[EMAIL PROTECTED]
Sent: Monday, September 15, 2003 11:36 AM
, September 15, 2003 1:10 PM
To: Boehne, Robert
Cc: [EMAIL PROTECTED]
Subject: Re: Fixing malloc.h related warning
Hi Robert,
what about
/*
* Include the header defining malloc.
*
* On KR C compilers, that's malloc.h,
* on ANSI C and ISO C compilers, that's
* stdlib.h
Bob,
I agree, and would approve such a patch if one were posted.
Robert
-Original Message-
From: Bob Friesenhahn [mailto:[EMAIL PROTECTED]
Sent: Monday, September 15, 2003 1:38 PM
To: Boehne, Robert
Cc: Dalibor Topic; [EMAIL PROTECTED]
Subject: RE: Fixing malloc.h related warning
Alan,
Until last week, none of us had a libtool-1.5 tarball, but now that
one has been located we can verify it for the FSF. I'm not sure
when though.
HTH,
Robert
-Original Message-
From: Alan W. Irwin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 11:54 AM
To: [EMAIL
Bill,
Yes, Libtool 1.5 (and cvs) allows you to specify any extension
for a shared library by passing -shrext extension on the link line.
To use it for jnilibs, you will have to have some configury
to set the option on MacOS X only.
HTH,
Robert
-Original Message-
From: Bill Northcott
Thomas,
This will make the objects link in twice in other cases.
Robert
-Original Message-
From: Thomas Woerner [mailto:[EMAIL PROTECTED]
Sent: Friday, August 08, 2003 5:53 AM
To: [EMAIL PROTECTED]
Subject: libtool 1.5 fix
libtool --mode=link gcc test1.o test2.o -o libtest.a
results
Wouldn't replacing -DPIC with -D__PIC__ break a fundamental
assumption about ANSI compilers, that __ means compiler-defined
and not in the userspace?
IMHO, I have yet to see an example of how it could be useful
to define PIC when it seems that the only way to make use of
it is to have it surround
:[EMAIL PROTECTED]]
Sent: Thursday, January 16, 2003 9:51 AM
To: Boehne, Robert
Cc: Simon Richter; [EMAIL PROTECTED]
Subject: Re: [PATCH] Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran)
-DPIC
Boehne, Robert schrieb:
IMHO, I have yet to see an example of how it could be useful
to define PIC
Title: RE: Problem on rs6000-ibm-aix4.3.2.0 (Fortran)
Steve,
I will look into this, but FYI, -DPIC should not be passed when
compiling Fortran.
Thanks,
Robert
-Original Message-
From: Steve Edwards [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 1:03 PM
To: [EMAIL
To: [EMAIL PROTECTED]
Subject: Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran)
On Wed, Jan 15, 2003 at 02:22:15PM -0500, Boehne, Robert wrote:
I will look into this, but FYI, -DPIC should not be passed when
compiling Fortran.
Why should -DPIC be passed at all for any compiler?
Thanks
Title: RE: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Ok then, I'll see if I can make -DPIC into
a conditionally-set thing that would be set to for anything
but C and C++. Can we agree on that? ;)
Robert
-Original Message-
From: Simon Richter [mailto:[EMAIL PROTECTED]]
the compiler define it for you?
Robert
-Original Message-
From: Simon Richter [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 5:46 PM
To: Boehne, Robert
Cc: 'Simon Richter'; [EMAIL PROTECTED]
Subject: Re: Problem on rs6000-ibm-aix4.3.2.0 (Fortran) -DPIC
Robert,
Ok
Title: RE: 1.5 alpha release?
Albert,
There are still issues with Mac OS X, and the patch for hppa64 from Ross.
The problem with OS X is that $shrext is evaluated too soon, and I can't
figure out how to quote it so it won't. I may end up having to add
a second variable $modext and going
Title: RE: hppa*64* and dependent libraries
Albert,
Post the patch you have for 1.4. I'm curious as to why you need to set $wl at all,
if linking is being done with ld then ${wl}= for any flag. IMHO, if that
isn't being done properly we need to find out why.
Thanks,
Robert
Title: RE: SED ?
Patrick,
Yes something is wrong here, I'm currently working on fixing this
but I didn't know it was broken in CVS Libtool. The problem I'm
having is that $SED needs to be set earlier than it currently is,
so the resulting libtool is attempting to operate with untested
sed
Title: RE: libtool support for Intel's icc
Roberto,
We have a patch, but no copyright assignment as of yet.
I have been assured that the paperwork has been sent to the FSF, so
it should just be a matter of time.
Thanks,
Robert
-Original Message-
From: Roberto Bagnara
Kratochvil
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 07, 2002 9:19 AM
To: Boehne, Robert
Cc: [EMAIL PROTECTED]
Subject: Re: solving of name conflicts in included .a
Robert,
On Thu, 07 Nov 2002 15:52:10 +0100, Boehne, Robert wrote:
...
I haven't gone over your patch with a fine-toothed
Eric,
The
main branch in the CVS repository (snapshots available at ftp://alpha.gnu.org/gnu/cvs)
fully
supports C++. There aren't any issues with C++ and LIbtool that aren't C++
issues
in
general.
HTH,
Robert
Boehne
-Original Message-From: Eric
Lemings [mailto:[EMAIL
Dirk,
Yes, 1.4.3 doesn't support C++. You can get a snapshot
of CVS from:
ftp://alpha.gnu.org/gnu/cvs/libtool.tgz
or from CVS directly. This will be released as 1.5 just
as soon as some paperwork is completed by the FSF
and a few patches are installed.
The problem is that 1.4.x doesn't link
Hello,
The real problem is that ELF platforms shouldn't
ever relink, because it isn't necessary and it
causes problems like these. If I get a patch
against CVS head to do this, that means I won't
have to make one myself, and it will get checked
in sooner.
Any volunteers?
--
Robert Boehne
We're pleased to announce the release of Libtool 1.4.3!
This is a patch release, the last one in the 1.4.x series,
and is compatable with Autoconf 2.13.
You can find the new release here:
in tarball,
ftp://ftp.gnu.org/gnu/libtool/libtool-1.4.3.tar.gz
xdelta,
Charles,
I think this fix was accidentally piggybacked on top of
another patch I checked in. I knew it happened after
the check in, but I thought I'd see if it fixed the problem
rather than back it out or add a ChangeLog entry.
I'll try to be more careful. ;)
Rob
--
Robert Boehne
Benjamin,
My point is that it would encourage developers to
write softwre that would ONLY compile on Darwin.
A similar case is the use of $ORIGIN/ in a hardcoded
library path. Not many OS's support it, and anyone
who depends on it would limit the possible supported
platform list down to only
With the link line fully qualified with all of the system libraries and
objects you could just use ld directly. It would be better, IMO, though
to remove the system libraries from the link command and allow g[cc|++]
to add the appropriate system libraries so that if some new system
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 Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: rboehne
Liwei:
Libtool 1.4.2 is not safe for anything but C, C++ support is
in the current CVS sources. The architecture of 1.4 is such
that C++ can't be supported which is why the current CVS
development is significantly branched off from it.
Robert
--
Robert Boehne Software Engineer
Alain:
Ok, I was confused about what exectly you were asking.
I think the best way to do this is to pass it as a single
flag, like this:
-Wl,'-whole-archive -lfoo -no-whole-archive'
This way those options won't be rearranged on the ld command
line.
Thanks,
Robert
--
Robert Boehne
Rotney,
Your question isn't relevant to libtool at all, you should ask
your question somewhere relevant, but I'm not sure where that is.
Sorry,
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
Bill,
If you can fix it in just a few lines, you don't need
a copyright assignment.
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: rboehne AT ricardo-us DOT com
Jost:
The flag you referr to is hp-compiler specific, so it can't
be put into ltmain.in. Possibly a better solution is to
figure out why +DAportable was lost. In the mean time you
could probably work around this by changing:
export CFLAGS=+DAportable -Ae +O2
to
export CFLAGS=-Wc,+DAportable
Jost:
The problem may be that Libtool doesn't treat options with +
the same way it treats -. It doesn't sound like that would be
terribly difficult to fix though. But before you go looking in
ltmain.in, you might want to try the CVS head version of Libtool.
There have been recent changes to
Title: RE: CVS libtool causes C++ exceptions to fail under Solaris 2.6
Bob:
I'm currently looking into this, it seems to happen in
many places. As you point out, this is just plan wrong
but I'm not sure where the problem really is.
Robert
-Original Message-
From: Bob Friesenhahn
PROTECTED]]
Sent: Tuesday, May 01, 2001 4:59 PM
To: Boehne, Robert; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: to libtool or not: Windows Unix NSAPI program
Have you tried a make check on libtool on cygwin recently Robert?
It may be supported but it don't work :[.
Rob
(approximately) using the method
discussed here.
Robert
-Original Message-From: Boehne, Robert
Sent: Wednesday, January 31, 2001 5:45 PMTo: 'Alexandre
Oliva'Cc: '[EMAIL PROTECTED]'Subject: RE: Fix for Arg list
too long
-Original Message- From:
Alexandre Oliva [mailto
Title: RE: Fix for Arg list too long
-Original Message-
From: Alexandre Oliva [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 31, 2001 1:27 PM
To: Boehne, Robert
Cc: '[EMAIL PROTECTED]'
Subject: Re: Fix for Arg list too long
On Jan 31, 2001, Boehne, Robert [EMAIL PROTECTED
43 matches
Mail list logo
