Re: Trailing slash in directory spec confuses libtool

On 2016-08-13 00:06, Richard Purdie wrote: > On Fri, 2016-08-12 at 22:06 +0200, Jan Engelhardt wrote: >> Given certain circumstances, libtool 2.4.2 fails to install a >> library. >> (a) The target directory spec contains a trailing slash >> (b) The library to install is linking to another just-b

Re: MSW DLLs support in libtool

On 2016-02-12 21:59, Vadim Zeitlin wrote: > Peter Rosin writes: >> On 2016-02-11 00:38, Bob Friesenhahn wrote: >>> It indicates that the build configuration has agreed to supply any >>> additional dependency libraries if there otherwise would be undefined >>&g

Re: MSW DLLs support in libtool

On 2016-02-12 22:12, Vadim Zeitlin wrote: > Several concrete questions in this thread asking for any benefits of the > current libtool behaviour went unanswered, but let me try once again > nevertheless: do you see any useful consequences of performing the check > for PIC when targeting Windows

Re: MSW DLLs support in libtool

On 2016-02-11 12:23, Evgeny Grin wrote: > On 11.02.2016 11:03, Peter Rosin wrote: >> Well said, I would also like to add that libtool -no-undefined *does* *not* >> imply ld --no-undefined. I.e. If you add libtool -no-undefined, then the >> *only* thing that changes is

Re: MSW DLLs support in libtool

On 2016-02-11 00:38, Bob Friesenhahn wrote: > On Wed, 10 Feb 2016, Evgeny Grin wrote: >> >> As result - "-no-undefined" is used only on W32 without any practical >> benefit: if lib have some undefined symbols, it will not be build on W32 >> as shared lib regardless of "-no-undefined" flag. And co

Re: MSW DLLs support in libtool

Hi! [Replying to various things across the thread] On 2016-02-10 04:53, Vadim Zeitlin wrote: > On Tue, 9 Feb 2016 21:29:23 -0600 (CST) Bob Friesenhahn > wrote: > > BF> On Wed, 10 Feb 2016, Vadim Zeitlin wrote: > BF> > > BF> > Sorry but this is just not true for the MSW DLLs. If the libtool use

Re: [PATCH] Support MSYS2

On 2015-08-09 21:26, fabrizio...@tiscali.it wrote: > The output of uname -o is indeed the same in MSYS2 and MinGW/MSYS > > Msys > > However, that is irrelevant because, config.guess does not use uname -o, it > does uname -s > > UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown > >

Re: [Mingw-users] [PATCH] Support MSYS2

On 2015-07-24 23:32, Greg Jung wrote: > On Fri, Jul 24, 2015 at 2:03 PM, Peter Rosin <mailto:p...@lysator.liu.se>> wrote: >> >> [ mingw-users: this is in reply to a suggested patch (1) ] >> >> On 2015-07-23 19:30, fabrizio...@tiscali.it >

Re: [PATCH] Support MSYS2

[ mingw-users: this is in reply to a suggested patch (1) ] On 2015-07-23 19:30, fabrizio...@tiscali.it wrote: > Hello, > when using the MSYS2 shell (http://msys2.github.io/), uname -o returns Msys > instead of mingw32. The latest versions of config.guess and config.sub > already support that, bu

Re: Performance issue of libtool-2.4.4

On 2015-02-09 14:05, Richard Purdie wrote: > On Mon, 2015-02-09 at 10:45 +0800, Robert Yang wrote: >> On 02/06/2015 10:46 PM, Bob Friesenhahn wrote: >>> On Fri, 6 Feb 2015, Robert Yang wrote: >>> On 02/06/2015 12:12 PM, Bob Friesenhahn wrote: > I am not seeing quite the differenc

Re: Performance issue of libtool-2.4.4

On 2015-02-06 10:30, Gary V. Vaughan wrote: > Hi Peter, > >> On Feb 6, 2015, at 9:22 AM, Peter Rosin wrote: >> >>> On 2015-02-04 15:48, Bob Friesenhahn wrote: >>>> On Wed, 4 Feb 2015, Robert Yang wrote: >>>> >>>> When reporting a bu

Re: Performance issue of libtool-2.4.4

On 2015-02-04 15:48, Bob Friesenhahn wrote: > On Wed, 4 Feb 2015, Robert Yang wrote: > >> When reporting a bug, please describe a test case to reproduce it and >> include the following information: >> >> host-triplet: $host >> shell: $SHELL >> compiler: $LTCC >>

Re: [SCM] GNU Libtool branch, master, updated. v2.4.5-5-gc60e054

On 2015-01-20 18:24, Gary V. Vaughan wrote: > -# Copyright (C) 2010-2015 Free Software Foundation, Inc. > +# Copyright (C) 2010-2014 Free Software Foundation, Inc. That's why I felt so young today! Cheers, Peter ___ https://lists.gnu.org/mailman/listin

Re: [RFC] any critical patches for a release this weekend?

On 2014-11-02 11:42, Gary V. Vaughan wrote: > [[Added back Cc: libtool-list]] > >> On Nov 1, 2014, at 11:11 AM, Richard PALO wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Le 27/10/14 23:02, Gary V. Vaughan a écrit : >> | Hi Richard, >> | >> |> I'd like to see two patches com

Re: Installing DLLs on Cygwin

On 2014-09-28 16:50, Mike Gran wrote: > >> My guess is that libguile-ncurses.la is a Libtool module. The move to ../bin >> does not happen for modules, if I remember correctly. > > > Thanks. Removing the -module from LDFLAGS fixed the install. > > I guess '-module' does not mean what I think

Re: Installing DLLs on Cygwin

On 2014-09-28 10:17, Marco Atzeri wrote: > On 28/09/2014 03:51, Mike Gran wrote: >> Hello Libtool, >> >> I was lead to believe that if I use libtool to install >> a dll created on Cygwin using automake with a lib_LTLIBRARIES >> rule, that libtool would install the dll in /usr/bin and the >> linker

Re: Installing DLLs on Cygwin

On 2014-09-28 03:51, Mike Gran wrote: > Hello Libtool, > > I was lead to believe that if I use libtool to install > a dll created on Cygwin using automake with a lib_LTLIBRARIES > rule, that libtool would install the dll in /usr/bin and the > linker and convenience libraries in /usr/lib. but I ca

Re: configure: WARNING: using cross tools not prefixed with host triplet

On 2014-09-18 10:06, R. Diez wrote: > > >>> [...] >> >>> Why is searching for on >> >>> platform when isn't available there? >>> >>> Because it's the autoconf way! It's not a bug. >>> [...] > > One more thing I just realised: that spurious warning renders the original > warning

Re: configure: WARNING: using cross tools not prefixed with host triplet

On 2014-09-17 16:48, R. Diez wrote: > Hi there: > > I am cross-compiling on a Linux PC host for an embedded ARM target, and I am > getting this warning: > > checking for arm-none-eabi-mt... no > checking for mt... mt > configure: WARNING: using cross tools not prefixed with host triplet >

Re: libtool: lib: command not found

On 2014-09-05 17:19, raz...@eml.cc wrote: > On Fri, Sep 05, 2014 at 05:05:52PM +0200, Peter Rosin wrote: >> On 2014-09-05 16:52, raz...@eml.cc wrote: >>> Hi Peter, thank you >>> >>> attacched the zzip config.log. >> >> Bleh, sorry, but could you a

Re: libtool: lib: command not found

On 2014-09-05 16:52, raz...@eml.cc wrote: > Hi Peter, thank you > > attacched the zzip config.log. Bleh, sorry, but could you also provide the output from ./libtool --config from your build directory? Cheers, Peter ___ https://lists.gnu.org

Re: libtool: lib: command not found

Hi! On 2014-09-05 13:28, raz...@eml.cc wrote: > I'm having some trouble cross building libraries from a Linux machine > (Debian/unstable) using mingw-w64, seem libtool is looking for a "lib" > command to generate a .lib library, but the command is missing and I > can't find it in any package (on s

Re: Libtool and ASAN

Hi! On 2014-04-28 17:45, Akim Demaille wrote: > I'm trying to use -fsanitize=address on OS X using MacPorts' Clang++ 3.5. > The project consists of C++ libraries, on top of which is built a Python > module (with a thin C++ layer which needs to be compiled). Libtool > (2.4.2 - the name of a fine b

Re: Passing flags with mode=link

On 2014-04-17 21:38, Evgeny Grin wrote: > Hi, > > I spend a few hours before I realized that libtool did not pass to linker > flags other than -L -l -Wl, and -Xlinker. It's totally confusing as in > compile mode libtool pass all flags to compiler. > Currently there are no way to pass flags like

[sr #108558] libtool nm test does not really work for W32 versions of nm

Update of sr #108558 (project libtool): Status:None => Done ___ Follow-up Comment #10: Patch pushed. Cheers, Peter ___ Rep

Re: [sr #108558] libtool nm test does not really work for W32 versions of nm

On 2014-05-06 15:30, Peter Rosin wrote: > Follow-up Comment #8, sr #108558 (project libtool): > > I have attached a patch that does the safe-safe-safe version. > Does it work for you? *snip* > <http://savannah.gnu.org/support/?108558> To not force everyone to follow

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #8, sr #108558 (project libtool): I have attached a patch that does the safe-safe-safe version. Does it work for you? Cheers, Peter (file #31318) ___ Additional Item Attachment: File name: 0001-libtool-fix-nm-test-for-MS

[sr #107959] Libtool generates invalid .def files

Update of sr #107959 (project libtool): Status:None => Done ___ Follow-up Comment #1: Fixed a while ago by commit a5a4944fbb2bbd20adb12b. Cheers, Peter ___

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #7, sr #108558 (project libtool): Ok, something like this seems safer: mkdir conftest.dir case `"$tmp_nm" -B conftest.dir/nofile` in *conftest.dir/nofile*) blablabla esac rm -rf conftest.dir But I don't know how non-GNU nm behaves, so the safe-safe-safe version only does the ab

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #5, sr #108558 (project libtool): Hmm, on second thought, that depends on MSYS (and MSYS2) still thinking that an argument starting with more than two slashes is a UNC path (or a switch). That might change if someone points out that ///foo and /foo should be equivalent and that P

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

Update of sr #108559 (project libtool): Status:None => Done ___ Follow-up Comment #3: I have now pushed this change, thanks for testing! Cheers, Peter

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

Follow-up Comment #1, sr #108559 (project libtool): Isn't this a more direct approach, not affected by new and even more aggressive optimizations? -volatile const char * MAGIC_EXE = "$magic_exe"; +#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 5) +# define externally_visible volatile +#el

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #3, sr #108558 (project libtool): > Well, in MSYS2 you can simply do: > nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble > and get satisfactory results (file name and 'No such file' > in the output). > Can't say anything about MSYS1, haven't used it for some time. Tha

[sr #108558] libtool nm test does not really work for W32 versions of nm

Follow-up Comment #1, sr #108558 (project libtool): Thanks for the report. Just a quick note, Cygwin is not affected. This happens on MSYS/MinGW only. On Cygwin, the Windows (or should I say DOS?) NUL device is never involved. cygwin$ /bin/nm -B /dev/null /bin/nm: Warning: '/dev/null' is not an

Re: -no-undefined on Win32

On 2014-04-29 17:30, Evgeny Grin wrote: > 29.04.2014, 11:36, "Peter Rosin": >>>> The situation you outlined is due to a defective package >>>> preparation/build environment. A proper build has just one version of >>>> a given library in a link

Re: -no-undefined on Win32

On 2014-04-29 07:25, Evgeny Grin wrote: > 29.04.2014, 05:59, "Bob Friesenhahn": >> On Mon, 28 Apr 2014, Evgeny Grin wrote: >>> Good. But requiring "-no-undefined" for Win32 flag lower probability of >>> successful compile. >> In what way does it lower the probability of a successful compile? >> S

Re: git commit forces bootstrap

On 2013-12-09 04:37, Gary V. Vaughan wrote: > On Dec 9, 2013, at 11:52 AM, Peter Rosin wrote: >> ok to push? > > Just to reiterate: I found the barrier for contributing to libtool had > become insanely high in years past, to the point where even I found it > hard to motiva

Re: git commit forces bootstrap

On 2013-12-07 08:53, Gary V. Vaughan wrote: > On 6 Dec 2013, at 21:11, Peter Rosin wrote: >> In my setup, I have to rerun "./bootstrap -fc" after every commit I make >> to my local git libtool repo, which is very annoying. I >> >> inline-source: error:

Re: g++ and -nostdlib

[dropping libtool-patches@] On 2013-11-12 12:24, Peter Rosin wrote: > [re-adding libtool@] > > On 2013-11-11 16:10, Bob Friesenhahn wrote: >> On Mon, 11 Nov 2013, Peter Rosin wrote: >>>>> >>>>> Quite a lot of effort went into making this work the wa

git commit forces bootstrap

Hi! In my setup, I have to rerun "./bootstrap -fc" after every commit I make to my local git libtool repo, which is very annoying. If I forget, and simply type make, configure runs (I can live with that), but after that I get this output: config.status: executing depfiles commands config.status:

Re: bootstrap breakage starting with fec7d87

On 2013-11-20 00:32, Gary V. Vaughan wrote: > Hi Ozkan, Petor, > > On Nov 19, 2013, at 11:57 PM, Peter Rosin wrote: > >> On 2013-11-19 10:08, Ozkan Sezer wrote: >>>> Starting with fec7d87 ("funclib.sh: simplify version comparison >>>> functions&qu

Re: bootstrap breakage starting with fec7d87

e. I came up with this patch, but I don't know how portable it is, so I would like someone knowledgeable to comment on it before pushing it... Cheers, Peter >From a7462c5563e124e06f4f61ce2a9cea26cf8be390 Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Tue, 19 Nov 2013 11:54:27 +0100 Sub

Re: g++ and -nostdlib

[re-adding libtool@] On 2013-11-11 16:10, Bob Friesenhahn wrote: > On Mon, 11 Nov 2013, Peter Rosin wrote: >>>> >>>> Quite a lot of effort went into making this work the way it currently does. >> >> I realize that, but if it really works or not is a differe

g++ and -nostdlib

incompatible change? Or simply a bug fix? BTW, it even appears to work, but please test, as I have only done very light testing... Oh well. Any thoughts? Cheers, Peter >From a233b4562d4274053852bc0353e36931beeb4803 Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Fri, 8 Nov 2013 19:01:2

Re: Using libtool via autotools causes linking problem on mingw

On 2013-11-08 14:15, Peter Rosin wrote: > On 2013-11-08 12:18, Panicz Maciej Godek wrote: >> 2013/11/8 Peter Rosin mailto:p...@lysator.liu.se>> >> >> The SDL library, for some obscure reason, has its own special take on >> that and >> prescribes th

Re: Using libtool via autotools causes linking problem on mingw

On 2013-11-08 12:18, Panicz Maciej Godek wrote: > 2013/11/8 Peter Rosin mailto:p...@lysator.liu.se>> > > The SDL library, for some obscure reason, has its own special take on > that and > prescribes that you should keep using main() even if you are doing a GUI >

Re: Using libtool via autotools causes linking problem on mingw

On 2013-11-08 11:31, Václav Zeman wrote: > On 7 November 2013 22:00, Panicz Maciej Godek > wrote: > > Hi, > For some time I've been trying to compile my framework > for writing multimedia and 3d games in Guile Scheme > on Windows/MinGW. > The fra

Re: Using libtool via autotools causes linking problem on mingw

On 2013-11-07 23:39, Panicz Maciej Godek wrote: > Hi, > I did apply that change, i.e. replaced AM_LDFLAGS with slayer_LDADD and moved > the definition to the end of the src/Makefile.am. The libtool is right now > invoked this way: > /bin/sh ../libtool --tag=CXX --mode=link g++ -D_GNU_SOURCE=1

Re: Using libtool via autotools causes linking problem on mingw

On 2013-11-07 22:00, Panicz Maciej Godek wrote: > Hi, > For some time I've been trying to compile my framework > for writing multimedia and 3d games in Guile Scheme > on Windows/MinGW. > The framework uses SDL library, and more details can be > found here: https://puszcza.gnu.org.ua/projects/slayer

Re: Interface range compatibility?

On 2013-10-02 17:30, Phillip Susi wrote: > If I build rev 0 of a library, link to it, then rebuild the library > with interface 1, age 1, that should mean it is compatible with > interface 0 or 1. It creates libfoo.so.0.1.0 so an app linked against > interface 0 will find it. Now if I rebuild the

Re: libtool woes

On 2013-09-17 10:23, Peter Rosin wrote: > On 2013-09-17 09:50, Ozkan Sezer wrote: >> Any chance that this patch, or a patch that fixes bug #15321 [1], >> gets applied any time? > > Yes, I'll push it in a bit. Pushed. Cheers, Peter ___

Re: libtool woes

On 2013-09-17 09:50, Ozkan Sezer wrote: > Any chance that this patch, or a patch that fixes bug #15321 [1], > gets applied any time? Yes, I'll push it in a bit. It's been almost a week, and I suspect that noone will take the time to review this, so I'm just going to push it shortly without review.

Re: libtool woes

On 2013-09-10 16:10, Peter Rosin wrote: > On 2013-09-10 15:56, Ozkan Sezer wrote: >> OK then, I'll keep an eye on mails from this list. >> >> (On an irrelevant note, the archive pages at >> http://lists.gnu.org/archive/html/libtool/2013-09/index.html >>

Re: libtool woes

On 2013-09-10 15:56, Ozkan Sezer wrote: > OK then, I'll keep an eye on mails from this list. > > (On an irrelevant note, the archive pages at > http://lists.gnu.org/archive/html/libtool/2013-09/index.html > http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html > doesn't list any mails f

Re: libtool woes

On 2013-09-10 15:29, Ozkan Sezer wrote: > On 9/10/13, Peter Rosin wrote: >> On 2013-09-10 15:00, Ozkan Sezer wrote: >>> On 9/10/13, Peter Rosin wrote: >>>> On 2013-09-10 12:52, Ozkan Sezer wrote: >>>>> That effectively cripples libtool for cross

Re: libtool woes

On 2013-09-10 15:00, Ozkan Sezer wrote: > On 9/10/13, Peter Rosin wrote: >> On 2013-09-10 12:52, Ozkan Sezer wrote: >>> That effectively cripples libtool for cross-compilers. Can the behavior >>> be refined instead? Can you contact Charles Wilson about this? >>

Re: libtool woes

On 2013-09-10 12:52, Ozkan Sezer wrote: > That effectively cripples libtool for cross-compilers. Can the behavior > be refined instead? Can you contact Charles Wilson about this? He should be reading this list, if he has time... Anyway, does this work? Cheers, Peter diff --git a/m4/libtool.m4

Re: libtool woes

On 2013-09-10 12:25, Ozkan Sezer wrote: > On 9/10/13, Ozkan Sezer wrote: >> On 9/10/13, Peter Rosin wrote: >>> On 2013-09-10 11:26, Ozkan Sezer wrote: >>>> On 9/10/13, Peter Rosin wrote: >>>>> On 2013-09-10 10:55, Ozkan Sezer wrote: >>>>

Re: libtool woes

On 2013-09-10 11:50, Ozkan Sezer wrote: > On 9/10/13, Peter Rosin wrote: >> On 2013-09-10 11:26, Ozkan Sezer wrote: >>> On 9/10/13, Peter Rosin wrote: >>>> On 2013-09-10 10:55, Ozkan Sezer wrote: >>>>> On 9/10/13, Peter Rosin wrote: >>>>&

Re: libtool woes

On 2013-09-10 11:26, Ozkan Sezer wrote: > On 9/10/13, Peter Rosin wrote: >> On 2013-09-10 10:55, Ozkan Sezer wrote: >>> On 9/10/13, Peter Rosin wrote: >>>> On 2013-09-10 09:47, Ozkan Sezer wrote: >>>>> On 9/10/13, Peter Rosin wrote: >>>>&

Re: libtool woes

On 2013-09-10 10:55, Ozkan Sezer wrote: > On 9/10/13, Peter Rosin wrote: >> On 2013-09-10 09:47, Ozkan Sezer wrote: >>> On 9/10/13, Peter Rosin wrote: >>>> On 2013-09-10 09:08, Ozkan Sezer wrote: >>>>> Tell me if you need anything else. >>&

Re: libtool woes

On 2013-09-10 09:47, Ozkan Sezer wrote: > On 9/10/13, Peter Rosin wrote: >> On 2013-09-10 09:08, Ozkan Sezer wrote: >>> Tell me if you need anything else. >> >> Let's focus on the libtool 2.4.2.393-5d4a if that's ok with >> you. >> >&

Re: libtool woes

On 2013-09-10 09:08, Ozkan Sezer wrote: > Tell me if you need anything else. Let's focus on the libtool 2.4.2.393-5d4a if that's ok with you. Can you provide the output from "libtool --config" and config.log? I'm not set up to easily duplicate your environment... Cheers, Peter

Re: libtool woes

On 2013-09-10 00:34, JonY wrote: > On 9/10/2013 02:12, Ozkan Sezer wrote: >> >> *** Warning: linker path does not have real file for library -lole32. >> *** I have the capability to make that library automatically link in when >> *** you link to this library. But I can only do this if you have a >

Re: Two-month patch ping: Re: powerpc*le-linux support

On 2013-08-22 17:48, Alan Modra wrote: > On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote: >>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is >>> explicitly 64-bit? That seems like utter garbage to me. What am I >>> missing this time? > > As far as I underst

Re: Two-month patch ping: Re: powerpc*le-linux support

On 2013-08-22 10:20, Gary V. Vaughan wrote: > Hi Peter, > > On Aug 22, 2013, at 2:54 PM, Peter Rosin wrote: > >> On 2013-08-22 09:40, Gary V. Vaughan wrote: >>>> Can we please get this simple patch pushed? >>> >>> Done. >> >> To me

Re: Two-month patch ping: Re: powerpc*le-linux support

On 2013-08-22 09:40, Gary V. Vaughan wrote: >> Can we please get this simple patch pushed? > > Done. To me, it appears as if what you actually pushed was not what was posted? Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: bfd and cygpath

On 2013-04-26 23:48, Peter Rosin wrote: > On 2013-04-26 18:51, NightStrike wrote: >> On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin wrote: >>> You had LD=i686-w64-mingw32-gcc, which will not make libtool happy. You >>> might try LD=i686-w64-mingw32-ld instead, but you sh

Re: bfd and cygpath

On 2013-04-26 18:51, NightStrike wrote: > On Fri, Apr 26, 2013 at 4:06 AM, Peter Rosin wrote: >> On 2013-04-26 13:58, NightStrike wrote: >>> On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin wrote: >>>> On 2013-04-24 22:24, NightStrike wrote: >>>>>

Re: bfd and cygpath

On 2013-04-26 13:58, NightStrike wrote: > On Wed, Apr 24, 2013 at 8:52 PM, Peter Rosin wrote: >> On 2013-04-24 22:24, NightStrike wrote: >>> On Wed, Apr 24, 2013 at 4:16 PM, NightStrike wrote: >>>> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin wrote: >>>>

Re: bfd and cygpath

On 2013-04-24 22:24, NightStrike wrote: > On Wed, Apr 24, 2013 at 4:16 PM, NightStrike wrote: >> On Wed, Apr 24, 2013 at 4:01 PM, Peter Rosin wrote: >>> So, it appears that LT_PATH_LD does not like your ld? I'd look into >>> that. >> >> Where is the a

Re: bfd and cygpath

On 2013-04-24 18:29, NightStrike wrote: > On Wed, Apr 24, 2013 at 12:17 PM, NightStrike wrote: >> On Wed, Apr 24, 2013 at 11:55 AM, NightStrike wrote: >>> On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin wrote: >>>> On 2013-04-23 16:12, NightStrike wrote: >>

Re: bfd and cygpath

On 2013-04-23 16:12, NightStrike wrote: > On Tue, Apr 23, 2013 at 4:02 AM, NightStrike wrote: >> Building bfd in a particular cross compiler scenario requires that >> cygpath be set to "echo". bfd configury has the tools to do this, but >> it's broken. Configure properly does this: >> >> # test

Re: [PATCH] doc: fix an orthographic error

On 2013-01-28 17:33, Jan Engelhardt wrote: > On Monday 2013-01-28 17:18, Peter Rosin wrote: >> On 2013-01-28 14:07, Jan Engelhardt wrote: >>> @@ -1696,7 +1696,7 @@ not >>> libdir='/tmp/usr/local/lib' >>> @end example >>> >>>

Re: [PATCH] doc: fix an orthographic error

On 2013-01-28 14:07, Jan Engelhardt wrote: > --- > doc/libtool.texi |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/libtool.texi b/doc/libtool.texi > index f7787f6..c06ddaa 100644 > --- a/doc/libtool.texi > +++ b/doc/libtool.texi > @@ -1696,7 +1696,7 @@ not > libd

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-345-ge54f2dc

On 2013-01-18 17:32, Peter Rosin wrote: > On 2013-01-01 19:03, Gary V. Vaughan wrote: >> maint: remove unsupported Tested-by: tag. >> >> * build-aux/git-log-fix: Tested-by: line should not appear in the >> ChangeLog. >> >> Signe

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-345-ge54f2dc

On 2013-01-01 19:03, Gary V. Vaughan wrote: > maint: remove unsupported Tested-by: tag. > > * build-aux/git-log-fix: Tested-by: line should not appear in the > ChangeLog. > > Signed-off-by: Gary V. Vaughan Hi Gary, I just noticed this, and while I'm perfectly fine with

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #26, sr #108201 (project libtool): I have pushed the code changes to m4/Libtool.m4 (as two separate commits), but left the testsuite alone. Thank you for your work on this! I also added you to THANKS, I hope that was ok? A libtool release is not on my table though. Cheers, Pet

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #24, sr #108201 (project libtool): Hi again! I have no quarel with the original change to augment archive_expsym_cmds with ${wl}-h $wl$soname. That looks like a no-brainer as it just matches archive_cmds. That can go in at any time, as far as I'm concerned. The testsuite change

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #22, sr #108201 (project libtool): I had a look in the code and it is only for Solaris that old_archive_cmds and archive_cmds are rigged to include $LDFLAGS. This is clearly a buggy thing to do and it explains why -no-undefined is passed down to gcc for you. However, I have litt

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #18, sr #108201 (project libtool): I believe gcc 4.5.3 is the latest stable for Cygwin. I do not trust myself to be able to build a new gcc and verify that it actually works for Cygwin without investing far more time than I think is warranted. I imagine that there is some good re

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #16, sr #108201 (project libtool): I had an old git checkout from some time back (with some totally unrelated work in it) and I used that to run the export test. I'm not wasting hours on a full testsuite runs for this. I tested once configuring with CC=g++ and once with CC=gcc. B

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #14, sr #108201 (project libtool): Regarding the -no-undefined issue, I believe it is correct to set -no-undefined in LDFLAGS in export.at. This is the case since libtool is used to link in that test, and nothing else. Or is LDFLAGS special in some way on Solaris, so that it get

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #10, sr #108201 (project libtool): Dropping -no-undefined from LDFLAGS in export.at kills the test on Windows and it's unacceptable to assume that elfdump exists. Passing -no-undefined to libtool is NOT a misnomer and -no-undefined is in fact a perfectly valid libtool option, not

Re: libtool 2.4.2 fails to compile on Solaris 10

On 2012-11-16 21:02, Dennis Clarke wrote: > So I guess we have progress here .. sort of. Good! > $ pwd > /usr/local/build/libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9 > $ cp -p ./test-suite.log > libtool-2.4.2_Nov_06_0153_SunOS5.10_sparcv9_test-suite.log > > see attached testsuite log file. I

Re: libtool 2.4.2 fails to compile on Solaris 10

On 2012-11-06 12:45, Peter Rosin wrote: > The lt_libltdl_LTX_preloaded_symbols symbol is supposed to be in an > automatically > generated file, which isn't generated because configure does not recognize the > $NM output. Libtool wants BSD style output. > > > &

Re: libtool 2.4.2 fails to compile on Solaris 10

Hi Dennis! On 2012-11-06 04:08, Dennis Clarke wrote: > > Firstly, I am willingto look at a git clone but I would prefer to work with a > version that is considered "stable" and "released" and not alpha or beta > grade. However, having said that : > > $ uname -a > SunOS node002 5.10 Generic_1

Re: [RFC] Moving ltmain.sh and libtool.m4 into Automake

Hi Gary! [dropping Automake@, since that part seems to have been shot down] On 2012-10-17 11:41, Gary V. Vaughan wrote: > Autotoolers, > > For quite some time now I've been thinking about simplifying Libtool, > but I'm interested in feedback and more particularly buy-in from > Automake maintaine

Re: func_win32_import_lib_p when file is missing

On 2012-10-07 14:48, Gary V. Vaughan wrote: > Hi Peter, > > On Oct 7, 2012, at 4:37 PM, Peter Rosin wrote: >> On 2012-10-07 06:04, Gary V. Vaughan wrote: >>> On 7 Oct 2012, at 06:53, Peter Rosin wrote: >>>> objdump doesn't output "import"

Re: func_win32_import_lib_p when file is missing

On 2012-10-07 06:04, Gary V. Vaughan wrote: > Hi Peter, > > On 7 Oct 2012, at 06:53, Peter Rosin wrote: >> How is the below function supposed to work >> when $file_magic_cmd is '$OBJDUMP -f' and not 'func_win32_libid'? > > I have no idea :( > &

func_win32_import_lib_p when file is missing

Hi! After getting rid of the legacy testsuite (nice!), I'm seeing a new failure with MSYS/MSVC in what used to be the demo group, now demo.at. I think it's a real libtool bug this time, and not a simple testsuite issue. When I do the MSVC run, I also specify that I want to use "dumpbin -symbols"

Re: cannot build from git/no daily snapshots

On 2012-09-18 23:50, Peter Rosin wrote: > On 2012-09-18 21:21, Peter Rosin wrote: >> On 2012-09-18 16:44, Gary V. Vaughan wrote: >>> Hi Bob, >>> >>> On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn >>> wrote: >>>> It used to be possible to run

Re: cannot build from git/no daily snapshots

On 2012-09-18 21:21, Peter Rosin wrote: > On 2012-09-18 16:44, Gary V. Vaughan wrote: >> Hi Bob, >> >> On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn >> wrote: >>> It used to be possible to run the libtool test suite in a MSYS shell >>> using a CIFS mo

Re: cannot build from git/no daily snapshots

On 2012-09-18 16:44, Gary V. Vaughan wrote: > Hi Bob, > > On 18 ก.ย. 2012, at 21:23, Bob Friesenhahn > wrote: >> It used to be possible to run the libtool test suite in a MSYS shell >> using a CIFS mount of the same source tree that I use for my Unix type >> systems. I used to do that on a peri

Re: cannot build from git/no daily snapshots

On 2012-09-18 03:33, Gary V. Vaughan wrote: > Hi Bob, Peter, > > On 17 ก.ย. 2012, at 23:22, Bob Friesenhahn > wrote: >> On Mon, 17 Sep 2012, Peter Rosin wrote: >>>> >>>> The 'm4' on this MinGW install is not a blessed version and a simple

Re: cannot build from git/no daily snapshots

On 2012-09-17 16:02, Bob Friesenhahn wrote: > On Mon, 17 Sep 2012, Gary V. Vaughan wrote: > >> Hi Bob, >> >> On 17 ก.ย. 2012, at 2:48, Bob Friesenhahn >> wrote: > >>> Please make it so that it is possible to use a source tree which has a .hg >>> directory >>> even if there is no 'git' program

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

On 2012-07-22 04:00, JonY wrote: > On 7/22/2012 00:43, Peter Rosin wrote: >> On 2012-07-21 14:49, Vincent Torri wrote: >>> On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin wrote: >>>> On 2012-07-21 13:16, Vincent Torri wrote: >>>>> absolutely NO reason t

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

On 2012-07-21 14:49, Vincent Torri wrote: > On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin wrote: >> On 2012-07-21 13:16, Vincent Torri wrote: >>> another solution is to just kill the stupid .la file. There is >> >> I don't think the .la file is stupid as it li

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

On 2012-07-21 13:16, Vincent Torri wrote: > another solution is to just kill the stupid .la file. There is I don't think the .la file is stupid as it lists other important dependencies. > absolutely NO reason to add to the linker static libraries that are > ONLY used in my Evil library and that a

Re: mingw-w64's libuuid.a : *** Warning: linker path does not have real file for library -luuid.

On 2012-07-20 17:49, Vincent Torri wrote: > hey > > I'm using mingw-w64 gcc (4.8.0 experimental) > > I have to link a library (named Evil) against libuuid.a. That is, in > Makefile.am : > > libevil_la_LIBADD = -luuid etc.. > > I have the warning that I pasted in the topic: > > ** Warning:

  1   2   >