subject:"\"libtool\""

Bob Friesenhahn  writes:
> On Sat, 7 Jan 2012, Russ Allbery wrote:

>> Do you mean for detecting other libraries?  Only for libraries without
>> pkg-config support.

> For detecting library features such as the availabilty of functions.

Yes, it deals with that fine.  Not that that's really on-topic, since I'm
not advocating everyone use pkg-config.

> Except that libtool is already embedded (in one vintage or another) in
> the source code of perhaps 5000 (???) different packages.  This makes
> the pace of change somewhat glacial.

So?  New versions are still being released, and people eventually upgrade.
I didn't say that we could resolve this problem overnight.  But I
guarantee it won't ever get fixed if, every time it comes up, the response
is negativity and defeatism about why it can't be fixed.

It's frustrating that GNU/Linux distributions have to drop *.la files
completely, dropping the other features that Libtool could be providing,
because of this ongoing issue.  Yes, it's not a trivial problem to solve
and it requires some thought about how to specify new linking semantics in
different situations, combined with detection of when one is in those
situations, but it's not impossible.

> Believe it or not, there are still people who download source packages
> and install software by building it from source code, or who develop new
> software from scratch, or by modifying existing source code.  Due to
> this, the pristine environment that the GNU/Linux distribution package
> maintainer is aware of is not necessarily representative of the user's
> system, or the user's intentions.  Given the principles of free
> software, we should not assume that software users will only get the
> software via carefully-prepared and managed binary packages provided by
> an OS distribution.

I don't see what this have to do with the library maintainer knowing
whether or not, for systems with ELF transitive dependency closure,
clients of their libraries should be linked with other libraries or can be
linked only with their library.  This is not a system-specific property,
nor is it something that is unknowable outside of a developer's
environment.

It does take some education of library maintainers on the issues, and
there have, of course, been bugs in pkg-config files.  But they get dealt
with.  It's really not that horribly hard of a problem for most libraries.
For nearly all libraries, in the pkg-config world, you can just put the
library itself in Libs and the libraries it links with in Libs.private.
There are some situations where you have to do something more complex, but
those are normally libraries that are more complex and have more expert
maintainers.

> Autotools needs to satisfy the requirements of completely different
> types of users.  This means that it still needs to work (best-effort) if
> pkg-config offers up some wrong (perhaps stale) information, or if the
> user has several independent (or complimentary) pkg-config installations
> on his system.  It also needs to work if pkg-config is not available at
> all.

Of course.  I think you've lost track of what I'm talking about.  I'm
pointing to pkg-config as a system that people have used to solve this
problem as something from which Libtool could pull ideas for how to fix
this problem in Libtool.  It doesn't make any sense to worry about
pkg-config files being stale or out of date in that context; the point is
that this would be incorporated into Libtool as a feature.

In doing so, I think there's some appeal in looking at the pkg-config file
format and seeing if the *.la file format could be merged with it, but
that was just an aside and is not something I feel strongly about.

> I feel that I may have gotten a bit off track here, but it should be
> clear that libtool needs to err towards the most reliable mechanisms by
> default (the software should build and work by default if at all
> possible) but also provide the features that distribution maintainers
> need.

Of course.  I've never advocated anything different.

-- 
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

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

Re: Several questions about libtool

2012-01-07 Thread Bob Friesenhahn


On Sat, 7 Jan 2012, Russ Allbery wrote:



Regardless, Autoconf's configure will still make subsequent decisions
based on trial and error (by running the compiler and linker).


Do you mean for detecting other libraries?  Only for libraries without
pkg-config support.  You of course can't solve the whole problem


For detecting library features such as the availabilty of functions.

Over the years, Autoconf principles have not changed much.  It could 
have usefully absorbed knowledge of libtool and its installed .la 
files (but it did not).



Pkg-config is optional software which only really works when it is
properly cared for and fed correctly.


The same is true of Libtool.  :)


Except that libtool is already embedded (in one vintage or another) in 
the source code of perhaps 5000 (???) different packages.  This makes 
the pace of change somewhat glacial.



My impression is that you don't want to try to do this with magic, because
the magic will occasionally be wrong.  That's the advantage of the
pkg-config method.  It lets the library maintainer, who actually knows
what's going on, specify the desired behavior.


The distribution library maintainer only knows what is going on from 
within his own limited sphere of influence.  Once the package is 
finally installed on a user's system, there is no telling what might 
happen after that.  The "user" might be the developer of the library 
that the distribution library maintainer prepares as a binary package.


Believe it or not, there are still people who download source packages 
and install software by building it from source code, or who develop 
new software from scratch, or by modifying existing source code.  Due 
to this, the pristine environment that the GNU/Linux distribution 
package maintainer is aware of is not necessarily representative of 
the user's system, or the user's intentions.  Given the principles of 
free software, we should not assume that software users will only get 
the software via carefully-prepared and managed binary packages 
provided by an OS distribution.  We should encourage people to 
actively edit source code and develop more free software or else the 
free software movement will eventually terminate by quenching the 
innovation which spawned it.  Free software should not fall victim to 
its own success.


Autotools needs to satisfy the requirements of completely different 
types of users.  This means that it still needs to work (best-effort) 
if pkg-config offers up some wrong (perhaps stale) information, or if 
the user has several independent (or complimentary) pkg-config 
installations on his system.  It also needs to work if pkg-config is 
not available at all.


You are correct that I don't put much faith in magic. :-)

I feel that I may have gotten a bit off track here, but it should be 
clear that libtool needs to err towards the most reliable mechanisms 
by default (the software should build and work by default if at all 
possible) but also provide the features that distribution maintainers 
need.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

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

Re: Several questions about libtool

Bob Friesenhahn  writes:
> On Sat, 7 Jan 2012, Russ Allbery wrote:

>> pkg-config is an excellent example of an alternative way of handling
>> this that does not have this problem, and it includes Autoconf support.

> What do you mean by "it includes Autoconf support".  Do you mean that it
> provides an Autoconf macro which makes pkg-config easier to use?

Yes.

> Regardless, Autoconf's configure will still make subsequent decisions
> based on trial and error (by running the compiler and linker).

Do you mean for detecting other libraries?  Only for libraries without
pkg-config support.  You of course can't solve the whole problem
overnight, but there's quite a bit of movement towards pkg-config support
already, including in a bunch of low-level libraries that lots of things
use.

Subsequent probes that need to link with the library can use the shell
variables set by pkg-config.

> They may seem like they do the same thing but perhaps they do 20-30% of
> the same thing (e.g. dependency info).  The .la files used in the build
> tree are very much needed since it is unlikely that builds will work at
> all without them (and libtool needs them).

I didn't say that pkg-config and Libtool did the same thing.  I said that
pkg-config configuration files and Libtool *.la files do largely the same
thing, namely store metadata about libraries.  pkg-config configuration
files are simple key-value structures, and the additional information that
Libtool needs to do the correct thing inside the build tree would not be
difficult to represent in that format so far as I can tell.  In fact, I
think pkg-config would benefit from tracking some of the additional
information that Libtool *.la files track.

Or one can of course just add the same separation of dependency
information to the Libtool *.la file format.  It just seems unnecessary to
have two file formats for doing the same thing, and the pkg-config file
format is somewhat nicer.  But this is all implementation details; I don't
really care which way the information is represented.

> Pkg-config is optional software which only really works when it is
> properly cared for and fed correctly.

The same is true of Libtool.  :)

> The obvious "solution" is that there should be a mode in which libtool
> does not apply any ".la" dependency libraries from an installed .la file
> unless they are known to be static libraries, or static libraries are
> otherwise involved.

I don't think you can just drop all dependencies for shared libraries,
because some shared libraries do want the client to link with a dependent
library for various complicated reasons.  GTK+ and GDK are the most
frequently cited example.

My impression is that you don't want to try to do this with magic, because
the magic will occasionally be wrong.  That's the advantage of the
pkg-config method.  It lets the library maintainer, who actually knows
what's going on, specify the desired behavior.

-- 
Russ Allbery (r...@stanford.edu)     <http://www.eyrie.org/~eagle/>

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

Re: Several questions about libtool

2012-01-07 Thread Bob Friesenhahn


On Sat, 7 Jan 2012, Russ Allbery wrote:


Bob Friesenhahn  writes:


I think that it is wrong to solely blame libtool for this state of
affairs.  In order for a project to work properly on non-ELF systems, or
where installed shared libraries have abbreviated/truncated ELF implicit
dependencies, or where static libraries are involved, the project needs
to add all dependencies to LIBS during the configure run.


pkg-config is an excellent example of an alternative way of handling this
that does not have this problem, and it includes Autoconf support.


What do you mean by "it includes Autoconf support".  Do you mean that 
it provides an Autoconf macro which makes pkg-config easier to use?


Regardless, Autoconf's configure will still make subsequent decisions 
based on trial and error (by running the compiler and linker).



One interesting possible solution to this problem would be to eliminate
Libtool *.la files in favor of pkg-config or something similar, rather
than continuing to maintain two different mechanisms for doing largely the
same thing.


They may seem like they do the same thing but perhaps they do 20-30% 
of the same thing (e.g. dependency info).  The .la files used in the 
build tree are very much needed since it is unlikely that builds will 
work at all without them (and libtool needs them).



I do agree that a tool can help solve these issues.  The linker itself
is in the best position to know which library dependencies are really
needed and to skip those which are not.


It turns out that this is harder than it looks.  --as-needed causes
obscure failures in places where the dependency really is needed although
the linker can't figure that out.


I suspected as much.


The pkg-config solution allows the maintainer of the library to declare
the necessary behavior for both cases: working transitive dependency
resolution, and situations where this cannot be relied upon.  The build
system then chooses based on the situation.


Pkg-config is optional software which only really works when it is 
properly cared for and fed correctly.  Autotools (as currently 
defined) can not depend on it.  However, we need to determine if there 
is some way that libtool can work better for modern ELF platforms 
using only shared libraries while still supporting portability 
requirements, and use with static libraries.


The obvious "solution" is that there should be a mode in which libtool 
does not apply any ".la" dependency libraries from an installed .la 
file unless they are known to be static libraries, or static libraries 
are otherwise involved.  The various .la files listed in 
dependency_libs would need to be inspected to see if a shared or 
static library would be used.  If any static library would be used, 
then all of the library dependencies would still need to be applied 
out of fear that the static library depends on a symbol in a shared 
library.


Since GNU/Linux disributions have taken the approach of stripping all 
.la files from the distribution, the above approach becomes more risky 
to implement.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

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

Re: Several questions about libtool

Bob Friesenhahn  writes:

> I think that it is wrong to solely blame libtool for this state of
> affairs.  In order for a project to work properly on non-ELF systems, or
> where installed shared libraries have abbreviated/truncated ELF implicit
> dependencies, or where static libraries are involved, the project needs
> to add all dependencies to LIBS during the configure run.

pkg-config is an excellent example of an alternative way of handling this
that does not have this problem, and it includes Autoconf support.

One interesting possible solution to this problem would be to eliminate
Libtool *.la files in favor of pkg-config or something similar, rather
than continuing to maintain two different mechanisms for doing largely the
same thing.

> I do agree that a tool can help solve these issues.  The linker itself
> is in the best position to know which library dependencies are really
> needed and to skip those which are not.

It turns out that this is harder than it looks.  --as-needed causes
obscure failures in places where the dependency really is needed although
the linker can't figure that out.

The pkg-config solution allows the maintainer of the library to declare
the necessary behavior for both cases: working transitive dependency
resolution, and situations where this cannot be relied upon.  The build
system then chooses based on the situation.

-- 
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

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

Re: Several questions about libtool

2012-01-07 Thread Bob Friesenhahn


On Sat, 7 Jan 2012, Russ Allbery wrote:


I wouldn't argue for breaking Libtool's ability to handle such platforms,
or for that matter old UNIX platforms that don't support transitive
resolution of shared library dependencies.  But I think Libtool needs some
mechanism to correctly support platforms where adding spurious NEEDED ELF
metadata is wrong and causes serious issues for distributions.  The
pkg-config approach seems to work reasonably well in practice.


I think that it is wrong to solely blame libtool for this state of 
affairs.  In order for a project to work properly on non-ELF systems, 
or where installed shared libraries have abbreviated/truncated ELF 
implicit dependencies, or where static libraries are involved, the 
project needs to add all dependencies to LIBS during the configure 
run.  This is well before libtool is even involved.  If configure 
scripts do not do this, then linker errors (due to missing libraries) 
will block tests for symbols and library features.


Because of the need to extend LIBS in configure, and because of the 
desire to support more systems than just GNU/Linux (or ELF-based 
systems which behave similarly) many carefully-maintained projects are 
already requesting/applying far more libraries than would be necessary 
to link the application/library under GNU/Linux.  My own project is a 
good example of this.


The library-dependency problems are more complex than they have been 
made out to be since they are due to responsible-project behavior and 
not only due to excessively-pedantic libtool behavior.


I do agree that a tool can help solve these issues.  The linker itself 
is in the best position to know which library dependencies are really 
needed and to skip those which are not.


Libltdl's automatic loading of dependency libraries based on the 
content of .la files is a secondary issue to be addressed.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

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

Re: Several questions about libtool

Peter Rosin  writes:
> Russ Allbery skrev 2012-01-07 03:13:

>> Of which there are very few still in existence in terms of widespread
>> use, since most systems now use ELF or (like Mac OS X) some other
>> object format that doesn't require this.  Solaris is definitely not one
>> of them.  I believe you may still need this on such platforms as AIX or
>> HP-UX that use a much different object format, but I'm not at all
>> certain of that; it's been years since I've used them.

> You are somehow forgetting Windows, probably the most widespread system
> of them all.  On Windows, you have to specify all libraries at link time
> and Libtool helps with that.

Indeed, I did forget Windows.  (Although while it's the most widespread
system of them all, it's a small fraction of the platforms on which people
use Libtool on a day-to-day basis.)

I wouldn't argue for breaking Libtool's ability to handle such platforms,
or for that matter old UNIX platforms that don't support transitive
resolution of shared library dependencies.  But I think Libtool needs some
mechanism to correctly support platforms where adding spurious NEEDED ELF
metadata is wrong and causes serious issues for distributions.  The
pkg-config approach seems to work reasonably well in practice.

-- 
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

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

Re: Several questions about libtool

2012-01-07 Thread Peter Rosin

Russ Allbery skrev 2012-01-07 03:13:
> Bob Friesenhahn  writes:
>> Libtool's mode of operation works with static builds and on systems
>> where all libraries have to be supplied at link time.
> 
> Of which there are very few still in existence in terms of widespread use,
> since most systems now use ELF or (like Mac OS X) some other object format
> that doesn't require this.  Solaris is definitely not one of them.  I
> believe you may still need this on such platforms as AIX or HP-UX that use
> a much different object format, but I'm not at all certain of that; it's
> been years since I've used them.

You are somehow forgetting Windows, probably the most widespread system of
them all.  On Windows, you have to specify all libraries at link time and
Libtool helps with that.

Cheers,
Peter

_______
https://lists.gnu.org/mailman/listinfo/libtool

Re: Several questions about libtool

2012-01-06 Thread Peter O'Gorman


On 01/06/2012 12:31 PM, Peter O'Gorman wrote:

On 01/06/2012 11:21 AM, Stepan Kasal wrote:


1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recursive resolution
(which is the case on GNU/Linux distributions for many years).
(I believe that the rule that forbids packing .la files to -dev and
-devel subpackages on Debian and Fedora (respectively), is there just
to work around this problem.)


This is still an issue, libtool always adds all dependencies. Many
packages assume this and don't explicitly add required dependencies to
Makefile.am etc. I don't recall the arguments for not changing this when
building shared. IIRC Scott tried to include Debian's patch at some
point. I'll look it up in the archives later.


http://lists.gnu.org/archive/html/libtool/2004-11/msg00455.html

http://lists.gnu.org/archive/html/libtool/2004-12/msg00259.html

http://lists.gnu.org/archive/html/libtool/2004-12/msg00029.html

http://lists.gnu.org/archive/html/libtool/2007-09/msg00017.html

And from you, no response given:

http://lists.gnu.org/archive/html/libtool/2008-01/msg3.html

Peter


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

Re: Several questions about libtool

2012-01-06 Thread Russ Allbery

Russ Allbery  writes:

> I don't believe this is correct.  GNU/Linux does not add implicit
> dependencies at link time; it only links with the libraries that you
> explicitly list.  ELF doesn't require that all symbols be resolved during
> the link, only the symbols in the thing that you're linking.

And, I should add, it's not necessarily the case that even this is
required, although that varies.  The default on GNU/Linux is to not care
about unresolved symbols in shared libraries (but to care about them in
executables).  So you can generate a shared library that can't be used
without linking with other shared libraries.  But this is certainly not
good practice; the behavior is there to support dynamically loadable
modules that should have unresolved symbols that are resolved by the
binary that's loading them, such as Apache modules.  Shared libraries
should always be linked with all libraries that they use *directly* (and
should never be linked with libraries that they use only indirectly) on
ELF systems with proper run-time linker support for transitive NEEDED
(which I believe is all of them in common use).

-- 
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

_______
https://lists.gnu.org/mailman/listinfo/libtool

Re: Several questions about libtool

2012-01-06 Thread Russ Allbery

Bob Friesenhahn  writes:
> On Fri, 6 Jan 2012, Peter O'Gorman wrote:

>> This is still an issue, libtool always adds all dependencies. Many
>> packages assume this and don't explicitly add required dependencies to
>> Makefile.am etc. I don't recall the arguments for not changing this
>> when building shared. IIRC Scott tried to include Debian's patch at
>> some point. I'll look it up in the archives later.

> Some systems (e.g. GNU Linux) add library implicit dependencies at link
> time while others (e.g. Solaris) only seem to add them at run-time and
> will fail to link if the dependencies are not also listed.

I don't believe this is correct.  GNU/Linux does not add implicit
dependencies at link time; it only links with the libraries that you
explicitly list.  ELF doesn't require that all symbols be resolved during
the link, only the symbols in the thing that you're linking.  This
behavior is, so far as I know, the same on both GNU/Linux and on Solaris.

On an ELF system, if linking fails, that means that what you're trying to
link references symbols in a library that you're not including, not that
one of the libraries that you link against has unreferenced symbols.  ELF
build-time linkers should not care about the latter; that's handled by the
runtime loader.

> Some systems require that no symbols remain unresolved in order to
> produce a shared library.

This refers only to the binary or shared library itself, not by symbols
used by shared libraries that it depends on.

> Libtool's mode of operation works with static builds and on systems
> where all libraries have to be supplied at link time.

Of which there are very few still in existence in terms of widespread use,
since most systems now use ELF or (like Mac OS X) some other object format
that doesn't require this.  Solaris is definitely not one of them.  I
believe you may still need this on such platforms as AIX or HP-UX that use
a much different object format, but I'm not at all certain of that; it's
been years since I've used them.

-- 
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

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

Re: Several questions about libtool

2012-01-06 Thread Robert Boehne

These questions are quite common, and what they really come down to is that
many (or most) users want to solve a *different problem* than the one that
Libtool was designed to solve.

Libtool will deal with the platform specific vagaries of shared libraries
in a uniform manner.  It isn't designed to easily expose features of *some*
specific shared library implementions, but attempts to support the largest
common subset of features.
If you have a fairly simple packge that includes libraries, you may be able
to build & run it on CygWin with no changes (for example), and that is what
Libtool was designed to do.

Some that you mention below could be dealt with by adding them as new
features.

On Fri, Jan 6, 2012 at 12:31 PM, Peter O'Gorman  wrote:

> On 01/06/2012 11:21 AM, Stepan Kasal wrote:
>
>>
>> 1) .la file always contains the recursively evaluated list of libraries.
>> While this is necessary for static linking and dumb dynamic linkers,
>> it is an issue for dyn. linkers that can do recursive resolution
>> (which is the case on GNU/Linux distributions for many years).
>> (I believe that the rule that forbids packing .la files to -dev and
>> -devel subpackages on Debian and Fedora (respectively), is there just
>> to work around this problem.)
>>
>
> This is still an issue, libtool always adds all dependencies. Many
> packages assume this and don't explicitly add required dependencies to
> Makefile.am etc. I don't recall the arguments for not changing this when
> building shared. IIRC Scott tried to include Debian's patch at some point.
> I'll look it up in the archives later.
>
>
> Overlinking when using shared libraries is not a good thing, and Libtool
could be modified to have a list of all dependencies for the static case,
but when the platform supports it, it could also have a list with only the
first level of dependencies.


>> 2) People told me libtool is slow and shell has to parse huge script
>> just to find out that it has to call gcc twice, with and without
>> -fPIC.  Again, this is not about the general portability case, it is
>> a request for optimization on GNU/Linux platform, that they percepts
>> as one of the major customers of libtool.
>>
>
> Libtool is faster than it used to be, the shell does have to parse quite a
> bit of script, but compile mode has been moved as close to the beginning of
> the script as possible to reduce that time, and the number of forks has
> been reduced drastically for modern shells. I believe dash and ksh93 are
> faster than bash at running libtool. Last time I checked, libtool's compile
> mode wasn't significantly slower than using dolt (
> http://dolt.freedesktop.org/)**.
>
>
>
 This could be optimized even more, but it would be a considerable amount
of work just to speed up compilation (Shouldn't we be spending more time
designeing code instead of building it?).


>
>> 3) Does it happen often in practice that a project builds both -fPIC
>> and non-pic objects, even though only one of them is going to be
>> used?  If yes, and if it is because of a mistake on package
>> maintainer's side, can something be done about it?  (warnings, changed
>> defaults, autodetection in automake)
>>
>
> Perhaps the default should be --enable-shared --disable-static? It's worth
> considering.
>
> Peter
>
>
This is the "common subset" in action.  Some platforms can't make static
archives from PIC objects, so to make static and shared libraries, each
source file must be compiled twice.  Users can disable either one at
configure time, so Libtool is already doing everything it possibly can to
do what it should.  Changing the defaults would just cause a different
group of users to complain ;)
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Several questions about libtool

2012-01-06 Thread Bob Friesenhahn


On Fri, 6 Jan 2012, Peter O'Gorman wrote:


This is still an issue, libtool always adds all dependencies. Many packages 
assume this and don't explicitly add required dependencies to Makefile.am 
etc. I don't recall the arguments for not changing this when building shared. 
IIRC Scott tried to include Debian's patch at some point. I'll look it up in 
the archives later.


Some systems (e.g. GNU Linux) add library implicit dependencies at 
link time while others (e.g. Solaris) only seem to add them at 
run-time and will fail to link if the dependencies are not also 
listed.  Some systems require that no symbols remain unresolved in 
order to produce a shared library.


Libtool's mode of operation works with static builds and on systems 
where all libraries have to be supplied at link time.


Perhaps the default should be --enable-shared --disable-static? It's worth 
considering.


Each package has control over these defaults.  My own package defaults 
to --disable-shared --enable-static because shared libraries should 
not link with static libraries.  Since a shared build implies more 
responsibility, I defaulted to the fail-safe option.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

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

Re: Several questions about libtool

2012-01-06 Thread Peter O'Gorman


On 01/06/2012 11:21 AM, Stepan Kasal wrote:


1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recursive resolution
(which is the case on GNU/Linux distributions for many years).
(I believe that the rule that forbids packing .la files to -dev and
-devel subpackages on Debian and Fedora (respectively), is there just
to work around this problem.)


This is still an issue, libtool always adds all dependencies. Many 
packages assume this and don't explicitly add required dependencies to 
Makefile.am etc. I don't recall the arguments for not changing this when 
building shared. IIRC Scott tried to include Debian's patch at some 
point. I'll look it up in the archives later.




2) People told me libtool is slow and shell has to parse huge script
just to find out that it has to call gcc twice, with and without
-fPIC.  Again, this is not about the general portability case, it is
a request for optimization on GNU/Linux platform, that they percepts
as one of the major customers of libtool.


Libtool is faster than it used to be, the shell does have to parse quite 
a bit of script, but compile mode has been moved as close to the 
beginning of the script as possible to reduce that time, and the number 
of forks has been reduced drastically for modern shells. I believe dash 
and ksh93 are faster than bash at running libtool. Last time I checked, 
libtool's compile mode wasn't significantly slower than using dolt 
(http://dolt.freedesktop.org/).




3) Does it happen often in practice that a project builds both -fPIC
and non-pic objects, even though only one of them is going to be
used?  If yes, and if it is because of a mistake on package
maintainer's side, can something be done about it?  (warnings, changed
defaults, autodetection in automake)


Perhaps the default should be --enable-shared --disable-static? It's 
worth considering.


Peter


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

Several questions about libtool

2012-01-06 Thread Stepan Kasal

Hello,

I'm sad when I hear people rant about libtool, and I would like to
know the answers to that rants.  The following bugs were, as I
supposed, known for years, but I may be wrong - perhaps they were
resolved years ago or they were never filed.

I would be very grateful if you could give me quick hints about what
is the real status of each of the issue.
(If my questions are silly, please be patient with me and help me by
referring me to the right docs.)

1) .la file always contains the recursively evaluated list of libraries.
While this is necessary for static linking and dumb dynamic linkers,
it is an issue for dyn. linkers that can do recursive resolution
(which is the case on GNU/Linux distributions for many years).
(I believe that the rule that forbids packing .la files to -dev and
-devel subpackages on Debian and Fedora (respectively), is there just
to work around this problem.)

2) People told me libtool is slow and shell has to parse huge script
just to find out that it has to call gcc twice, with and without
-fPIC.  Again, this is not about the general portability case, it is
a request for optimization on GNU/Linux platform, that they percepts
as one of the major customers of libtool.

3) Does it happen often in practice that a project builds both -fPIC
and non-pic objects, even though only one of them is going to be
used?  If yes, and if it is because of a mistake on package
maintainer's side, can something be done about it?  (warnings, changed
defaults, autodetection in automake)

Regards,
Stepan Kasal

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

Re: Bad LD_LIBRARY_PATH set in the libtool wrapper

2011-12-26 Thread Roumen Petrov


Sam Varshavchik wrote:
My source tree builds two libraries, from two separate directories in 
the source tree.


libxtls.la gets linked against libx.la in a different directory, as 
well as some system libraries in /usr/local/lib. Makefile.am declares 
thusly:


libxtls_la_LIBADD=../base/libx.la
libxtls_la_LDFLAGS=-version-info 1 $(GNUTLS_LIBS) $(GCRYPT_LIBS) 
-lpthread
libtool use LDFLAGS before LIBADD as result paths form LDFLAGS will be 
used first.


Move "$(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthread"  to LIBADD adn try again.

Roumen


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

Bad LD_LIBRARY_PATH set in the libtool wrapper

2011-12-26 Thread Sam Varshavchik

My source tree builds two libraries, from two separate directories in the  
source tree.


libxtls.la gets linked against libx.la in a different directory, as well as  
some system libraries in /usr/local/lib. Makefile.am declares thusly:


libxtls_la_LIBADD=../base/libx.la
libxtls_la_LDFLAGS=-version-info 1 $(GNUTLS_LIBS) $(GCRYPT_LIBS) -lpthread

These macros expand to a search path that includes /usr/local/lib. In  
libxtls.la I end up with this (leaving out some unrelated stuff):


dependency_libs="-R/usr/local/lib -L/usr/local/lib  
[SOURCETREEPATH]/base/libx.la"


I then build an executable named "testuseragent_shared" that gets linked  
against libxtls.la:


testuseragent_shared_SOURCES=testuseragent.C
testuseragent_shared_LDADD=libxtls.la

From this, libtool produces a wrapper for testuseragent_shared in the source  

tree, that reads as follows (linewrapped):

LD_LIBRARY_PATH="[CURRENTDIR]/.libs:/usr/local/lib: 
[SOURCETREEPATH]/base/.libs:$LD_LIBRARY_PATH"


The search path places /usr/local/lib ahead of …/base/.libs, for libx.so.1.  
It obviously gets it from libxtls_la_LDFLAGS.


The problem here is when I already have a previously installed, older  
libx.so.1 build in /usr/local/lib, and I run testuseragent_shared from the  
source tree, it ends up loading the older libx.so.1 from /usr/local/lib,  
rather than the one that also gets built in the source tree. Hilarity ensues.


Yes, I know about -static, and I also produce a testuseragent_static linked  
with -static, that works splendidly from the source tree. But I'd really  
like to have a dynamically-linked testuseragent_shared and run it from the  
source tree, with the wrapper's help, for regression testing purposes.


I must be doing something fundamentally wrong here, but I can't figure it  
out. The more I think about it, the more I'm leaning towards thinking that  
libtool should always put source tree paths ahead of any system paths, in  
the wrapper. This is libtool 2.4.




pgpj4qALO6AA6.pgp
Description: PGP signature
_______
https://lists.gnu.org/mailman/listinfo/libtool

Re: Fwd: http://www.gnu.org/software/libtool/future.html is outdated

2011-12-21 Thread Peter O'Gorman


Hi Max,

Thanks, I did as you suggested and removed future.html.

Peter

On 12/21/2011 10:30 AM, Max Horn wrote:

Hi Peter,

I tried two times now to send the following email to webmast...@www.gnu.org, but the address seems 
to be dead and not accepting any delivery; after several days, each with a "timeout, trying 
again", I finally got a "retry timeout exceeded".

Anyway, since I know that you are (were?) involved with libtool development, I 
thought you might know a different way to deliver the message below to whoever 
it might be suitable for :).

Cheers,
Max

Anfang der weitergeleiteten E-Mail:


Von: Max Horn
Datum: 18. Dezember 2011 16:52:44 MEZ
An: webmast...@www.gnu.org
Betreff: http://www.gnu.org/software/libtool/future.html is outdated

Dear webmasters of www.gnu.org,

as per the instructions at the bottom 
of<http://www.gnu.org/software/libtool/future.html>, I am emailing you -- if 
this the wrong address, I'd appreciate if you could let me know whom else to contact 
about this matter.

The page<http://www.gnu.org/software/libtool/future.html>  in questions is heavily 
outdated. It talks about "future" developments of libtool, and with that means 1.5 
and 1.6. But as you probably know, version 2.4.2 is the latest.

I guess it might be easiest to simply delete that page, unless some libtool 
developers would like to update it with current content?

Best wishes,
Max





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

Re: Libtool error reporting.

2011-12-08 Thread Shamis, Pavel

Peter,

Actually, I already have a patch. Please see attached file. It is very simple, 
if module opening fails, in addition to "Failed" message, it prints out last 
error message. 
So far it is only a spot where I found useful to add verbose error reporting.



libtool_debug_error_reporting.patch
Description: libtool_debug_error_reporting.patch


Regards,

Pavel (Pasha) Shamis
---
Application Performance Tools Group
Computer Science and Math Division
Oak Ridge National Laboratory

On Dec 8, 2011, at 12:19 AM, Peter O'Gorman wrote:

> On 12/05/2011 11:48 AM, Shamis, Pavel wrote:
>> Hi,
>> 
>> As have been mentioned on the list, libtool error reporting - "file not 
>> found" is not perfect. People suggested to fix it 
>> (hxxp://www.mail-archive.com/libtool@gnu.org/msg12156.html) but it seems, 
>> that the changes have never been incorporated into the trunk. I'm not well 
>> familiar with all the details of the problem, but I would suggest to improve 
>> the debug mode (-DLT_DEBUG_LOADERS) verbose messaging. Libtool already 
>> prints "Success/Failed", so I suggest to extend the message and  print out 
>> the last error (LT__GETERROR(error)) for the Failed case.
> 
> This seems like a good idea (if DEBUG_LOADERS is defined, print the 
> error to stderr every time an error is set). If you don't come up with a 
> patch, I'll try to find the time to do it.
> 
> Thanks,
> Peter
> 
> 

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

Re: Libtool, rpath, and libGL.so

2011-12-07 Thread Adam Mercer

On Wed, Dec 7, 2011 at 23:26, Peter O'Gorman  wrote:

> Does anyone want to try again?
>
> http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html
>
> I only have red hat like distros, so if someone could update the patch and
> look at other distros that'd be great.

I can have a play, I need to support Scientific Linux 6, Debian
Squeeze, and Mac OS X (Snow Leopard and Lion) for one of my projects
(one which has been hit by this problem). It may take me a while as
I'm in the middle of preparing a new release of our software.

Cheers

Adam

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

Re: Libtool, rpath, and libGL.so

2011-12-07 Thread Peter O'Gorman


On 11/29/2011 11:48 PM, Adam Mercer wrote:

On Mon, Nov 28, 2011 at 23:30, Andy Spencer  wrote:


This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly configured to use the nvidia version.


I raised this question a week or so ago and the workaround suggested was to set:

lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64"


Does anyone want to try again?

http://lists.gnu.org/archive/html/libtool-patches/2010-11/msg00027.html

I only have red hat like distros, so if someone could update the patch 
and look at other distros that'd be great.


Peter


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

Re: Libtool error reporting.

2011-12-07 Thread Peter O'Gorman


On 12/05/2011 11:48 AM, Shamis, Pavel wrote:

Hi,

As have been mentioned on the list, libtool error reporting - "file not found" is not 
perfect. People suggested to fix it (http://www.mail-archive.com/libtool@gnu.org/msg12156.html) but 
it seems, that the changes have never been incorporated into the trunk. I'm not well familiar with 
all the details of the problem, but I would suggest to improve the debug mode (-DLT_DEBUG_LOADERS) 
verbose messaging. Libtool already prints "Success/Failed", so I suggest to extend the 
message and  print out the last error (LT__GETERROR(error)) for the Failed case.


This seems like a good idea (if DEBUG_LOADERS is defined, print the 
error to stderr every time an error is set). If you don't come up with a 
patch, I'll try to find the time to do it.


Thanks,
Peter


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

Libtool error reporting.

2011-12-05 Thread Shamis, Pavel

Hi,

As have been mentioned on the list, libtool error reporting - "file not found" 
is not perfect. People suggested to fix it 
(http://www.mail-archive.com/libtool@gnu.org/msg12156.html) but it seems, that 
the changes have never been incorporated into the trunk. I'm not well familiar 
with all the details of the problem, but I would suggest to improve the debug 
mode (-DLT_DEBUG_LOADERS) verbose messaging. Libtool already prints 
"Success/Failed", so I suggest to extend the message and  print out the last 
error (LT__GETERROR(error)) for the Failed case.

My 0,02$

Regards,

Pavel (Pasha) Shamis


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

Re: Libtool, rpath, and libGL.so

2011-11-29 Thread Adam Mercer

On Mon, Nov 28, 2011 at 23:30, Andy Spencer  wrote:

> This seems to be caused by libtool adding a -rpath flag which forces the
> application to use the /usr/lib64 version provided by mesa even though
> ld.so.conf has been properly configured to use the nvidia version.

I ran into essentially the same problem on Scientific Linux 6,
essentially libtool sometimes incorrectly determines the system
library paths. I imagine if you look at the sys_lib_dlsearch_path_spec
variable within the libtool script it will state that /usr/lib is a
system library path and not /usr/lib64. Therefore libtool will assume
it needs to pass /usr/lib64 on the command line thereby leading to
this linking problem.

I raised this question a week or so ago and the workaround suggested was to set:

lt_cv_sys_lib_dlsearch_path_spec="/lib64 /usr/lib64"

during configure, this overrides the paths found by libtool and solved
the linking problem for me. Unfortunately this is a hack and ignores
any paths specified in ld.so.conf so you may need to tweak this
accordingly.

Hope this is of some help.

Cheers

Adam

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

Libtool, rpath, and libGL.so

2011-11-29 Thread Andy Spencer

I'm building a library of mine on Fedora 64-bit and running into some
problems. I'm running configure as follows:

  ./configure --prefix=/usr --libdir=/usr/lib64

The problem is that the wrong version of libGL.so is being used at
runtime. The correct version is /usr/lib64/nvidia/libGL.so.* but any
application built against my library uses /usr/lib64/libGL.so.* instead.

This seems to be caused by libtool adding a -rpath flag which forces the
application to use the /usr/lib64 version provided by mesa even though
ld.so.conf has been properly configured to use the nvidia version.

I can fix the problem for other programs by manually deleting all the
.la files provided by my library after I install it. However, my library
also comes with a demo program which is compiled along side the library
and I don't know how to make that use the correct version of libGL.

Is there any way to prevent the demo program from getting build with a
rpath, or are there any other ways to fix this?


pgpKhH0XiIbSJ.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: ac_run_ifelse and libtool

2011-11-26 Thread Werner LEMBERG


Ping!  Is this really an unimportant issue?


Werner

> I've found this interesting mail:
> 
>   http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html
> 
> Interestingly, there was no comment at all.  So my question: Is this
> the `right' approach?  Will libtool provide something similar?

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

ac_run_ifelse and libtool

2011-11-16 Thread Werner LEMBERG


I've found this interesting mail:

  http://lists.gnu.org/archive/html/libtool-patches/2011-08/msg0.html

Interestingly, there was no comment at all.  So my question: Is this
the `right' approach?  Will libtool provide something similar?


Werner

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

Re: How to use libtool for target builds? libstdc++ conflicts

2011-11-11 Thread Jim Galarowicz


Hi all,

I did get around this issue by not trying to use the Cray CC and cc 
commands.  They must do something that skews how the whole scenario is 
supposed to work
By just using the PrgEnv-gnu module and using gcc and g++ directly, I do 
not see the issues outlined below.  The proper libstdc++ library that is 
associated with the gcc and g++ version is used.


Thanks,
Jim G

On 11/08/2011 04:56 PM, Jim Galarowicz wrote:


Hi,

I'm building our OpenSpeedShop performance tool to run on the backend 
nodes of a Cray-XE machine.  We use the libtool, m4, autoconf, and 
automake autotools.


Everything is working accept I'm getting the wrong libstdc++ library 
when linking the main program that runs on the backend nodes.   Each 
of the libraries that I'm building that get linked into the main 
program have /usr/lib64/libstdc++.la in there .la files.  The 
/usr/lib64/libstdc++.la isn't the one that corresponds to the 
/opt/gcc/4.6.1/bin/g++ compiler that I'm using to build for the target 
(Cray backend nodes).  This compiler has its own stdc++.la file: 
/opt/gcc/default/snos/lib64/libstdc++.la.


I'm not sure how resolve this and have spent a few hours trying to 
find how to force the build of our tool to use the correct version of 
libstdc++.   The host version and the target version conflict and 
cause linker errors when building the main program.


I'm guessing I'm doing something dumb.

I build my own libtool, autoconf, m4, and automake because the ones on 
the Cray frontend node are old (libtool-1.5.3).  We use 
libtool-2.2.6b.   I build these on the frontend node and use it to 
"bootstrap/autogen" the tool we are building.   Everything works fine 
when we build the frontend version of our tool but when I try to build 
a version that runs on the backend nodes of the cray with a different 
compiler (/opt/gcc/4.6.1/bin/g++) I'm still getting the 
/usr/lib64/libstdc++.la files included in my target build library .la 
files.


Any thoughts on what I'm doing wrong?   Is there a way to build a 
version libtool, for the target, and specify the libraries that should 
be used (i.e. the ones that correspond to the compiler)?


Thanks for any help.  It will be appreciated.

Jim G.


_______
https://lists.gnu.org/mailman/listinfo/libtool

How to use libtool for target builds? libstdc++ conflicts

2011-11-11 Thread Jim Galarowicz



Hi,

I'm building our OpenSpeedShop performance tool to run on the backend 
nodes of a Cray-XE machine.  We use the libtool, m4, autoconf, and 
automake autotools.


Everything is working accept I'm getting the wrong libstdc++ library 
when linking the main program that runs on the backend nodes.   Each of 
the libraries that I'm building that get linked into the main program 
have /usr/lib64/libstdc++.la in there .la files.  The 
/usr/lib64/libstdc++.la isn't the one that corresponds to the 
/opt/gcc/4.6.1/bin/g++ compiler that I'm using to build for the target 
(Cray backend nodes).  This compiler has its own stdc++.la file: 
/opt/gcc/default/snos/lib64/libstdc++.la.


I'm not sure how resolve this and have spent a few hours trying to find 
how to force the build of our tool to use the correct version of 
libstdc++.   The host version and the target version conflict and cause 
linker errors when building the main program.


I'm guessing I'm doing something dumb.

I build my own libtool, autoconf, m4, and automake because the ones on 
the Cray frontend node are old (libtool-1.5.3).  We use 
libtool-2.2.6b.   I build these on the frontend node and use it to 
"bootstrap/autogen" the tool we are building.   Everything works fine 
when we build the frontend version of our tool but when I try to build a 
version that runs on the backend nodes of the cray with a different 
compiler (/opt/gcc/4.6.1/bin/g++) I'm still getting the 
/usr/lib64/libstdc++.la files included in my target build library .la 
files.


Any thoughts on what I'm doing wrong?   Is there a way to build a 
version libtool, for the target, and specify the libraries that should 
be used (i.e. the ones that correspond to the compiler)?


Thanks for any help.  It will be appreciated.

Jim G.

_______
https://lists.gnu.org/mailman/listinfo/libtool

Re: Install libtool on Win7 x64

2011-11-01 Thread Gary V. Vaughan

Hi Joe,

On 1 Nov 2011, at 20:08, Joe Breedlove wrote:
> Hello,
> I am trying to install a program called srecord found at 
> http://srecord.sourceforge.net . The author of srecord suggested also 
> installing libtool. I am working with the srecord in order to convert a hex 
> file over to a binary which I am attempting to use to program a CPU 
> controller. I am not familiar with these types of source files at all so I 
> hope you can help me. I have read the instructions for how to configure 
> libtool found in the INSTALL file. However, whenever I open the windows 
> command prompt and change directory to the unzipped files I downloaded for 
> libtool and type “./configure” I get an error message stating something like 
> that is not a valid batch command or something to that nature. Can someone 
> explain to me how I should install this libtool. Again, I am not familiar 
> with building things from source files but it has become necessary for the 
> project I am working on.
>  
> Thank you,

Thanks for your interest in GNU Libtool.

I'm sorry that the standard GNU INSTALL file you'll find in most GNU projects 
doesn't make mention that it assumes you are already on Unix, or at least in a 
POSIX compatible environment, so those instructions absolutely won't work on 
bare Windows which does not have any of the tools that it assumes.

The GNU build system (Autoconf, Automake, Libtool) was written for and designed 
to run in a POSIX compatible environment, with a Bourne Shell and GNU M4 
installed among others.  Before you can hope to run POSIX shell scripts (such 
as Libtool) on Windows you will need to install a full POSIX emulation.  In the 
past I have had good experiences with http://www.cygwin.com, but Libtool is 
also compatible with mingw and MSYS if you prefer those.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

_______
https://lists.gnu.org/mailman/listinfo/libtool

Install libtool on Win7 x64

2011-11-01 Thread Joe Breedlove

Hello,

I am trying to install a program called srecord found at
http://srecord.sourceforge.net . The author of srecord suggested also
installing libtool. I am working with the srecord in order to convert a hex
file over to a binary which I am attempting to use to program a CPU
controller. I am not familiar with these types of source files at all so I
hope you can help me. I have read the instructions for how to configure
libtool found in the INSTALL file. However, whenever I open the windows
command prompt and change directory to the unzipped files I downloaded for
libtool and type "./configure" I get an error message stating something like
that is not a valid batch command or something to that nature. Can someone
explain to me how I should install this libtool. Again, I am not familiar
with building things from source files but it has become necessary for the
project I am working on.

 

Thank you,

 

Joe Breedlove

Protokraft, LLC.

4545 W Stone Dr

Bld 135

Kingsport, TN 37660

(423) 578-7200 ext 23

jbreedl...@protokraft.com

 

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

Re: libtool, multilib and test "duplicate convenience archive names"

2011-10-23 Thread Andreas Jaeger

On Thursday, October 20, 2011 11:07:13 PM Roumen Petrov wrote:
> Hi Andreas and Bo,
> 
> Please could you clarify build of 64-bit system for 32 bit.

Hi Roumen,

> Roumen Petrov wrote:
> > Hello All,
> > 
> > I wonder how to build and test on a 64 bit platform a 32 bit libtool
> > version.
> > 
> > First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux
> > with CC and CXX set to 'gcc|g++ -m32', i.e. multilib .
> > 
> > The libtool regression suite fail in test case :
> > 25: duplicate convenience archive names     FAILED
> > (duplicate_conv.at:83)
> > 
> > From testsuite.log:
> > 
> > .../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link
> > --tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la
> > stderr:
> > .../ld: Relocatable linking with relocations from format elf32-i386
> > (.libs/c.o) to format elf64-x86-64 (cee.o) is not supported
> > stdout:
> > libtool: link: .../ld -r -o cee.o  .libs/c.o   --whole-archive
> > a/.libs/liba.a b/.libs/liba.a --no-whole-archive
> > 
> > 
> > Eric PAIRE post a patch about linker emulation mode - ref.
> > http://lists.gnu.org/archive/html/bug-libtool/2011-06/msg1.html .
> > 
> > 
> > Based on Eric's suggestion I try to build without to set --host, i.e.
> > as native build for x86_64-gnu-linux with gcc|g++ -m32 as compilers.
> > 
> > As result -m elf_i386 is added to linker (LD) and libtool regression
> > test pass with:
> > 114 tests behaved as expected.
> > 12 tests were skipped.
> > 
> > 
> > Any thought on this ?
> 
> Traced to
> 
> 2002-11-18 Andreas Jaeger , Bo Thorsen 
> 
> * libtool.m4: Support linking of 32-bit libraries with ld
> 
> on the x86-64, ppc64, s390x and sparc64 GNU/Linux systems.

Sorry, I don't remember that change anymore and thus cannot help,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

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

Re: libtool, multilib and test "duplicate convenience archive names"

2011-10-20 Thread Roumen Petrov


Hi Andreas and Bo,

Please could you clarify build of 64-bit system for 32 bit.


Roumen Petrov wrote:

Hello All,

I wonder how to build and test on a 64 bit platform a 32 bit libtool 
version.


First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux 
with CC and CXX set to 'gcc|g++ -m32', i.e. multilib .


The libtool regression suite fail in test case :
25: duplicate convenience archive names FAILED 
(duplicate_conv.at:83)


From testsuite.log:

.../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link 
--tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la

stderr:
.../ld: Relocatable linking with relocations from format elf32-i386 
(.libs/c.o) to format elf64-x86-64 (cee.o) is not supported

stdout:
libtool: link: .../ld -r -o cee.o  .libs/c.o   --whole-archive 
a/.libs/liba.a b/.libs/liba.a --no-whole-archive



Eric PAIRE post a patch about linker emulation mode - ref.
http://lists.gnu.org/archive/html/bug-libtool/2011-06/msg1.html .


Based on Eric's suggestion I try to build without to set --host, i.e. 
as native build for x86_64-gnu-linux with gcc|g++ -m32 as compilers.


As result -m elf_i386 is added to linker (LD) and libtool regression 
test pass with:

114 tests behaved as expected.
12 tests were skipped.


Any thought on this ?


Traced to

2002-11-18 Andreas Jaeger , Bo Thorsen 

* libtool.m4: Support linking of 32-bit libraries with ld

on the x86-64, ppc64, s390x and sparc64 GNU/Linux systems.



Roumen



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

libtool, multilib and test "duplicate convenience archive names"

2011-10-19 Thread Roumen Petrov


Hello All,

I wonder how to build and test on a 64 bit platform a 32 bit libtool 
version.


First test is to use --build=x86_64-gnu-linux --host=i386-gnu-linux with 
CC and CXX set to 'gcc|g++ -m32', i.e. multilib .


The libtool regression suite fail in test case :
25: duplicate convenience archive names FAILED 
(duplicate_conv.at:83)


From testsuite.log:

.../libtool-2.4.2/tests/duplicate_conv.at:83: $LIBTOOL --mode=link 
--tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la

stderr:
.../ld: Relocatable linking with relocations from format elf32-i386 
(.libs/c.o) to format elf64-x86-64 (cee.o) is not supported

stdout:
libtool: link: .../ld -r -o cee.o  .libs/c.o   --whole-archive 
a/.libs/liba.a b/.libs/liba.a --no-whole-archive



Eric PAIRE post a patch about linker emulation mode - ref.
http://lists.gnu.org/archive/html/bug-libtool/2011-06/msg1.html .


Based on Eric's suggestion I try to build without to set --host, i.e. as 
native build for x86_64-gnu-linux with gcc|g++ -m32 as compilers.


As result -m elf_i386 is added to linker (LD) and libtool regression 
test pass with:

114 tests behaved as expected.
12 tests were skipped.


Any thought on this ?


Regards,
Roumen

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

GNU Libtool 2.4.2 released [stable]

2011-10-18 Thread Gary V. Vaughan

Libtoolers!

The Libtool Team is pleased to announce the release of GNU Libtool 2.4.2.

GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.

This release contains bugfixes accumulated over the last 13 months since
the release of 2.4 in September 2010.

New in 2.4.2 2011-10-17:

* New features:

  - The --with-pic configure option now supports a list of comma-separated
package names.  This can be used to build some static libraries with PIC
objects while building others with non-PIC objects.

  - Initial support for Go, using the gccgo compiler.

  - On Mac OS X .dylib is now tried as well as .so with
lt_dlopenext().

* Bug fixes:

  - The generic approximation of the command line length limit (when getconf is
not available) works again.  Regression introduced in v2.2.6-39-g9c3d4d8.
  - The bug that leaked developer tool paths into the release tarballs
from ./bootstrap is fixed.
  - Improved support for the Cuda Compiler Driver (nvcc) on Darwin.
  - For GCC LTO support, the -fuse-linker-plugin switch is now also removed
when computing compiler postdeps.

* Important incompatible changes:

  - The undocumented hardcode_libdir_flag_spec_ld tag variable has been
removed in favor of using hardcode_libdir_flag_spec with $wl set to empty.

* Changes in supported systems or compilers:

  - Fixes for gfortran on Darwin, XL Fortran on GNU/Linux.
  - Support for FreeBSD 1.x (outdated since 1994) has been removed.


libtool-2.4.2 is available now from ftp.gnu.org, along with compressed diffs
against libtool-2.4. Please use a mirror to reduce stress on the main gnu
machine:

  http://www.gnu.org/order/ftp.html

Here are the compressed sources:

  ftp://ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.gz (2.51MiB)
  ftp://ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.xz (0.82MiB)

Here are the compressed diffs against libtool-2.4:

  ftp://ftp.gnu.org/gnu/libtool/libtool-2.4-2.4.2.diff.gz (353.7KiB)

Here are the gpg detached signatures:

  ftp://ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.gz.sig (4.0KiB)
  ftp://ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.xz.sig (4.0KiB)
  ftp://ftp.gnu.org/gnu/libtool/libtool-2.4-2.4.2.diff.gz.sig (4.0KiB)

You should download the signature named after any tarball you download, and
then verify its integrity with, for example:

  gpg --verify libtool-2.4.2.tar.gz.sig

Here are the MD5 and SHA1 checksums:

  d2f3b7d4627e69e13514a40e72a24d50 libtool-2.4.2.tar.gz
  2ec8997e0c07249eb4cbd072417d70fe libtool-2.4.2.tar.xz
  676723ef67a060566aa9aab0cde60463 libtool-2.4-2.4.2.diff.gz
  22b71a8b5ce3ad86e1094e7285981cae10e6ff88 libtool-2.4.2.tar.gz
  4671f3323f2fbc712a70afce57602ce906a82a15 libtool-2.4.2.tar.xz
  87537042205aecac8c887cb3f9b03d6a2f28855e libtool-2.4-2.4.2.diff.gz

This release was bootstrapped with autoconf-2.68 and automake-1.11.1, but is
useable with autoconf-2.62 and automake-1.9.6 in your own projects.

Alternatively, you can fetch the unbootstrapped source code with git by
using the following command:

  $ git clone git://git.savannah.gnu.org/libtool.git
  $ cd libtool
  $ git checkout v2.4.2

You will then need to have the latest release versions of Automake
(automake-1.11.1) and Autoconf (autoconf-2.68) installed to
bootstrap the checked out sources yourself.

Please report bugs to , along with the verbose output of
any failed test groups, and the output from `./libtool --config.' The README
file explains how to capture the verbose test output.

Enjoy!
___
https://lists.gnu.org/mailman/listinfo/libtool

RE: Help needed to build shared library with libtool

2011-10-17 Thread David Aldrich

Hi Peter

I have tried using just g++ (no libtool) and the link succeeds.  On this 
occasion it seems easiest for me just not to use libtool.

Thanks for your help and advice.

Best regards

David

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

RE: Help needed to build shared library with libtool

> Your object files are created without using libtool?

Yes, just g++.

> 
> > ln: creating symbolic link `libGUI.so.0': Operation not supported
> > make: *** [libGUI.so] Error 1
> 
> That's a new one for me, you snipped the ln command that fails though.
> 
> I don't know how much you care about portability, if you aren't worried
> about it (previously your Makefile with older libtool would only create
> working shared libraries with compilers that understand -shared and
> where the shared library extension is .so), then you may be better off
> not using libtool at all, and just doing
> g++ -shared -o libGUI.so 

Well that would be fine. We just need to build for Linux.  To be honest I don't 
know why we are using libtool.  I will try just using g++ ...

Thanks again

David

_______
https://lists.gnu.org/mailman/listinfo/libtool

Re: Help needed to build shared library with libtool

2011-10-14 Thread Peter O'Gorman


On 10/14/2011 08:45 AM, David Aldrich wrote:

Hi Peter

Thanks for your reply.

-shared is not a libtool flag


Oh, that's weird! We've been using that option for building other shared 
libraries for a long time.


Yes, and older libtools used to pass it along to the compiler driver, so 
on systems using gcc/g++ or where the compiler accepted the -shared flag 
to create a shared library it would work.





does it work if you do:

libtool --mode=link g++ -o libGUI.la  -rpath /usr/local/lib



That doesn't work, but the result is different:

libtool --mode=link g++ -o libGUI.la   -rpath /usr/local/lib 
-rpath /usr/lib64 -L/usr/lib64 -pthread   -L/usr/lib64   -lwx_gtk2u_richtext-2.8 
-lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 
-lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 
-lwx_baseu-2.8  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig 
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0

*** Warning: Linking the shared library libGUI.la against the non-libtool
*** objects  is not portable!


Your object files are created without using libtool?


ln: creating symbolic link `libGUI.so.0': Operation not supported
make: *** [libGUI.so] Error 1


That's a new one for me, you snipped the ln command that fails though.

I don't know how much you care about portability, if you aren't worried 
about it (previously your Makefile with older libtool would only create 
working shared libraries with compilers that understand -shared and 
where the shared library extension is .so), then you may be better off 
not using libtool at all, and just doing

g++ -shared -o libGUI.so 

That does exclude Windows, Mac OS X, HP-UX, though, just on the ".so".

Peter




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

RE: Help needed to build shared library with libtool

Hi Peter

Thanks for your reply.
> -shared is not a libtool flag

Oh, that's weird! We've been using that option for building other shared 
libraries for a long time.
 
> does it work if you do:
> 
> libtool --mode=link g++ -o libGUI.la  -rpath /usr/local/lib
> 

That doesn't work, but the result is different:

libtool --mode=link g++ -o libGUI.la   -rpath /usr/local/lib 
-rpath /usr/lib64 -L/usr/lib64 -pthread   -L/usr/lib64   
-lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 
-lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 
-lwx_baseu_net-2.8 -lwx_baseu-2.8  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 
-lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0

*** Warning: Linking the shared library libGUI.la against the non-libtool
*** objects  is not portable!
libtool: link: warning: ignoring multiple `-rpath's for a libtool library
libtool: link: g++ -shared -nostdlib 
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crti.o 
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtbeginS.o  
-L/usr/lib64 -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 
-lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 
-lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -lgtk-x11-2.0 
-lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 
-lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 
-lgmodule-2.0 -lglib-2.0 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4 
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64 -L/lib/../lib64 
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../.. -lstdc++ 
-lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.4.4/crtendS.o 
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/crtn.o  -pthread   
-pthread -Wl,-soname -Wl,libGUI.so.0 -o libGUI.so.0.0.0
libtool: link: (cd )
ln: creating symbolic link `libGUI.so.0': Operation not supported
make: *** [libGUI.so] Error 1

David

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

Re: Help needed to build shared library with libtool

2011-10-14 Thread Peter O'Gorman


On 10/14/2011 02:10 AM, David Aldrich wrote:

Hi

I am using libtool in a makefile to create a shared library containing my 
application code, which also links to wxWidgets libraries.  As a consequence of 
changing both platform (including gcc version) and wxWidgets packages, my 
makefile ceases to work.  It seems that the libtool command is trying to make a 
static, rather than a shared library.  I don't understand libtool well enough 
to fix the problem and would be grateful of some help.  Although I have 
mentioned wxWidgets, I am inclined to think that it is more appropriate to ask 
help from the libtool community than the wxWidgets community.

Here is the failing command:

libtool --mode=link g++ -shared -o libGUI.so   -rpath 
/usr/local/lib


-shared is not a libtool flag, does it work if you do:

libtool --mode=link g++ -o libGUI.la  -rpath /usr/local/lib

?

Peter

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

Help needed to build shared library with libtool

Hi 

I am using libtool in a makefile to create a shared library containing my 
application code, which also links to wxWidgets libraries.  As a consequence of 
changing both platform (including gcc version) and wxWidgets packages, my 
makefile ceases to work.  It seems that the libtool command is trying to make a 
static, rather than a shared library.  I don't understand libtool well enough 
to fix the problem and would be grateful of some help.  Although I have 
mentioned wxWidgets, I am inclined to think that it is more appropriate to ask 
help from the libtool community than the wxWidgets community.

Here is the failing command:

libtool --mode=link g++ -shared -o libGUI.so   -rpath 
/usr/local/lib -rpath /usr/lib64 -pthread -Wl,-Bsymbolic-functions  
-lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 
-lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 
-lwx_baseu_net-2.8 -lwx_baseu-2.8  -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 
-lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 
-lgthread-2.0 -lrt -lglib-2.0  
libtool: link: g++ -o libGUI.so  -pthread 
-Wl,-Bsymbolic-functions -pthread  -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 
-lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 
-lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 
/usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so 
/usr/lib/libgio-2.0.so /usr/lib/libpangoft2-1.0.so 
/usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so 
/usr/lib/libcairo.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so 
-lfontconfig /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so 
/usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -pthread -Wl,-rpath 
-Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/lib64
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'  

Now, on the previous (working) environment, libtool created a command that 
started with:

   g++ -shared -o /libGUI.so

whereas the failing command (above) starts with:

   libtool: link: g++ -o libGUI.so

I realise that the absence of '-shared' in the latter is probably causing my 
problem.  Why is it not present please?

Best regards

David


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

Help needed to build shared library with libtool

Hi 

I am using libtool in a makefile to create a shared library containing my 
application code, which also links to wxWidgets libraries.  As a consequence of 
changing both platform (including gcc version) and wxWidgets packages, my 
makefile ceases to work.  It seems that the libtool command is trying to make a 
static, rather than a shared library.  I don't understand libtool well enough 
to fix the problem and would be grateful of some help.  Although I have 
mentioned wxWidgets, I am inclined to think that it is more appropriate to ask 
help from the libtool community than the wxWidgets community.

Here is the failing command:

libtool --mode=link g++ -shared -o libGUI.so   -rpath 
/usr/local/lib -rpath /usr/lib64 -pthread -Wl,-Bsymbolic-functions  
-lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 
-lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 
-lwx_baseu_net-2.8 -lwx_baseu-2.8  -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 
-lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 
-lgthread-2.0 -lrt -lglib-2.0  
libtool: link: g++ -o libGUI.so  -pthread 
-Wl,-Bsymbolic-functions -pthread  -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 
-lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 
-lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 
/usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so 
/usr/lib/libgio-2.0.so /usr/lib/libpangoft2-1.0.so 
/usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so 
/usr/lib/libcairo.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so 
-lfontconfig /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so 
/usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -pthread -Wl,-rpath 
-Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/lib64
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'  

Now, on the previous (working) environment, libtool created a command that 
started with:

   g++ -shared -o /libGUI.so

whereas the failing command (above) starts with:

   libtool: link: g++ -o libGUI.so

I realise that the absence of '-shared' in the latter is probably causing my 
problem.  Why is it not present please?

Best regards

David


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

Help needed to build shared library with libtool

Hi

I am using libtool in a makefile to create a shared library containing my 
application code, which also links to wxWidgets libraries.  As a consequence of 
changing both platform (including gcc version) and wxWidgets packages, my 
makefile ceases to work.  It seems that the libtool command is trying to make a 
static, rather than a shared library.  I don't understand libtool well enough 
to fix the problem and would be grateful of some help.  Although I have 
mentioned wxWidgets, I am inclined to think that it is more appropriate to ask 
help from the libtool community than the wxWidgets community.

Here is the failing command:

libtool --mode=link g++ -shared -o libGUI.so   -rpath 
/usr/local/lib -rpath /usr/lib64 -pthread -Wl,-Bsymbolic-functions  
-lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 
-lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 
-lwx_baseu_net-2.8 -lwx_baseu-2.8  -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 
-lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 
-lgthread-2.0 -lrt -lglib-2.0
libtool: link: g++ -o libGUI.so  -pthread 
-Wl,-Bsymbolic-functions -pthread  -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 
-lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 
-lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 
/usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so 
/usr/lib/libgio-2.0.so /usr/lib/libpangoft2-1.0.so 
/usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so 
/usr/lib/libcairo.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so 
-lfontconfig /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so 
/usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -pthread -Wl,-rpath 
-Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/lib64
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'

Now, on the previous (working) environment, libtool created a command that 
started with:

g++ -shared -o /libGUI.so

whereas the failing command (above) starts with:

libtool: link: g++ -o libGUI.so

I realise that the absence of '-shared' in the latter is probably causing my 
problem.  Why is it not present please?

Best regards

David

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

Libtool and GPLv3

2011-09-03 Thread Christophe Jarry

Dear developers,

Is there a plan to release GNU Libtool under GPLv3 or later?

Ralf seemed to say so in his post from 2008 at
https://lists.gnu.org/archive/html/libtool/2008-02/msg00069.html:

Well, yes, eventually we will switch the various differently-licensed
parts of Libtool to version 3 or later of the GPL, LGPL, including the
exception clauses (see the file HACKING in the CVS tree about the
individual licensing rules).  We are still waiting for the lawyers to
reformulate the exception clauses in the way that GPLv3 specifies
additions to happen to that license.  But I strongly expect 2.2 to be
released before that happens.

Christophe

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

Re: bug#9257: configure errors after upgrade to libtool 2.4

2011-08-21 Thread Russ Allbery

Julien ÉLIE  writes:

> It seems to be related to:

> SED='`$ECHO "$SED" | $SED "$delay_single_quote_subst"`'
> Xsed='`$ECHO "$Xsed" | $SED "$delay_single_quote_subst"`'
> macro_version='`$ECHO "$macro_version" | $SED "$delay_single_quote_subst"`'
> macro_revision='`$ECHO "$macro_revision" | $SED "$delay_single_quote_subst"`'
> [...]

> Thanks beforehand for your help on that subject.

INN is trying to do something weird by making use of libtool conditional
(my fault originally), and I suspect that something about the structure of
its configure.ac is causing $delay_single_quote_subst to not be set to
anything, leading sed to be invoked with the empty string as a command.

-- 
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>

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

Re: bug#9257: configure errors after upgrade to libtool 2.4

2011-08-21 Thread Julien ÉLIE

Hi all,

Following an issue reported in:
  https://lists.gnu.org/archive/html/bug-libtool/2011-08/msg00012.html

I found out that upgrading from libtool 2.2.6b to libtool 2.2.8 already
triggers the error off.
Would it be related to the $Xsed -> $SED switch?  Is there something that
should be taken care of in configure.ac owing to that change?


Here are log files from an attempt to configure INN (a news server):
http://iulius.dinauz.org/libtool-inn/


You will see at the end of output.console:


checking for Unix domain sockets... yes
checking log facility for news... LOG_NEWS
configure: creating ./config.status
Usage: /bin/sed [OPTION]... {script-only-if-no-other-script} [input-file]...
[...]
./configure: line 20068: /bin/sed -e 1s/^X//: No such file or directory
./configure: line 20068: : command not found
./configure: line 20068: : command not found
./configure: line 20068: : command not found
./configure: line 20068: : command not found
./configure: line 20068: : command not found
./configure: line 20068: : command not found
./configure: line 20068: : command not found
./configure: line 20068: : command not found
./configure: line 20068: i686-pc-linux-gnu: command not found
./configure: line 20068: linux-gnu: command not found
./configure: line 20068: : command not found
./configure: line 20068: i686-pc-linux-gnu: command not found
./configure: line 20068: linux-gnu: command not found
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
./configure: line 20068: /bin/grep -E: No such file or directory
./configure: line 20068: : command not found
./configure: line 20068: : command not found
[...]



It seems to be related to:

SED='`$ECHO "$SED" | $SED "$delay_single_quote_subst"`'
Xsed='`$ECHO "$Xsed" | $SED "$delay_single_quote_subst"`'
macro_version='`$ECHO "$macro_version" | $SED "$delay_single_quote_subst"`'
macro_revision='`$ECHO "$macro_revision" | $SED "$delay_single_quote_subst"`'
[...]


Thanks beforehand for your help on that subject.

-- 
Julien ÉLIE

« – Hou hou !
  – Ouille, ouille !
  – Ouf !
  – Où ouf ? » (Astérix)

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

PATCH: Don't fall back to static libraries if building them was disabled. (was: libtool shouldn't switch to creating static library if it can't create the shared one under Windows)

2011-07-07 Thread Vadim Zeitlin

On Thu, 23 Jun 2011 23:07:17 +0200 Peter Rosin  wrote:

PR> Den 2011-06-23 14:25 skrev Vadim Zeitlin:
PR> > Am I the only one to think that this behaviour is singularly
PR> > unhelpful?
PR> 
PR> Of course not, others have stated that a patch would be welcome to
PR> fix --disable-static (and --enable-shared) to error out if it is not
PR> possible to create a shared library (due to a missing -no-undefined).

 Sorry for the delay, I got distracted by other things but here is finally
the promised trivial patch (I also cc it to libtool-patches just in case,
sorry if you get this message twice):


From: Vadim Zeitlin 
Date: Thu, 7 Jul 2011 17:26:43 +0200
Subject: [PATCH] Don't fall back to static libraries if building them was 
disabled.

If -no-undefined was not specified but the platform didn't support shared
libraries with undefined symbols (e.g. Cygwin/MinGW), static libraries were
built instead of shared ones, even if building them was explicitly disabled
with --disable-static configure option.

Fix this by stopping with a fatal error if a shared library can't be built in
this case instead of unexpectedly building a static library instead.

* libltdl/config/ltmain.m4sh (func_mode_link()): Stop with fatal error when
trying to build a shared library without -no-undefined on a platform not
supporting undefined symbols in shared libraries.

Signed-off-by: Vadim Zeitlin 
---
 libltdl/config/ltmain.m4sh |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 8e5c588..40b1d5f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6735,9 +6735,12 @@ func_mode_link ()
# Check to see if the archive will have undefined symbols.
if test "$allow_undefined" = yes; then
  if test "$allow_undefined_flag" = unsupported; then
-   func_warning "undefined symbols not allowed in $host shared 
libraries"
-   build_libtool_libs=no
-   build_old_libs=yes
+   if test "$build_old_libs" = yes; then
+ func_warning "undefined symbols not allowed in $host shared 
libraries"
+ build_libtool_libs=no
+   else
+ func_fatal_error "can't build $host shared library unless 
-no-undefined is specified"
+   fi
  fi
else
  # Don't allow undefined symbols.
-- 
1.7.2.3


I've tested this patch with the default and --disable-static configurations
under Windows and Linux and it behaved as expected. Maybe the error message
could be improved but I tried to remain consistent with the existing
warning, if this consideration is not important it might be better to be
more explicit about the problem and its potential solution.


PR> But fixing that is a separate issue from what the default behavior
PR> should be when -no-undefined is not specified.

 I agree with this but I still disagree that the current default behaviour
is useful. IMO both (C1) and (C3) should try to build a shared library even
if -no-undefined was not given and simply either stop with a fatal error or
fall back to a static library if it failed. I don't see how could getting a
shared library in addition to the static one in the case (C3) could ever be
a problem and getting the expected result in the case (C1) is definitely an
advantage and not a drawback.

 But I won't discuss this any more as I don't have any new arguments and
apparently the ones I already gave were insufficiently convincing.

 Regards,
VZ


pgpgD5ub1Glcm.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool not generating / installing .so, even tho config says it should

2011-07-06 Thread Scott Robert Ladd

Thank you ever so much. In past editions, the compiles included the default
CFLAGS followed by the ones I specified.

..Scott

On Wed, Jul 6, 2011 at 2:26 AM, Ralf Corsepius  wrote:

> On 07/06/2011 01:54 AM, ScottLadd wrote:
>
>>
>>
>> I've been writing configure.ac scripts for a long time, and now,
>> unexpectedly, on a new Kubuntu 11.04 installation and on a Fedora 15
>> install, libtool not longer generates and installs shared objects. Same
>> scripts I've used before, different behavior.
>>
>
> I don't know if this had ever worked, but the culprit seems to be this part
> of your configure.ac:
>
> if test "x$gccopt" = "xyes"
> then
>CFLAGS="-std=gnu99 -pedantic -Wall -Wno-format -lpthread -lrt -O2 -g0
> -march=native"
> else
>CFLAGS="-std=gnu99 -pedantic -Wall -Wno-format -lpthread -lrt -g -O2
> -static"
> fi
>
>
> Besides this, this part overrides CFLAGS with hard-coded compiler- and
> system-specific CFLAGS - Not a good idea.
>
> Ralf
>
> __**_
> https://lists.gnu.org/mailman/**listinfo/libtool<https://lists.gnu.org/mailman/listinfo/libtool>
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool not generating / installing .so, even tho config says it should

2011-07-05 Thread Ralf Corsepius


On 07/06/2011 01:54 AM, ScottLadd wrote:



I've been writing configure.ac scripts for a long time, and now,
unexpectedly, on a new Kubuntu 11.04 installation and on a Fedora 15
install, libtool not longer generates and installs shared objects. Same
scripts I've used before, different behavior.


I don't know if this had ever worked, but the culprit seems to be this 
part of your configure.ac:


if test "x$gccopt" = "xyes"
then
CFLAGS="-std=gnu99 -pedantic -Wall -Wno-format -lpthread -lrt -O2 
-g0 -march=native"

else
CFLAGS="-std=gnu99 -pedantic -Wall -Wno-format -lpthread -lrt -g 
-O2 -static"

fi


Besides this, this part overrides CFLAGS with hard-coded compiler- and 
system-specific CFLAGS - Not a good idea.


Ralf

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

libtool not generating / installing .so, even tho config says it should

2011-07-05 Thread ScottLadd

I've been writing configure.ac scripts for a long time, and now,
unexpectedly, on a new Kubuntu 11.04 installation and on a Fedora 15
install, libtool not longer generates and installs shared objects. Same
scripts I've used before, different behavior.

Note: The configure.ac/Makefile.am in question DID install shared objects in
the past.

When I run configure, it states:

checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes

Upon running make install, I see:

test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
/bin/bash ../libtool --mode=install /usr/bin/install -c libbrahe.la
'/usr/local/lib'
libtool: install: /usr/bin/install -c .libs/libbrahe.lai
/usr/local/lib/libbrahe.la
libtool: install: /usr/bin/install -c .libs/libbrahe.a
/usr/local/lib/libbrahe.a
libtool: install: chmod 644 /usr/local/lib/libbrahe.a
libtool: install: ranlib /usr/local/lib/libbrahe.a

I've hunted up and down, to no avail, trying to figure out what's wrong. Did
something change in a recent update to autotools? My versions are:

libtool 2.2.6b
automake 1.11.1
autoconf 2.67

The actual library code can be downloaded from
http://www.coyotegulch.com/products/brahe/index.html Brahe Library

--
View this message in context:
http://old.nabble.com/libtool-not-generating---installing-.so%2C-even-tho-config-says-it-should-tp32001082p32001082.html
Sent from the Gnu - Libtool - Discuss mailing list archive at Nabble.com.
_______
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-25 Thread Vadim Zeitlin

Charles Wilson  cwilson.fastmail.fm> writes:

> No, what it means is that, IF the project maintainers want to support
> shared libraries (DLLs) on win32, then they must do the following -- and
> this is true regardless of whether libtool is involved.

 I think the real problem is that we differ in our understanding of how the
development of a typical project work. You assume that the developers know
in advance everything there is to know about Win32 DLLs and libtool but IME
this is not always the case, especially for the latter. So while I can't
disagree that what you wrote should happen in an ideal case, a more typical
scenario is simply that somebody tries to build the project under Windows.
If there are undefined symbol errors, they will be fixed and maybe, just
maybe, while doing it the person attempting the build will also discover
libtool --no-undefined flag but maybe not even then. What is almost certain
however is that if there are no undefined symbol errors (which is a rather
common case after all) there is going to be much head-scratching because of
libtool seemingly unmotivated refusal to build the shared libraries even
so.

 IOW maybe the simplest solution would be to just include a mention of
--no-undefined in the warning message given by libtool when it decides to
skip building the shared library. E.g. replace the current

libtool: link: warning: undefined symbols not allowed in $host shared libraries

message with something more user-friendly like this:

libtool: link: warning: Skipping the generation of the shared library as
undefined symbols are not allowed in $host shared libraries.
Use -no-undefined option to allow building it if there are really
no undefined symbols.

With the current message it's far from clear that libtool isn't going to
build the shared library (it just warns about something but doesn't say
explicitly what does it mean) nor, most importantly, what can be done about
it.

> 2) Once you've gone thru the exercise in #1, now you might as well add
> -no-undefined unconditionally to your libtool invocation -- if you are
> using libtool, that is.

 Exactly! If you don't use libtool, you don't need to do anything special
and can just run the same "g++ -shared ..." command as under Unix provided
you don't really have any undefined symbols. But if you do use libtool you
need to know to use -no-undefined to prevent libtool from quasi-silently
deciding that your shared library can't be built for you.

 Anyhow, to use the terminology of Peter Rosin's reply, I'm going to resume
my efforts to provide a patch to at least fix this for the case (C1). But
personally I remain convinced that the current behaviour in case (C3) is
very unhelpful. Hopefully at least the warning message could be modified as
proposed above to make it slightly less so.

 Regards,
VZ

_______
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-23 Thread Charles Wilson

On 6/23/2011 11:03 AM, Vadim Zeitlin wrote:
> On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn 
>  wrote:
> 
> BF> On Thu, 23 Jun 2011, Vadim Zeitlin wrote:
> BF> >
> BF> > I.e. it created a shared library with undefined symbols without any
> BF> > problems because it never actually passed -no-undefined to g++/ld.
> BF> 
> BF> In actual practice, it seems difficult or impossible to build programs 
> BF> under systems like Linux with -no-undefined.
> 
>  I didn't know this but doesn't this make the situation even worse? I.e.
> because of the above you can't even recommend people to use -no-undefined
> by default. So the default behaviour will remain the current one, i.e. no
> DLLs at all under Windows.

No, what it means is that, IF the project maintainers want to support
shared libraries (DLLs) on win32, then they must do the following -- and
this is true regardless of whether libtool is involved.

1) Ensure that when building for win32, that the various object files
that will be combined into the DLL, as well as the library dependencies
(-lwhatever) are such that there WILL BE no undefined symbols, at least
*when building for win32*.  Otherwise, ld will refuse to create the DLL.

This may involve restructuring the code, and possibly changing the
division of labor between various DLLs if your project has multiple
interdependent ones.  It is *very* difficult to build stuff on win32
where you have circular dependencies between DLLs, or between DLLs and
an EXE -- not impossible, just very difficult. (*)

Now, if you are going to go thru all that trouble to support
win32...you'd just be making a lot of extra work for yourself to
maintain TWO separate library structures -- one for win32 (and, btw,
AIX) where everything is "no undefined symbols" clean, and one for
everything else where undefined symbols are allowed.  So...most projects
that end up in this place (**), finally decide to restructure their
shared libraries for *ALL* platforms.

Notice I haven't said anything about libtool yet.

2) Once you've gone thru the exercise in #1, now you might as well add
-no-undefined unconditionally to your libtool invocation -- if you are
using libtool, that is.  Remember, all the stuff in #1 is required just
to build DLLs on win32 *at all*, libtool or no libtool.

(*) You basically have to create an export file for DLL A (or the EXE),
and an import lib for it.  THEN, you can build DLL B as normal, and
specify -lDLLA (or -lEXE).  Finally, you build the "real" DLL A (or
EXE), and specify -lDLLB.  Libtool has /no/ direct mechanism to support
this.

(**) Except for those that use a "plugin" architecture, where the plugin
DLLs *must* be able to call back to the EXE.  That's really tricky, and
they usually end up using another solution, of which there are several
(see http://edll.sourceforge.net/ for a good description of several
different approaches).  But that's outside the scope of our discussion here.

--
Chuck

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

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-23 Thread Peter Rosin

Den 2011-06-23 14:25 skrev Vadim Zeitlin:
> On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin  wrote:
> 
> PR> Den 2011-06-23 11:22 skrev Vadim Zeitlin:
> PR> >  I have no idea whether -no-undefined is supposed to work like this but 
> in
> PR> > any case it seems to me that it's perfectly useless right now. It's not
> PR> > checked at all under normal Unix systems so it can't be used to ensure 
> that
> PR> > a shared library actually doesn't have any undefined symbols and so 
> could
> PR> > be created under Windows too. And it must be always specified under
> PR> > Windows as otherwise DLL are never created at all.
> PR> 
> PR> If you really are targeting Windows (or some other platform which needs
> PR> -no-undefined to build libtool libraries) then you really do get a failure
> PR> if there are undefined symbols.
> 
>  Yes but *only* if you had "-no-undefined" in your Makefile.am. If you do
> not specify "-no-undefined", you practically silently (not quite as it does
> output "libtool: link: warning: undefined symbols not allowed in $host
> shared libraries" but this is very easy to miss) get a static library
> instead, whether there are any undefined symbols or not.
> 
>  This is even worse than the original problem that I had because at least
> you had a big fat warning with plenty of asterisks in that case because
> there was another problem in that case. But if all goes perfectly well you
> still never get a shared library without "no-undefined". Even if you
> specified --disable-static as you did in my example (although IMO even
> without it silently creating static library when a shared one was requested
> is wrong). Am I the only one to think that this behaviour is singularly
> unhelpful?

Of course not, others have stated that a patch would be welcome to
fix --disable-static (and --enable-shared) to error out if it is not
possible to create a shared library (due to a missing -no-undefined).
But fixing that is a separate issue from what the default behavior
should be when -no-undefined is not specified. The think the push-
back you are sensing is because you are mixing those two issues.

The thing is, if you really do have undefined symbols, *and* are
targeting Windows (or other platforms needing -no-undefined for "normal"
libraries), there is no (clean & simple) way to explicitly declare that
you don't want libtool to attempt to build the shared lib, you can
only implicitly declare that fact by *not* specifying -no-undefined. At
the same time, you want failures to be reported back and interrupt the
build, for cases where you really do hit undefined symbols.

Let me attempt to line up all the cases:

A. We know that there are no undefined symbols, -no-undefined is
   specified.
B. We know that there are undefined symbols, -no-undefined is
   not specified.
C. Noone has bothered to check for undefined symbols, package was
   never ported to Windows, -no-undefined is not specified.

1. --disable-static in effect
2. --disable-shared in effect
3. Build both static and shared, or whatever is possible.

For A1 and B1 we want to error out on Windows if we can't find
shared versions of all dependencies, because we do not want to
risk including static libs in the resulting shared lib, and we
don't want to fall back to a static lib since a shared lib was
explicitly requested. IMO there is a bug for this case, since
currently libtool falls back to creating a static lib when it
can satisfy missing symbols with static dependencies. You also
think this is a bug, and I don't think anyone disagrees with
you, me, Bob and Chuck that it really is a bug.

For A2, B2 and C2, there is no problem, you get a static lib.
For A3 and B3, there is no problem, but you don't get a shared lib
on Windows (as desired, don't want to risk static dependencies
inside the shared lib).

For C1, it would perhaps be nice to go looking for shared versions
of all dependencies and then attempt to link the library and fail
if any of that didn't work out. But see below (-*-).

For C3, I can agree that libtool *could* look for shared versions
of all dependencies and if found, libtool *could* attempt to create
the shared lib, hoping that there would be no undefined symbols.
I.e. just as in C1, but then not error out if any of that fails but
instead just ignore the failure and proceed with a static-only
result as if nothing happened. But I must say that it would be kind
of surprising to one day get both a static lib and a shared lib, and
the next day "silently" only get a static lib because some bozo
broke something (completely unrelated) for Windows. True, the bozo
code would perhaps fail on Windows for the static case as well,
but maybe not.

And since it is a bit fragile to make that

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-23 Thread Bob Friesenhahn


On Thu, 23 Jun 2011, Vadim Zeitlin wrote:


I.e. it created a shared library with undefined symbols without any
problems because it never actually passed -no-undefined to g++/ld.


In actual practice, it seems difficult or impossible to build programs 
under systems like Linux with -no-undefined.  I tried this before, but 
glibc got in the way since it depends on some symbols which are 
never/rarely defined.  Under Linux, programs run just fine with 
undefined symbols as long as they are never accessed.



I have no idea whether -no-undefined is supposed to work like this but in
any case it seems to me that it's perfectly useless right now. It's not


Not quite useless, but not pedantically useful either.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

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

Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn 
 wrote:

BF> On Thu, 23 Jun 2011, Vadim Zeitlin wrote:
BF> >
BF> > I.e. it created a shared library with undefined symbols without any
BF> > problems because it never actually passed -no-undefined to g++/ld.
BF> 
BF> In actual practice, it seems difficult or impossible to build programs 
BF> under systems like Linux with -no-undefined.

 I didn't know this but doesn't this make the situation even worse? I.e.
because of the above you can't even recommend people to use -no-undefined
by default. So the default behaviour will remain the current one, i.e. no
DLLs at all under Windows.

BF> > I have no idea whether -no-undefined is supposed to work like this but in
BF> > any case it seems to me that it's perfectly useless right now. It's not
BF> 
BF> Not quite useless, but not pedantically useful either.

 Useless and useful are subjective, of course, but what seems undeniably
objective to me is that currently libtool by default doesn't create shared
libraries under Windows at all, even with --disable-static (although,
again, --disable-static shouldn't be considered as a solution for this) and
you need to force it to do it by using -no-undefined explicitly. Moreover,
you may need to do this conditionally, for Windows only, as this could
break things under Linux apparently. And this drastically reduces libtool
usefulness under Windows.


 To put it in another way, currently libtool supposes that a shared library
has undefined symbols by default. There would be nothing intrinsically
wrong with this assumption but it results in clearly broken behaviour. So
IMO it must be changed. I think that ideally libtool should be capable of
determining on its own whether the library has undefined symbols or not.
But if/as this is too difficult to implement, for now a more reasonable
approach would be to admit that libtool doesn't know whether this is the
case and try to do its best with this information and try to create shared
libraries under Windows by default. If -no-undefined is explicitly
specified it wouldn't then change anything for its behaviour under Windows
and similar platforms (AIX?). Finally, some new -has-undefined option might
be introduced to explicitly tell libtool that a library really does have
unresolved external symbols and so can't be built under Windows.

 What do you think?
VZ


pgpNR49pd50KF.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin  wrote:

PR> Den 2011-06-23 11:22 skrev Vadim Zeitlin:
PR> >  I have no idea whether -no-undefined is supposed to work like this but in
PR> > any case it seems to me that it's perfectly useless right now. It's not
PR> > checked at all under normal Unix systems so it can't be used to ensure 
that
PR> > a shared library actually doesn't have any undefined symbols and so could
PR> > be created under Windows too. And it must be always specified under
PR> > Windows as otherwise DLL are never created at all.
PR> 
PR> If you really are targeting Windows (or some other platform which needs
PR> -no-undefined to build libtool libraries) then you really do get a failure
PR> if there are undefined symbols.

 Yes but *only* if you had "-no-undefined" in your Makefile.am. If you do
not specify "-no-undefined", you practically silently (not quite as it does
output "libtool: link: warning: undefined symbols not allowed in $host
shared libraries" but this is very easy to miss) get a static library
instead, whether there are any undefined symbols or not.

 This is even worse than the original problem that I had because at least
you had a big fat warning with plenty of asterisks in that case because
there was another problem in that case. But if all goes perfectly well you
still never get a shared library without "no-undefined". Even if you
specified --disable-static as you did in my example (although IMO even
without it silently creating static library when a shared one was requested
is wrong). Am I the only one to think that this behaviour is singularly
unhelpful?

PR> Quoting the docs for the libtool -no-undefined option:
...
PR> I.e. no mention of any actual check if there were any undefined
PR> symbols.

 I agree that the current behaviour conforms to documentation. I just think
it's pretty bad and I dare say that I'm not alone to misunderstand it
because of expecting something useful from this option.

PR> However, I agree that it is awkward. If this was done today, with
PR> no backwards compatibility in mind, I'd say that -no-undefined should
PR> be the default and any packages that truly needed undefined symbols
PR> should somehow declare that instead, since that is more of a special
PR> case (IMHO). But it is as it is.

 I continue to believe that it's much worse than awkward under Windows.
Libtool should try to create DLLs there and fail if it doesn't work. Not
even trying is the worst possible solution.

 For me the ideal behaviour would be to try to link a DLL and stop with an
error if it doesn't work but according to the beginning of this thread,
this is not acceptable by default. So I can only propose:

1. At least do this when --disable-static is specified.
2. Try to link as DLL in any case (well, unless --disable-shared was used)
   and only fall back to static linking if it actually failed instead of
   giving up in advance just because -no-undefined wasn't used.

I probably could hack libtool to do (1) but I'm not sure I could do (2)
which is, IMHO, even more important.

 Any comments?
VZ


pgpQv8Wb5Takd.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-23 Thread Peter Rosin

Den 2011-06-23 11:22 skrev Vadim Zeitlin:
> Charles Wilson  cwilson.fastmail.fm> writes:
> 
>> On 6/21/2011 8:29 AM, Vadim Zeitlin wrote:
>>> Charles Wilson  writes:
>>>> No, I think --disable-static, if specified, should actually *disable
>>>> static*.  That should be sufficient.
>>>>
>>>> If it's not doing that, then it's a bug IMO.
>>>
>>>  Just to confirm: no, currently it doesn't do this. The example of my
>>> original message came from libxml2 build configured with --disable-static.
>>>
>>>  So should I try to create a patch making libtool fail in this case?
>>
>> I think so.
> 
>  So I did try. Unfortunately I didn't succeed because after looking closer
> at libtool sources, things turned out to be much more complicated than I
> thought -- or at least very different from what I thought that would be.
> 
>  I naively expected the presence of "-no-undefined" in foo_la_LDFLAGS to
> result in passing the equivalent of "-Wl,-no-undefined" to the compiler for
> the platforms where shared libraries with undefined symbols are supported
> (i.e. allow_undefind_flag != "unsupported"). But this is not at all what
> happens. In fact, libtool doesn't seem to have any logic for actually
> ensuring that shared libraries with -no-undefined actually have no
> undefined symbols! Indeed, just look at this transcript:
> 
>   % cat configure.ac
>   AC_INIT([foo],[1.0])
>   AM_INIT_AUTOMAKE
>   AC_CONFIG_SRCDIR([foo.c])
> 
>   LT_INIT([disable-static])
>   AC_PROG_CC
> 
>   AC_CONFIG_FILES([Makefile])
>   AC_OUTPUT
>   % cat Makefile.am
>   lib_LTLIBRARIES = libfoo.la
>   libfoo_la_SOURCES = foo.c
>   libfoo_la_LDFLAGS = -no-undefined
>   % cat foo.c
>   extern void foo();
>   void foo2()
>   {
>   foo();
>   foo();
>   }
>   % mkdir build && cd $_
>   % ../configure >/dev/null
>   % make -s
>   libtool: compile:  gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
> -DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"foo 1.0\""
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"foo\" 
> -DVERSION=\"1.0\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
> -I.
> -I.. -g -O2 -MT foo.lo -MD -MP -MF .deps/foo.Tpo -c ../foo.c  -fPIC -DPIC -o
> .libs/foo.o
>   libtool: link: gcc -shared  -fPIC -DPIC  .libs/foo.o-O2   
> -Wl,-soname
> -Wl,libfoo.so.0 -o .libs/libfoo.so.0.0.0
>   libtool: link: (cd ".libs" && rm -f "libfoo.so.0" && ln -s 
> "libfoo.so.0.0.0"
> "libfoo.so.0")
>   libtool: link: (cd ".libs" && rm -f "libfoo.so" && ln -s 
> "libfoo.so.0.0.0"
> "libfoo.so")
>   libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la"
> "libfoo.la" )
> 
> 
> I.e. it created a shared library with undefined symbols without any
> problems because it never actually passed -no-undefined to g++/ld.
> 
>  I have no idea whether -no-undefined is supposed to work like this but in
> any case it seems to me that it's perfectly useless right now. It's not
> checked at all under normal Unix systems so it can't be used to ensure that
> a shared library actually doesn't have any undefined symbols and so could
> be created under Windows too. And it *must* be always specified under
> Windows as otherwise DLL are never created at all.

If you really are targeting Windows (or some other platform which needs
-no-undefined to build libtool libraries) then you really do get a failure
if there are undefined symbols.

>  And setting allow_undefined to "yes" in the beginning of func_mode_link()
> (after commenting out the line above that sets it to "no") illustrates the
> same point: all this logic is at best useless and at worst broken as long
> as libtool doesn't have any support for actually determining whether a
> library has any undefined symbols because the *only* reasonable thing to do
> for any project that targets Windows is to use -no-undefined in LDFLAGS and
> hope for the best. In particular, the default case of having an LTLIBRARY
> that does not include -no-undefined in its LDFLAGS does not work at

Re: warning about _putenv redeclaration without dllimport in libtool wrapper script

Vadim Zeitlin  zeitlins.org> writes:

> And as this project build options also include "-std=c++0x",
> __STRICT_ANSI__ is defined. For the compiler I use it would be enough to
> add _CRTIMP in front of the declaration as this is how _putenv() is really
> declared in /usr/i686-w64-mingw32/sys-root/mingw/include/stdlib.h but I'm
> not sure if all MinGW versions define _CRTIMP. I did check that 3.4.5,
> 4.4.0 and 4.5.0 (native, i.e. not Cygwin) MinGW versions do define it but I
> don't have access to earlier versions any more.
> 
>  Does anybody know if _CRTIMP is safe to use for all MinGW versions?

 After looking further, I think it is, so I sent the corresponding trivial
patch to libtool-patches.

 Please let me know if you see any problems with it. Thanks,
VZ


_______
https://lists.gnu.org/mailman/listinfo/libtool

Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows