test failed
# make check | grep FAIL FAIL: demo-exec.test FAIL: demo-exec.test FAIL: demo-exec.test FAIL: hardcode.test FAIL: build-relink.test that was on NetBSD-1.4Y/Alpha (ELF) and libtool 1.3.5. how can in find out why the test failed and track down the errors.
Re: ltcf-cxx.sh
On 29 May 2000, Alexandre Oliva wrote: > On May 29, 2000, Paul Berrevoets <[EMAIL PROTECTED]> wrote: > > > In general, this statement is false. The Solaris (>=2.5) linker _does_ > > allow non-PIC code in shared libraries. > > Ok. The problem is that gcc links shared libraries with `-z text', > unless `-mimpure-text' is given. Maybe that's the flag libtool should > use when it finds libstdc++ is not a shared library. Perhaps, but I would prefer an option to either drop the static libraries OR get the linker to accept them. Linking static libraries into shared libraries could also cause problems when two different shared libraries have slightly different versions of the same static library. -- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
Re: ltcf-cxx.sh
On May 29, 2000, Paul Berrevoets <[EMAIL PROTECTED]> wrote:
> In general, this statement is false. The Solaris (>=2.5) linker _does_
> allow non-PIC code in shared libraries.
Ok. The problem is that gcc links shared libraries with `-z text',
unless `-mimpure-text' is given. Maybe that's the flag libtool should
use when it finds libstdc++ is not a shared library.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltcf-cxx.sh
Alexandre Oliva wrote: > On May 29, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote: > > > This is a bug in gcc at least til 2.8.1 (no 2.95 here at the > > moment): > > > _IO_do_write0x8c > > /opt/GCC281/lib/libstdc++. > > a(stdiostream.o) > > Not a bug. It's just that libstdc++ is not PIC, and Solaris' linker > refuses to include such non-PIC code in a shared library. This means > you wouldn't be able to create a shared library with g++ on Solaris. In general, this statement is false. The Solaris (>=2.5) linker _does_ allow non-PIC code in shared libraries. It may refuse to link in objects from a static archive (I don't know if this is true or not), but if it didn't, I suspect it wouldn't matter if the static archive contained PIC or non-PIC code. I know that have seen non-PIC objects linked into a shared library by the Solaris linker. -- Regards, Paul
Re: ltcf-cxx.sh
On May 26, 2000, Michael Matz <[EMAIL PROTECTED]> wrote:
> On Thu, 25 May 2000, Ossama Othman wrote:
>> Hmm, I though that Alexandre as already took care of this.
Not me, but the patch is already in.
> Hmm, it seems the newest diff to libtool-ml has something, but it
> only deals with stripping an eventual path, the diff below deals
> with that (it also uses CXX not CC, though they should be the same):
BTW, I don't really see the point of using CXX at all. In fact, it's
wrong, we should be consistently using CC.
Would you mind fixing these issues and posting a patch to
[EMAIL PROTECTED], along with a ChangeLog entry?
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltcf-cxx.sh
On May 29, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> Ossama Othman wrote:
>> Now that I think about it, libtool is only reproducing what the C++
>> compiler would normally do internally, so why would libtool be wrong?
>> Specifically, libtool disables the internal library link commands that
>> the C++ compiler would normally perform automatically, and simply does
>> the linking itself. Why does it work for the C++ compiler?
> It doesn't. This is a bug in gcc at least til 2.8.1 (no 2.95 here at
> the moment):
Which means libtool should consider whether to add libstdc++ (or any
other implicitly-linked libraries, for that matter) just like it
considers any other libraries: on platforms that won't allow non-PIC
code into shared libraries, we'd have to drop it.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: ltcf-cxx.sh
On May 29, 2000, Stephan Kulow <[EMAIL PROTECTED]> wrote:
> This is a bug in gcc at least til 2.8.1 (no 2.95 here at the
> moment):
> _IO_do_write0x8c
> /opt/GCC281/lib/libstdc++.
> a(stdiostream.o)
Not a bug. It's just that libstdc++ is not PIC, and Solaris' linker
refuses to include such non-PIC code in a shared library. This means
you wouldn't be able to create a shared library with g++ on Solaris.
--
Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat companyaoliva@{redhat, cygnus}.com
Free Software Developer and EvangelistCS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org} Write to mailing lists, not to me
Re: libtool patch to allow overriding AR_FLAGS
Hi Jason, Fred, Sorry for the delay -- I am working through my email backlog after an extended period of busyness... On Fri, Jan 07, 2000 at 02:29:09PM -0800, Jason Merrill wrote: > A while back, Fred Fish wrote this patch to allow an environment to > override AR_FLAGS, presumably for use on BeOS. I've updated the patch to > 1.3.4. Thanks for the patch! Unfortunately it broke the sources in a few ways for normal compilation, so I fixed it up a little before applying. I am afraid it missed the 1.3.5 release from Friday, but it is now in the trunk (for 1.4) and I ported it to the multi-language-branch (for 1.5). Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
Re: ltcf-cxx.sh
Ossama Othman wrote:
>
> Hi Kevin,
>
> On Sun, May 28, 2000 at 07:37:11PM -0400, Kevin Atkinson wrote:
> > I was just informed that the HEAD branch does indeed drop static library
> > dependencies when making shared libraries. Perhaps the HEAD branch needs
> > to be merged with the ML branch or is it something else?
>
> The core HEAD branch libtool files ltmain.in, ltconfig.in and
> libtool.m4 have been merged into the ML branch. However, the ML
> branch probably reintroduced the static libs due to the fact it
> analyses what the C++ compiler links internally based on output from
> "g++ -v," for example. What is most likely happening is that the new
> C++ library analysing code is bypassing the code in libtool that would
> normally drop the static libs.
>
> Now that I think about it, libtool is only reproducing what the C++
> compiler would normally do internally, so why would libtool be wrong?
> Specifically, libtool disables the internal library link commands that
> the C++ compiler would normally perform automatically, and simply does
> the linking itself. Why does it work for the C++ compiler?
>
It doesn't. This is a bug in gcc at least til 2.8.1 (no 2.95 here at
the moment):
kulow@zeus:~>cat test.C
#include
int foo() { cout << "hello" << endl; return 0; }
kulow@zeus:~>g++ -shared -o libtest.so test.C
Text relocation remains referenced
against symbol offset in file
_IO_do_write0x8c
/opt/GCC281/lib/libstdc++.
a(stdiostream.o)
_IO_do_write0x1d4
/opt/GCC281/lib/libstdc++.
a(stdiostream.o)
_IO_do_write0x640
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write0xca0
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write0x6f0
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write0x6b4
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write0x668
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write0x100
/opt/GCC281/lib/libstdc++.
and so on
Greetings, Stephan
--
... but you ain't had mine
