Re: GNU libtool-2.4.4 released [stable]

2014-12-02 Thread Lawrence Velázquez
On Dec 1, 2014, at 5:39 AM, Gary V. Vaughan  wrote:

> Yes, as you discovered, starting with Libtool-2.4.3 GNU M4 is required by 
> libtoolize, because we now dynamically run the configure.ac through it to 
> reliably detect build characteristics (as opposed to earlier releases which 
> grepped and sedded through aclocal.m4 and configure.ac looking for magic 
> strings heuristically).

What minimum version of M4 is required?

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


Re: GNU libtool-2.4.4 released [stable]

2014-12-02 Thread Gary V. Vaughan
Hi Lawrence,

> On 2 Dec 2014, at 08:05, Lawrence Velázquez  wrote:
> 
>> On Dec 1, 2014, at 5:39 AM, Gary V. Vaughan  wrote:
>> 
>> Yes, as you discovered, starting with Libtool-2.4.3 GNU M4 is required by 
>> libtoolize, because we now dynamically run the configure.ac through it to 
>> reliably detect build characteristics (as opposed to earlier releases which 
>> grepped and sedded through aclocal.m4 and configure.ac looking for magic 
>> strings heuristically).
> 
> What minimum version of M4 is required?
> 
> vq

Anything that works with modern Autoconf should be fine.

I haven't tested Libtool against every combination, but (more than 8 years old) 
1.4.6 comes with Mac OS X 10.10.1 and works for me.  There are known problems 
with 1.4.11 through 1.4.15 so best avoid those too.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

2014-12-02 Thread Filipe Brandenburger
Hi Gary, Bob,

Thanks for your feedback!

In the end, I found Roumen Petrov replied to the list indicating that
setting lt_cv_sys_lib_dlsearch_path_spec when calling configure might
be able to solve this and indeed it did.

http://lists.gnu.org/archive/html/libtool/2014-08/msg4.html

By passing lt_cv_sys_lib_dlsearch_path_spec="${stagedir}/usr/lib" (I'm
not linking to anything under the system's /usr/lib so it's OK for me
to omit it) I managed to get it not to add that directory to the
rpath.

I wish that this "sys_lib_dlsearch_path_spec" variable was better
documented in libtool's documentation... I'd be happy to try to
contribute but unfortunately I don't think I understand them well
enough to give them a good description... Let me know if you think I
could help with it anyhow.

Replying to some of your comments:

On Fri, Nov 28, 2014 at 10:37 AM, Bob Friesenhahn
 wrote:
> I am not sure what OS is being discussed here since it was never mentioned.

This is on GNU/Linux and I'm using either the GNU ld and the gold
linker (ideally I want both to work.) Both seem to support -rpath and
-rpath-link but that doesn't seem to be part of the problem (as just
adding the directory to lt_cv_sys_lib_dlsearch_path_spec was enough to
solve it.)

> GNU ld on GNU/Linux has these options:
>
>   -rpath PATH Set runtime shared library search path
>   -rpath-link PATHSet link time shared library search path
>
> Notice that one is the path used for the installed library and the other is
> for linking.  It is more correct to use -rpath-link for libraries which are
> not in their final resting place.  However, the libraries do remember the
> -rpath-link option which was used when they were linked, and libraries
> linked with them inherit the option (to support cascading linkage).

So in my actual case I'm installing libraries to a ${GNU_PLATFORM}
subdirectory of /usr/lib where ${GNU_PLATFORM} is set to the GNU
triplet.

So, I'm actually passing ./configure both the
lt_cv_sys_lib_dlsearch_path_spec="${stagedir}/usr/lib/${GNU_PLATFORM}"
variable and also LDFLAGS="-Wl,-rpath,/usr/lib/${GNU_PLATFORM}
-Wl,-rpath-link,${stagedir}/usr/lib/${GNU_PLATFORM}" which gets it to
*add* the -rpath I want and to link to the libraries in the correct
location.

> I don't think that linking against libraries in DESTDIR is portable. DESTDIR
> should be considered an install/copy-only option to support packaging.

Well, in my use case I'm often/usually cross compiling so having the
final libraries installed under /usr/lib is not really an option... It
seems that lt_cv_sys_lib_dlsearch_path_spec solved the issue for me,
but I'm not 100% positive how portable that is, if you can think of
some reasons why this is not a good fix and if there's a cleaner way
to accomplish this then please let me know.

Cheers,
Filipe

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


Re: Trying to get libtool not to add -rpath, since libs are only in a staging directory

2014-12-02 Thread Bob Friesenhahn

On Tue, 2 Dec 2014, Filipe Brandenburger wrote:



I don't think that linking against libraries in DESTDIR is portable. DESTDIR
should be considered an install/copy-only option to support packaging.


Well, in my use case I'm often/usually cross compiling so having the
final libraries installed under /usr/lib is not really an option... It
seems that lt_cv_sys_lib_dlsearch_path_spec solved the issue for me,
but I'm not 100% positive how portable that is, if you can think of
some reasons why this is not a good fix and if there's a cleaner way
to accomplish this then please let me know.


This solves the problem (automatic addition of -rpath) caused by 
libtool on GNU/Linux.  It is not truely portable since it can not 
solve automatic tool behavior on other operating systems.


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