Re: postdeps empty on OpenBSD

[Olly Betts]

On 2005-09-28, Jacob Meuser <[EMAIL PROTECTED]> wrote:
> yes.  I work with transcode (transcoding.org), which is a C program
> that loads modules.  some modules are written in C++.  it works on
> OpenBSD with the C++ modules linked to libstdc++.  this is done
> unconditionally in the Makefile.ams with 'modfoo_la_LIBADD = -lstdc++'.
> I have not had a complaint about this method, but maybe no one's
> actually built such a module for transcode while using a non-system
> g++?

I've just investigated this (on Linux) and it looks like libtool handles
specifying -lstdc++ in LIBADD much better (I was using specifying it
using "make LDFLAGS=-lstdc++" which is wrong now I come to think of it).
Only one -lstdc++ appears in the actual link command, and it's after the
correct -L.  I need to test further but I think this will avoid problems
with non-system GCC installations.

It needs to be conditionalised on using GCC, but that's easy to do in
configure as it already knows.  It'll not cope with other compilers on
platforms that might need this but I'm not aware of any currently.

So I'm happier now, though I still tend to think libtool should just
take care of this.  Otherwise it's a trap waiting to catch anyone
creating such modules - it'll all work fine until someone tries it on
OpenBSD.  If this isn't addressed in the libtool code, a brief
discussion of the issue in the manual would be useful.

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Jacob Meuser]

On Tue, Sep 27, 2005 at 01:31:37PM +, Olly Betts wrote:
> [Cc:-ed to Mark Espie at Jacob's suggestion:
> > I think perhaps you should ask [EMAIL PROTECTED] about this.  he might
> > be able to explain why -lstdc++ is not implicitly used in `g++ -shared'
> 
> If you need context, this is the whole thread:
> http://thread.gmane.org/gmane.comp.gnu.libtool.general/6671
> ]
> 
> On 2005-09-27, Jacob Meuser <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 26, 2005 at 04:15:11PM +, Olly Betts wrote:
> >> I did wonder about getting my project's configure to always specifying
> >> "-lstdc++" if the compiler if GCC (with: test "$GXX" = yes).
> >> 
> >> But I worry that I could end up trying to link in two incompatible
> >> versions of libstdc++ on a machine with multiple GCC installations.
> >
> > are you saying that on some platforms, you actually get
> > -L/path/to -lstdc++?
> 
> You certainly do in some cases.  The one I've seen is with a private
> build of GCC installed in a non-standard path (on Linux).  Then I get
> the following in dependency_libs in the .la file (amongst other things
> I've pruned for clarity):
> 
> -L/u1/olly/install/lib /u1/olly/install/lib/./libstdc++.la 
> /u1/olly/install/lib/./libstdc++.la

OK

> I'm not sure why libstdc++.la is there twice...
> 
> If I explicitly specify LDFLAGS=-lstdc++, then the explicit libstdc++
> appears before the -L above.  So (for example) it would pull libstdc++
> from /usr/lib if there's one there...

yes

> I don't have access to the openbsd box right now to test, but I'd
> imagine I'd get the exact same effect if I installed a private build of
> GCC in my home directory on openbsd and used it.

probably so

> > I don't think I've seen that one yet.  certainly
> > don't see that in the `g++ -shared -v' output you posted before.
> > so how is libtool going to help with this?
> 
> My point here is that I'm not happy with the suggested approach of
> always explicitly linking with libstdc++.  In some situations I believe
> that will break builds which currently work by picking up the wrong
> libstdc++ (or trying to link in two different copies of libstdc++).
> 
> Even always explicitly linking with libstdc++ conditional on $host_os
> matching openbsd* seems like it'll risk getting this wrong in some
> cases (although at least only on a platform which doesn't work at
> present anyway).
> 
> So libtool could help by encapsulating the knowledge of when libstdc++
> needs to be explicitly specified.

but how does libtool know that?

> >> The obvious override mechanism is probably to see if the user specifies
> >> "-lsupc++" explicitly and not to add -lstdc++ if they have.
> >
> > what I don't get, is that at one point, libtool assumes the linker
> > knows what it's doing, and copies it.  but then maybe what it's doing
> > is not right?
> 
> Well, "not right" is perhaps a bit of a loaded phrase.  But the current
> openbsd linker's approach is problematic in the case here where I'm
> linking a C++ module to be loaded via dlopen from a C program.  The
> linker doesn't add a dependency on libstdc++, and the C program doesn't
> have a dependency on libstdc++ either, so the dlopen fails with
> unresolved symbols.

right.  the module should be linked to libstdc++, not the program.
and yes, on OpenBSD, you will not het this automatically, you must
add it explicitly.

> While this may seem like something of a corner case, many programs are
> written in C and support loading of modules - python was the particular
> case here, but most scripting languages support it (perl, php, etc).
> So does apache, as another example.

yes.  I work with transcode (transcoding.org), which is a C program
that loads modules.  some modules are written in C++.  it works on
OpenBSD with the C++ modules linked to libstdc++.  this is done
unconditionally in the Makefile.ams with 'modfoo_la_LIBADD = -lstdc++'.
I have not had a complaint about this method, but maybe no one's
actually built such a module for transcode while using a non-system
g++?

-- 
<[EMAIL PROTECTED]>


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On 2005-09-22, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
> Do we know what the versions of the OS/gcc are where -lstdc++ is missing? We
> can enplicitly add it (as we did recently for, I think, sunpro c++). Is this
> a gcc bug, or is it by design?

I've only been able to test OpenBSD 3.7 with g++ 3.3.5.

It appears to be an OpenBSD linker design decision from what various
people have been saying.

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

[Cc:-ed to Mark Espie at Jacob's suggestion:
> I think perhaps you should ask [EMAIL PROTECTED] about this.  he might
> be able to explain why -lstdc++ is not implicitly used in `g++ -shared'

If you need context, this is the whole thread:
http://thread.gmane.org/gmane.comp.gnu.libtool.general/6671
]

On 2005-09-27, Jacob Meuser <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 26, 2005 at 04:15:11PM +, Olly Betts wrote:
>> I did wonder about getting my project's configure to always specifying
>> "-lstdc++" if the compiler if GCC (with: test "$GXX" = yes).
>> 
>> But I worry that I could end up trying to link in two incompatible
>> versions of libstdc++ on a machine with multiple GCC installations.
>
> are you saying that on some platforms, you actually get
> -L/path/to -lstdc++?

You certainly do in some cases.  The one I've seen is with a private
build of GCC installed in a non-standard path (on Linux).  Then I get
the following in dependency_libs in the .la file (amongst other things
I've pruned for clarity):

-L/u1/olly/install/lib /u1/olly/install/lib/./libstdc++.la 
/u1/olly/install/lib/./libstdc++.la

I'm not sure why libstdc++.la is there twice...

If I explicitly specify LDFLAGS=-lstdc++, then the explicit libstdc++
appears before the -L above.  So (for example) it would pull libstdc++
from /usr/lib if there's one there...

I don't have access to the openbsd box right now to test, but I'd
imagine I'd get the exact same effect if I installed a private build of
GCC in my home directory on openbsd and used it.

> I don't think I've seen that one yet.  certainly
> don't see that in the `g++ -shared -v' output you posted before.
> so how is libtool going to help with this?

My point here is that I'm not happy with the suggested approach of
always explicitly linking with libstdc++.  In some situations I believe
that will break builds which currently work by picking up the wrong
libstdc++ (or trying to link in two different copies of libstdc++).

Even always explicitly linking with libstdc++ conditional on $host_os
matching openbsd* seems like it'll risk getting this wrong in some
cases (although at least only on a platform which doesn't work at
present anyway).

So libtool could help by encapsulating the knowledge of when libstdc++
needs to be explicitly specified.

>> The obvious override mechanism is probably to see if the user specifies
>> "-lsupc++" explicitly and not to add -lstdc++ if they have.
>
> what I don't get, is that at one point, libtool assumes the linker
> knows what it's doing, and copies it.  but then maybe what it's doing
> is not right?

Well, "not right" is perhaps a bit of a loaded phrase.  But the current
openbsd linker's approach is problematic in the case here where I'm
linking a C++ module to be loaded via dlopen from a C program.  The
linker doesn't add a dependency on libstdc++, and the C program doesn't
have a dependency on libstdc++ either, so the dlopen fails with
unresolved symbols.

While this may seem like something of a corner case, many programs are
written in C and support loading of modules - python was the particular
case here, but most scripting languages support it (perl, php, etc).
So does apache, as another example.

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacob Meuser wrote:
| I think perhaps you should ask [EMAIL PROTECTED] about this.  he might
| be able to explain why -lstdc++ is not implicitly used in `g++ -shared',
| which could give you a good starting point on how to "fix" the
| "problem".
|

I already asked him. He replied "It won't change, we do not link shared
libraries together when we can avoid it."

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQzlD8biDAg3OZTLPAQLLZwP+MiXSyXqWIjAUHJoT9ogofXlAs7irG7LL
ZLOAtAlry+4IifCREMXaatFZ73qWGPsU2RZ4v/l0WTE6tb+Il/z+9VS33tOsQ5F4
hDUqdOnrgVoLXVf5hXePHP8qD1cd0JcjrnnTb3/WuERKYaerE3/ubOgjuM6pkeWX
JMrqWWyZyos=
=caV9
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Jacob Meuser]

On Mon, Sep 26, 2005 at 04:15:11PM +, Olly Betts wrote:
> On 2005-09-23, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> > [ By the way, I don't think everyone in this discussion has subscribed
> > this list; if in doubt, speak up, or even better, set Mail-Followup-To:
> > next time ]
> 
> I'm following it on gmane, but an explicit Cc: isn't a problem.
> 
> > * Jacob Meuser wrote on Fri, Sep 23, 2005 at 04:10:36AM CEST:
> >> just add -lstdc++ manually.  trust me, that works fine.  I really don't
> >> see why libtool should be adding this automatically.
> 
> I did wonder about getting my project's configure to always specifying
> "-lstdc++" if the compiler if GCC (with: test "$GXX" = yes).
> 
> But I worry that I could end up trying to link in two incompatible
> versions of libstdc++ on a machine with multiple GCC installations.

are you saying that on some platforms, you actually get
-L/path/to -lstdc++?  I don't think I've seen that one yet.  certainly
don't see that in the `g++ -shared -v' output you posted before.
so how is libtool going to help with this?

> I don't really want to risk breaking other platforms to get OpenBSD to
> work, especially as I can document a workaround for OpenBSD users:
> 
> make LDFLAGS=-lstdc++
> 
> I could write configure code to detect OpenBSD and add -lstdc++ for
> OpenBSD.  But such system specific tests are generally the wrong
> approach - what if an older or newer version of OpenBSD behaves
> differently?  Writing a configure test which builds a C++ module and C
> client and tries to dlopen the former from the latter would at least fix
> this more generally, but wouldn't work when cross-compiling, and besides
> seems a bit ridiculous when libtool is meant to hide shared library
> portability issues.
> 
> >> is it _always_ needed?  what about -lsupc++?
> >
> > Ahh, very good question.  Here we have an issue: it should be possible
> > to _override_ the decision of libtool to add -lstdc++ on OpenBSD in all
> > cases.  But those cases, in my opinion, would be the exception rather
> > than the rule: they are usually the cause when your package makes use of
> > some system-specifics anyway.  (Maybe there is even a way to detect
> > whether supc++ is preferable over stdc++; I don't know of one, though,
> > and in this case guessing is probably worse than allowing an override.)
> >
> > Can we agree on this somehow?  What other issues, if any, are you
> > experiencing?
> 
> The obvious override mechanism is probably to see if the user specifies
> "-lsupc++" explicitly and not to add -lstdc++ if they have.

what I don't get, is that at one point, libtool assumes the linker
knows what it's doing, and copies it.  but then maybe what it's doing
is not right?

I think perhaps you should ask [EMAIL PROTECTED] about this.  he might
be able to explain why -lstdc++ is not implicitly used in `g++ -shared',
which could give you a good starting point on how to "fix" the
"problem".

-- 
<[EMAIL PROTECTED]>


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On 2005-09-23, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
> I have no statistics for how many shared libraries are written in c++ but do
> not take advantage of the standard c++ library, at a guess I'd say that the
> majority use some libstdc++ features.

It's perhaps worth noting that not linking libstdc++ to a library that
requires it means it fails to dlopen() - a fatal error.  Whereas linking
libstdc++ to a library which only needs libsupc++ just means that it is
linked to a shared library containing more than it needs (AIUI,
libsupc++ is just a very cut down version of libstdc++).

Linking to libstdc++ when you could get away with libsupc++ is
essentially irrelevant if you're running any other dynamically linked
C++ programs.  In fact it's probably slightly better if everything uses
libstdc++ than some use libsupc++!

To me defaulting to C++ pulling in libstdc++ makes most sense, probably
with an ability to override for the minority who don't require it and
care.

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On 2005-09-22, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Olly Betts wrote on Wed, Sep 21, 2005 at 11:00:30PM CEST:
>> The bottom line for me is that if I explicitly add "-lstdc++" when
>> linking _xapian.so, it all works.  If I don't, it doesn't.  So I
>> kind of feel that ideally libtool should be doing that for me...
>
> ACK.  I hate to break libtool on systems I cannot test, when the
> maintainers may have had good reasons to do something slightly
> differently than the default way, though.

I've kindly been given temporary access to on an OpenBSD machine by the
user who reported this issue to me.  If one of the libtool maintainers
would find it useful to be able to test fixes, I can ask if he'd be
willing to give them temporary access too.  Alternatively I can test
fixes.  Or I can work on a fix myself, if there's consensus on what
should be done (I suspect I'll need some help and advice though...)

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On 2005-09-23, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> [ By the way, I don't think everyone in this discussion has subscribed
> this list; if in doubt, speak up, or even better, set Mail-Followup-To:
> next time ]

I'm following it on gmane, but an explicit Cc: isn't a problem.

> * Jacob Meuser wrote on Fri, Sep 23, 2005 at 04:10:36AM CEST:
>> just add -lstdc++ manually.  trust me, that works fine.  I really don't
>> see why libtool should be adding this automatically.

I did wonder about getting my project's configure to always specifying
"-lstdc++" if the compiler if GCC (with: test "$GXX" = yes).

But I worry that I could end up trying to link in two incompatible
versions of libstdc++ on a machine with multiple GCC installations.
I don't really want to risk breaking other platforms to get OpenBSD to
work, especially as I can document a workaround for OpenBSD users:

make LDFLAGS=-lstdc++

I could write configure code to detect OpenBSD and add -lstdc++ for
OpenBSD.  But such system specific tests are generally the wrong
approach - what if an older or newer version of OpenBSD behaves
differently?  Writing a configure test which builds a C++ module and C
client and tries to dlopen the former from the latter would at least fix
this more generally, but wouldn't work when cross-compiling, and besides
seems a bit ridiculous when libtool is meant to hide shared library
portability issues.

>> is it _always_ needed?  what about -lsupc++?
>
> Ahh, very good question.  Here we have an issue: it should be possible
> to _override_ the decision of libtool to add -lstdc++ on OpenBSD in all
> cases.  But those cases, in my opinion, would be the exception rather
> than the rule: they are usually the cause when your package makes use of
> some system-specifics anyway.  (Maybe there is even a way to detect
> whether supc++ is preferable over stdc++; I don't know of one, though,
> and in this case guessing is probably worse than allowing an override.)
>
> Can we agree on this somehow?  What other issues, if any, are you
> experiencing?

The obvious override mechanism is probably to see if the user specifies
"-lsupc++" explicitly and not to add -lstdc++ if they have.

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacob Meuser wrote:
|
| just add -lstdc++ manually.  trust me, that works fine.  I really don't
| see why libtool should be adding this automatically.  is it _always_
| needed?  what about -lsupc++?
|

Apparently, it is not always needed, see:
.


I have no statistics for how many shared libraries are written in c++ but do
not take advantage of the standard c++ library, at a guess I'd say that the
majority use some libstdc++ features.

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQzPjUriDAg3OZTLPAQLLlwQAsUhKKPzk73eqX1+wdOJjpGmy+R6SVGrO
tVB+6iBFiplV2LUsM5iTGp0M4dU7oOQ1sK+LokBaCuzOMytYRkKQsrS9ca2z+obL
3brxglwrjwDC81Vqlw5tj4MqKa/Hi13KO+RkhqhD3gw6leKqdWJZcjdEbtFtHo8P
osYvkCz+H0Q=
=tY8i
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Ralf Wildenhues]

[ By the way, I don't think everyone in this discussion has subscribed
this list; if in doubt, speak up, or even better, set Mail-Followup-To:
next time ]

* Jacob Meuser wrote on Fri, Sep 23, 2005 at 04:10:36AM CEST:
> On Fri, Sep 23, 2005 at 08:41:38AM +0900, Peter O'Gorman wrote:
> > Jacob Meuser wrote:
> > |
> > | but, there was something of a policy decision made to not link libraries
> > | against eachother.  actually, this policy is somewhat under debate, and
> > | the runtime linker is getting a bit of a reworking ...
> > |
> > | as far as why -lstdc++ is not always used, I can't find the reason ATM,
> > | but I do remember some discussion of that at some point.  maybe it's
> > | possible that -lstdc++ is not always necessary for each and every g++
> > | link command?
> > |
> > | knowing that not always using -lstdc++ was a conscious decision, I would
> > | really consider libtool adding -lstdc++ to be a bug.
> > |
> > 
> > Well, we need to find a solution to the original poster's problem (runtime
> > loading a c++ library from a C application), and I don't see another way to
> > do that.
> 
> just add -lstdc++ manually.  trust me, that works fine.  I really don't
> see why libtool should be adding this automatically.

I do.  People can rightly expect linking C++ code to work under both
BSD-like systems as well as GNUish systems as well as, for example,
Solaris/CC where -lstdc++ is spelled "-lCstd -lCrun".  Libtool promises
to keep the normal user from being exposed to these differences.

> is it _always_ needed?  what about -lsupc++?

Ahh, very good question.  Here we have an issue: it should be possible
to _override_ the decision of libtool to add -lstdc++ on OpenBSD in all
cases.  But those cases, in my opinion, would be the exception rather
than the rule: they are usually the cause when your package makes use of
some system-specifics anyway.  (Maybe there is even a way to detect
whether supc++ is preferable over stdc++; I don't know of one, though,
and in this case guessing is probably worse than allowing an override.)

Can we agree on this somehow?  What other issues, if any, are you
experiencing?

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Jacob Meuser]

On Fri, Sep 23, 2005 at 08:41:38AM +0900, Peter O'Gorman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Jacob Meuser wrote:
> |
> | Thorsten's statement is somewhat misleading.  you can definitely link
> | libraries and dlopened modules against libraries without having all
> | those libraries linked directly to the executable.
> |
> | but, there was something of a policy decision made to not link libraries
> | against eachother.  actually, this policy is somewhat under debate, and
> | the runtime linker is getting a bit of a reworking ...
> |
> | as far as why -lstdc++ is not always used, I can't find the reason ATM,
> | but I do remember some discussion of that at some point.  maybe it's
> | possible that -lstdc++ is not always necessary for each and every g++
> | link command?
> |
> | knowing that not always using -lstdc++ was a conscious decision, I would
> | really consider libtool adding -lstdc++ to be a bug.
> |
> 
> Well, we need to find a solution to the original poster's problem (runtime
> loading a c++ library from a C application), and I don't see another way to
> do that.

just add -lstdc++ manually.  trust me, that works fine.  I really don't
see why libtool should be adding this automatically.  is it _always_
needed?  what about -lsupc++?

-- 
<[EMAIL PROTECTED]>


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacob Meuser wrote:
|
| Thorsten's statement is somewhat misleading.  you can definitely link
| libraries and dlopened modules against libraries without having all
| those libraries linked directly to the executable.
|
| but, there was something of a policy decision made to not link libraries
| against eachother.  actually, this policy is somewhat under debate, and
| the runtime linker is getting a bit of a reworking ...
|
| as far as why -lstdc++ is not always used, I can't find the reason ATM,
| but I do remember some discussion of that at some point.  maybe it's
| possible that -lstdc++ is not always necessary for each and every g++
| link command?
|
| knowing that not always using -lstdc++ was a conscious decision, I would
| really consider libtool adding -lstdc++ to be a bug.
|

Well, we need to find a solution to the original poster's problem (runtime
loading a c++ library from a C application), and I don't see another way to
do that.

We'd appreciate as much information about this as possible. I'd better go
google, I suppose :-)

Peter

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQzNBMbiDAg3OZTLPAQJRaQQAkwA0KWuYjDGFKQQnDf9MfkGfH6fszYnq
HQJPadHI1qnxJSm2TEGRcCbl14xJ6nWlw3NfmjB4adORckL7Qz4FrbpI1tEFUk1j
zPPAHCILrnZFxtgOKBj+dr7/Nm0q/Z2IAcpLuZ9nWsQF3v22+ltaTd7t4IdepuS8
EqtfiHhESuo=
=PrkY
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Jacob Meuser]

On Thu, Sep 22, 2005 at 01:58:36PM +0900, Peter O'Gorman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Thorsten Glaser wrote:
> | gcc -shared creates a shared library.
> |
> | On OpenBSD, shared libraries do not link against other shared libraries.
> | The main programme must link against all these.
> 
> Is there a reason for this?

Thorsten's statement is somewhat misleading.  you can definitely link
libraries and dlopened modules against libraries without having all
those libraries linked directly to the executable.

but, there was something of a policy decision made to not link libraries
against eachother.  actually, this policy is somewhat under debate, and
the runtime linker is getting a bit of a reworking ...

as far as why -lstdc++ is not always used, I can't find the reason ATM,
but I do remember some discussion of that at some point.  maybe it's
possible that -lstdc++ is not always necessary for each and every g++
link command?

knowing that not always using -lstdc++ was a conscious decision, I would
really consider libtool adding -lstdc++ to be a bug.

-- 
<[EMAIL PROTECTED]>


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Ralf Wildenhues]

Hi Jacob,

* Jacob Meuser wrote on Thu, Sep 22, 2005 at 01:38:09PM CEST:
> On Wed, Sep 21, 2005 at 10:45:40PM +0200, Ralf Wildenhues wrote:
> > 
> > OK, but this is exactly one thing libtool was designed to do for you:
> > keep track of the libraries you also have to link against; it should
> > have added -lstdc++ to _xapian.la's dependency_libs.
> 
> IIRC, the problem was that we ended up with multiple "-lstdc++"s
> in the actual link commands which caused errors.  The dups happen
> because libtool checks to see what the linker will add, and then
> explicitly adds that stuff, while the linker is still adding stuff
> implicitly.
> 
> I believe this issue was discussed on this list actually, in the
> context of a different OS.

Are you talking about the thread before this mail?
http://lists.gnu.org/archive/html/libtool/2005-08/msg00085.html
If so, then would a change to the linker search algorithm fix the
issues you encountered as well?

> And changing output_verbose_link_command won't fix Olly's problem
> anyway, because as Olly has shown, -lstdc++ doesn't get added by the
> linker when -shared is used.

Well, we can fix it in a different way, as Peter noted as well; the
important thing is that postdeps won't end up empty for C++.  Having it
contain -lstdc++ without the path to whereever the current libstdc++ is
it is still better than nothing in there.

Cheers, and thanks for checking this,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacob Meuser wrote:
| And changing output_verbose_link_command won't fix Olly's problem
| anyway, because as Olly has shown, -lstdc++ doesn't get added by the
| linker when -shared is used.
|

Do we know what the versions of the OS/gcc are where -lstdc++ is missing? We
can enplicitly add it (as we did recently for, I think, sunpro c++). Is this
a gcc bug, or is it by design?

I saw a note somewhere that g++ -shared gives a different result on openbsd
if a pic flag is specified, is that true?

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQzK3+LiDAg3OZTLPAQIObgQAtq4jUOOjKkfRH/iFAa7nAbRxM3o50ize
8/ngImen2LZUs22I9rth2fMGbK7pXt5z7/f0ghgcKf2ylBkQjUGvKbmYziUkpc96
pzHzp7DpDkbjJlj6xtrfHANoVABVwUauya71PLz3qOOrqxGgZ8rb7/xjE7BLst/m
4s6bUubYTfg=
=utTL
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Jacob Meuser]

On Wed, Sep 21, 2005 at 10:45:40PM +0200, Ralf Wildenhues wrote:
> Hi Thorsten,
> 
> * Thorsten Glaser wrote on Wed, Sep 21, 2005 at 10:05:53PM CEST:
> > Olly Betts dixit:
> > >On 2005-09-21, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
> > >> IIRC, archive_cmds on openbsd does not use -nostdlib, so having empty
> > >> postdeps ought to be okay.
> > >
> > >It looks like the problem is that "g++ -shared" doesn't link to libstdc++.
> > 
> > gcc -shared creates a shared library.
> > 
> > On OpenBSD, shared libraries do not link against other shared libraries.
> > The main programme must link against all these.
> 
> OK, but this is exactly one thing libtool was designed to do for you:
> keep track of the libraries you also have to link against; it should
> have added -lstdc++ to _xapian.la's dependency_libs.

IIRC, the problem was that we ended up with multiple "-lstdc++"s
in the actual link commands which caused errors.  The dups happen
because libtool checks to see what the linker will add, and then
explicitly adds that stuff, while the linker is still adding stuff
implicitly.

I believe this issue was discussed on this list actually, in the
context of a different OS.

And changing output_verbose_link_command won't fix Olly's problem
anyway, because as Olly has shown, -lstdc++ doesn't get added by the
linker when -shared is used.

-- 
<[EMAIL PROTECTED]>


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Ralf Wildenhues]

* Olly Betts wrote on Wed, Sep 21, 2005 at 11:00:30PM CEST:
> On Wed, Sep 21, 2005 at 10:45:40PM +0200, Ralf Wildenhues wrote:
> > * Thorsten Glaser wrote on Wed, Sep 21, 2005 at 10:05:53PM CEST:
> > > Olly Betts dixit:
> > > >It looks like the problem is that "g++ -shared" doesn't link to 
> > > >libstdc++.
> > > 
> > > gcc -shared creates a shared library.
> > > 
> > > On OpenBSD, shared libraries do not link against other shared libraries.
> > > The main programme must link against all these.
> 
> Does that apply when using dlopen?

This is another, orthogonal question.  But ltdl.m4:LT_SYS_DLOPEN_DEPLIBS
has
|   openbsd*)
| lt_cv_sys_dlopen_deplibs=yes
| ;;

so I would say yes (or above would need fixing as well).

> When python dlopens _xapian.so, something automatically knows to
> load libxapian.so.8.0 too - so there's definitely a working shared
> library dependency mechanism in this case.

Which confirms the above.

> The bottom line for me is that if I explicitly add "-lstdc++" when
> linking _xapian.so, it all works.  If I don't, it doesn't.  So I
> kind of feel that ideally libtool should be doing that for me...

ACK.  I hate to break libtool on systems I cannot test, when the
maintainers may have had good reasons to do something slightly
differently than the default way, though.

> > OK, but this is exactly one thing libtool was designed to do for you:
> > keep track of the libraries you also have to link against; it should
> > have added -lstdc++ to _xapian.la's dependency_libs.
> 
> It definitely isn't doing that.  This is what I have in _xapian.la:
> 
> dependency_libs=' /home/olly/install/lib/libxapian.la'
> 
> But unless python uses ltdl that wouldn't help me here anyway.

See above.  If lt_cv_sys_dlopen_deplibs were false, then yes, you would
need to use ltdl in order for opening to work.  Plus also the fix for
postdeps.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thorsten Glaser wrote:
| gcc -shared creates a shared library.
|
| On OpenBSD, shared libraries do not link against other shared libraries.
| The main programme must link against all these.

Is there a reason for this?

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQzI5/LiDAg3OZTLPAQK1kwP+JiucDmdq2ufMrVZRwHd948c2+f75WSCA
0xhldTuA0ho2OZR7v67jEbHxS63FkTTMxep3kedQkHZsWOa/GNGz5k0K4OM52tqJ
bRu47GvQuca4oFofYJ9CNBbMqQL4/Ijk/Nl9Jh7zQfoC459mmm6qoFwLsZGb+3a+
w4VpxfPpGag=
=t+pK
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On Wed, Sep 21, 2005 at 10:45:40PM +0200, Ralf Wildenhues wrote:
> * Thorsten Glaser wrote on Wed, Sep 21, 2005 at 10:05:53PM CEST:
> > Olly Betts dixit:
> > >It looks like the problem is that "g++ -shared" doesn't link to libstdc++.
> > 
> > gcc -shared creates a shared library.
> > 
> > On OpenBSD, shared libraries do not link against other shared libraries.
> > The main programme must link against all these.

Does that apply when using dlopen?

When python dlopens _xapian.so, something automatically knows to
load libxapian.so.8.0 too - so there's definitely a working shared
library dependency mechanism in this case.

The bottom line for me is that if I explicitly add "-lstdc++" when
linking _xapian.so, it all works.  If I don't, it doesn't.  So I
kind of feel that ideally libtool should be doing that for me...

> OK, but this is exactly one thing libtool was designed to do for you:
> keep track of the libraries you also have to link against; it should
> have added -lstdc++ to _xapian.la's dependency_libs.

It definitely isn't doing that.  This is what I have in _xapian.la:

dependency_libs=' /home/olly/install/lib/libxapian.la'

But unless python uses ltdl that wouldn't help me here anyway.

Cheers,
Olly


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Ralf Wildenhues]

Hi Thorsten,

* Thorsten Glaser wrote on Wed, Sep 21, 2005 at 10:05:53PM CEST:
> Olly Betts dixit:
> >On 2005-09-21, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
> >> IIRC, archive_cmds on openbsd does not use -nostdlib, so having empty
> >> postdeps ought to be okay.
> >
> >It looks like the problem is that "g++ -shared" doesn't link to libstdc++.
> 
> gcc -shared creates a shared library.
> 
> On OpenBSD, shared libraries do not link against other shared libraries.
> The main programme must link against all these.

OK, but this is exactly one thing libtool was designed to do for you:
keep track of the libraries you also have to link against; it should
have added -lstdc++ to _xapian.la's dependency_libs.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Thorsten Glaser]

Olly Betts dixit:

>On 2005-09-21, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
>> IIRC, archive_cmds on openbsd does not use -nostdlib, so having empty
>> postdeps ought to be okay.
>
>It looks like the problem is that "g++ -shared" doesn't link to libstdc++.

gcc -shared creates a shared library.

On OpenBSD, shared libraries do not link against other shared libraries.
The main programme must link against all these.

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Brad]

On Wed, Sep 21, 2005 at 05:05:53PM +0200, Ralf Wildenhues wrote:
> * Peter O'Gorman wrote on Wed, Sep 21, 2005 at 11:31:58AM CEST:
> > Ralf Wildenhues wrote:
> > |
> > | Probably libtool needs to be adjusted (on OpenBSD,
> > | output_verbose_link_cmd is set to `echo' in the C++ case).
> > |
> > | Brad, you changed this with this patch:
> > | http://lists.gnu.org/archive/html/libtool-patches/2004-07/msg0.html
> > | and presumably for good reason.  However, I could not find the
> > | corresponding discussion by searching of web archives.  Unfortunately, I
> > | don't have access to OpenBSD, either, at the moment, to test myself.
> 
> > IIRC, archive_cmds on openbsd does not use -nostdlib, so having empty
> > postdeps ought to be okay.
> 
> Good point.
> 
> > Olly may have found that it is not okay though :(
> 
> Olly, can you show us the libtool link line that fails, plus the output
> it generates (you can probably cut off after the first ten or so
> errors to keep size down).
> 
> Thanks,
> Ralf

Unfortunately I don't remember the details at the moment but I know that we ran
into a number of linking issues with C++ based programs if 
output_verbose_link_cmd
was left as is. Issues that our linker seemed to deal with just fine without 
libtool
trying to explicitly doing something. I'll see if I can dig up any clues.


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On Wed, Sep 21, 2005 at 05:05:53PM +0200, Ralf Wildenhues wrote:
> Olly, can you show us the libtool link line that fails, plus the output
> it generates (you can probably cut off after the first ten or so
> errors to keep size down).

The libtool link doesn't fail.  The failure comes when Python tries to
dlopen the resulting module.

Here's the libtool link line (from the output from "make"):

/bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -Wno-unused 
-Wno-uninitialized  -g -I/home/olly/install/include   -o _xapian.la -rpath 
/usr/local/lib/python2.3/site-packages -avoid-version -module -no-undefined 
xapian_wrap.lo /home/olly/install/lib/libxapian.la
rm -fr  .libs/_xapian.la .libs/_xapian.lai .libs/_xapian.so
g++ -shared  -fPIC -DPIC   .libs/xapian_wrap.o  -L/home/olly/install/lib 
-lxapian   -o .libs/_xapian.so
creating _xapian.la
(cd .libs && rm -f _xapian.la && ln -s ../_xapian.la _xapian.la)

And here's the error when Python tries to load it:

$ PYTHONPATH=/home/olly/xb-install-tmp:. python -c 'import xapian'
python:/usr/local/lib/libxapian.so.8.0: undefined symbol '_ZTISi'
python: /usr/local/lib/libxapian.so.8.0: can't resolve reference '_ZTISi'
python:/usr/local/lib/libxapian.so.8.0: undefined symbol '_ZTISi'
python: /usr/local/lib/libxapian.so.8.0: can't resolve reference '_ZTISi'
python:/usr/local/lib/libxapian.so.8.0: undefined symbol '_ZTISi'
python: /usr/local/lib/libxapian.so.8.0: can't resolve reference '_ZTISi'
python:/usr/local/lib/libxapian.so.8.0: undefined symbol '_ZNSiD1Ev'
python: /usr/local/lib/libxapian.so.8.0: can't resolve reference '_ZNSiD1Ev'
[And lots more!]

Demangling with c++filt, "_ZTISi" is "typeinfo for std::basic_istream >".  The other symbols are all C++ STL stuff too
from what I could see.

Cheers,
Olly


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On 2005-09-21, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
> IIRC, archive_cmds on openbsd does not use -nostdlib, so having empty
> postdeps ought to be okay.

It looks like the problem is that "g++ -shared" doesn't link to libstdc++.
Here's the output from my original message (except wrapped for your viewing
pleasure):

  g++ -shared -v /dev/null 2>&1|grep "\-L"

  [...]

  On an x86 OpenBSD 3.7 box with g++ 3.3.5 this gives:

   /usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5/collect2 --eh-frame-hdr
 -shared -Bdynamic -dynamic-linker /usr/libexec/ld.so /usr/lib/crtbeginS.o
 -L/usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5 /dev/null -lsupc++ -lgcc
 -lgcc /usr/lib/crtendS.o

  Note: -lsupc++ instead of -lstdc++.

Without the -shared, the output *does* contain -lstdc++.

So using "g++ -shared" to do the link means my module doesn't depend on
libstdc++.  With dlopen from a C++ program that would be OK, as the program
would pull in libstdc++, but dlopen from a C program fails.

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Ralf Wildenhues]

* Peter O'Gorman wrote on Wed, Sep 21, 2005 at 11:31:58AM CEST:
> Ralf Wildenhues wrote:
> |
> | Probably libtool needs to be adjusted (on OpenBSD,
> | output_verbose_link_cmd is set to `echo' in the C++ case).
> |
> | Brad, you changed this with this patch:
> | http://lists.gnu.org/archive/html/libtool-patches/2004-07/msg0.html
> | and presumably for good reason.  However, I could not find the
> | corresponding discussion by searching of web archives.  Unfortunately, I
> | don't have access to OpenBSD, either, at the moment, to test myself.

> IIRC, archive_cmds on openbsd does not use -nostdlib, so having empty
> postdeps ought to be okay.

Good point.

> Olly may have found that it is not okay though :(

Olly, can you show us the libtool link line that fails, plus the output
it generates (you can probably cut off after the first ten or so
errors to keep size down).

Thanks,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralf Wildenhues wrote:
|
| Probably libtool needs to be adjusted (on OpenBSD,
| output_verbose_link_cmd is set to `echo' in the C++ case).
|
| Brad, you changed this with this patch:
| http://lists.gnu.org/archive/html/libtool-patches/2004-07/msg0.html
| and presumably for good reason.  However, I could not find the
| corresponding discussion by searching of web archives.  Unfortunately, I
| don't have access to OpenBSD, either, at the moment, to test myself.
|
| Could you be bothered to look at this issue?

IIRC, archive_cmds on openbsd does not use -nostdlib, so having empty
postdeps ought to be okay.

Olly may have found that it is not okay though :(

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQzEojbiDAg3OZTLPAQLgZgP/Xb3mgWsyw8Z0BFTs+UqU0tFoLE1+JoHP
ncNdbfbghMjX2poqHyqKrUTcC7Rfvlp4SNfW1h50NkNBIemLqXC3qal83aBmeTOo
LrLsmBijJpdEZLJDqgHQSb9LQWX95PQaU1LDiT2LEIM3RlzWYwirXXbSEJ4I8zds
tnnjzooiVO8=
=m1k8
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Ralf Wildenhues]

Hi Olly, Brad,

[ quoting generously for the benefit of Brad; this thread is also at
http://lists.gnu.org/archive/html/libtool/2005-09/msg00070.html ]

* Olly Betts wrote on Tue, Sep 20, 2005 at 08:08:40PM CEST:
> I'm trying to link C++ code into a shared object for use as a Python
> module.  I'm using libtool to do the linking.  On Linux this works
> well, but on OpenBSD it fails with lots of C++ library symbols not
> found.
> 
> The problem seems to be that on OpenBSD the shared object doesn't
> pull in libstdc++.  Python isn't written in C++, so doesn't pull in
> libstdc++ either.
> 
> I've found that if I explicitly link with -lstdc++ then it works on
> OpenBSD, which supports this theory.  I could potentially just always
> explicitly link with -lstdc++, but I'm concerned that this could try
> to link in two different versions on a machine with multiple compilers
> installed.
> 
> Comparing the generated libtool scripts on the 2 systems, I've noticed
> that postdeps is empty on OpenBSD.  On Linux it is:
> 
> postdeps="-lstdc++ -lm -lgcc -lc -lgcc"
> 
> So this would seem to be on the right track.
> 
> I don't entirely follow the logic which generates this, but it seems
> to come from the output of something like:
> 
> g++ -shared -v /dev/null 2>&1|grep "\-L"
> 
> On an x86 Linux box (Debian unstable) with g++ 3.3.6 this gives:
> 
>  /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/collect2 --eh-frame-hdr -m 
> elf_i386 -shared /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crti.o 
> /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/crtbeginS.o 
> -L/usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6 -L/usr/bin/../lib/gcc-lib 
> -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6 
> -L/usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. 
> -L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. /dev/null -lstdc++ -lm 
> -lgcc_s -lc -lgcc_s /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/crtendS.o 
> /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crtn.o
> 
> On an x86 OpenBSD 3.7 box with g++ 3.3.5 this gives:
> 
>  /usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5/collect2 --eh-frame-hdr 
> -shared -Bdynamic -dynamic-linker /usr/libexec/ld.so /usr/lib/crtbeginS.o 
> -L/usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5 /dev/null -lsupc++ -lgcc 
> -lgcc /usr/lib/crtendS.o
> 
> Note: -lsupc++ instead of -lstdc++.
> 
> If I remove the "-shared" on OpenBSD I get -lstdc++ instead of -lsupc++.
> 
> I don't know if it's relevant, but both systems have shared and static 
> versions
> of libstdc++, but only static versions of libsupc++ and libgcc.  The Linux
> system has a shared (only) libgcc_s, but the OpenBSD system doesn't have this
> at all.
> 
> Is this a libtool issue, or should I be looking elsewhere?

Probably libtool needs to be adjusted (on OpenBSD,
output_verbose_link_cmd is set to `echo' in the C++ case). 

Brad, you changed this with this patch:
http://lists.gnu.org/archive/html/libtool-patches/2004-07/msg0.html
and presumably for good reason.  However, I could not find the
corresponding discussion by searching of web archives.  Unfortunately, I
don't have access to OpenBSD, either, at the moment, to test myself.

Could you be bothered to look at this issue?

Thanks,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On Tue, Sep 20, 2005 at 01:51:28PM -0500, Bob Friesenhahn wrote:
> If you are using the C++ standard library, there are things going on 
> that you are normally blissfully unaware of.  These may use static 
> initialization.

Fair enough, a C++ Python module may simply not work on some platforms.
But static initialisation does work on a number of platforms in this
situation, including both Linux and OpenBSD (I've just written a small
testcase to actually check).

But we seem to have strayed from the problem I actually have (into
problems I might potentially have!)

Should libtool be able to link a C++ module such that it can be
dlopen-ed by a C program (on platforms where this can be made to work)?

Cheers,
Olly


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Olly Betts]

On Tue, Sep 20, 2005 at 01:30:37PM -0500, Bob Friesenhahn wrote:
> On Tue, 20 Sep 2005, Olly Betts wrote:
> 
> >I'm trying to link C++ code into a shared object for use as a Python
> >module.  I'm using libtool to do the linking.  On Linux this works
> >well, but on OpenBSD it fails with lots of C++ library symbols not
> >found.
> 
> You may encounter more problems even after a successful link.  The 
> problem is that static initialization (including initializing C++ 
> exception support) may not be done correctly for C++ code loaded by a 
> C program.

Thanks for the warning.

I've carefully avoided creating static objects, so at least that
shouldn't be a problem.  And exceptions are at least only thrown
in exceptional circumstances...

> It should help to use the C++ compiler to do the link rather than a C 
> compiler.

I'm using libtool to link, and it uses a C++ compiler to do the link
(at least in these two cases).

Cheers,
Olly


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Bob Friesenhahn]

On Tue, 20 Sep 2005, Olly Betts wrote:


Should libtool be able to link a C++ module such that it can be
dlopen-ed by a C program (on platforms where this can be made to work)?


Yes.  Any libraries necessary for C++ programs should be applied when 
linking using the C++ compiler.  It seems that you have encountered a 
case where the wrong libraries are used.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Bob Friesenhahn]

On Tue, 20 Sep 2005, Olly Betts wrote:


I've carefully avoided creating static objects, so at least that
shouldn't be a problem.  And exceptions are at least only thrown
in exceptional circumstances...


If you are using the C++ standard library, there are things going on 
that you are normally blissfully unaware of.  These may use static 
initialization.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: postdeps empty on OpenBSD

[Bob Friesenhahn]

On Tue, 20 Sep 2005, Olly Betts wrote:


I'm trying to link C++ code into a shared object for use as a Python
module.  I'm using libtool to do the linking.  On Linux this works
well, but on OpenBSD it fails with lots of C++ library symbols not
found.


You may encounter more problems even after a successful link.  The 
problem is that static initialization (including initializing C++ 
exception support) may not be done correctly for C++ code loaded by a 
C program.


It should help to use the C++ compiler to do the link rather than a C 
compiler.


Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/


___
http://lists.gnu.org/mailman/listinfo/libtool

postdeps empty on OpenBSD

[Olly Betts]

I'm trying to link C++ code into a shared object for use as a Python
module.  I'm using libtool to do the linking.  On Linux this works
well, but on OpenBSD it fails with lots of C++ library symbols not
found.

The problem seems to be that on OpenBSD the shared object doesn't
pull in libstdc++.  Python isn't written in C++, so doesn't pull in
libstdc++ either.

I've found that if I explicitly link with -lstdc++ then it works on
OpenBSD, which supports this theory.  I could potentially just always
explicitly link with -lstdc++, but I'm concerned that this could try
to link in two different versions on a machine with multiple compilers
installed.

Comparing the generated libtool scripts on the 2 systems, I've noticed
that postdeps is empty on OpenBSD.  On Linux it is:

postdeps="-lstdc++ -lm -lgcc -lc -lgcc"

So this would seem to be on the right track.

I don't entirely follow the logic which generates this, but it seems
to come from the output of something like:

g++ -shared -v /dev/null 2>&1|grep "\-L"

On an x86 Linux box (Debian unstable) with g++ 3.3.6 this gives:

 /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/collect2 --eh-frame-hdr -m 
elf_i386 -shared /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crti.o 
/usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/crtbeginS.o 
-L/usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6 -L/usr/bin/../lib/gcc-lib 
-L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6 
-L/usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. 
-L/usr/lib/gcc-lib/i486-linux-gnu/3.3.6/../../.. /dev/null -lstdc++ -lm -lgcc_s 
-lc -lgcc_s /usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/crtendS.o 
/usr/bin/../lib/gcc-lib/i486-linux-gnu/3.3.6/../../../crtn.o

On an x86 OpenBSD 3.7 box with g++ 3.3.5 this gives:

 /usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5/collect2 --eh-frame-hdr -shared 
-Bdynamic -dynamic-linker /usr/libexec/ld.so /usr/lib/crtbeginS.o 
-L/usr/lib/gcc-lib/i386-unknown-openbsd3.7/3.3.5 /dev/null -lsupc++ -lgcc -lgcc 
/usr/lib/crtendS.o

Note: -lsupc++ instead of -lstdc++.

If I remove the "-shared" on OpenBSD I get -lstdc++ instead of -lsupc++.

I don't know if it's relevant, but both systems have shared and static versions
of libstdc++, but only static versions of libsupc++ and libgcc.  The Linux
system has a shared (only) libgcc_s, but the OpenBSD system doesn't have this
at all.

Is this a libtool issue, or should I be looking elsewhere?

And please say if I need to provide more information.  I don't have a small
example showing the problem, though I can work on one if that's helpful.

Cheers,
Olly



___
http://lists.gnu.org/mailman/listinfo/libtool