Re: libtool woes
On 9/10/13, JonY <10wa...@gmail.com> 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 >> *** shared version of the library, which you do not appear to have >> *** because I did check the linker path looking for a file starting >> *** with libole32 but no candidates were found. (...for file magic test) >> >> *** Warning: linker path does not have real file for library -ldsound. >> *** 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 >> *** shared version of the library, which you do not appear to have >> *** because I did check the linker path looking for a file starting >> *** with libdsound but no candidates were found. (...for file magic test) >> >> *** Warning: linker path does not have real file for library -lwinmm. >> *** 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 >> *** shared version of the library, which you do not appear to have >> *** because I did check the linker path looking for a file starting >> *** with libwinmm but no candidates were found. (...for file magic test) >> *** The inter-library dependencies that have been dropped here will be >> *** automatically added whenever a program is linked with this library >> *** or is declared to -dlopen it. >> >> I am stuck with this. Can anyone see what I am doing wrong? >> > > This needs to be taken up with the libtool developers. > > libtool is technically correct, but libole32.a is a mixed shared lib > with static data inserted. The thing is, libole32.a is _not_ mixed: it is generated only from ole32.def. My first thought was like yours when I first hit the issue with libws2_32.a, which _is_ mixed, but then saw it with others which are let's say _pure_ > > libtool should use dlltool --identify when available. > ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
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?
>
> He should be reading this list, if he has time...
>
> Anyway, does this work?
>
No, it does not. With this patch applied, I see
sys_lib_search_path_spec="/opt/W64_180676/lib/gcc "
.. in the libtool --config output.
(Note that, this is not a multilib compiler: it targets only win64.)
> Cheers,
> Peter
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index 4418a1c..59953d1 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -2246,23 +2246,38 @@ if test yes = "$GCC"; then
>done
>lt_search_path_spec=`$ECHO "$lt_tmp_lt_search_path_spec" | awk '
> BEGIN {RS = " "; FS = "/|\n";} {
> - lt_foo = "";
> - lt_count = 0;
> + lt_canon_foo = "";
> + lt_canon_count = 0;
> + lt_multi_foo = "";
> + lt_multi_count = 0;
> + lt_multi = 1;
>for (lt_i = NF; lt_i > 0; lt_i--) {
> -if ($lt_i != "" && $lt_i != ".") {
> +if ($lt_i == ";") {
> + lt_multi = 0;
> + continue;
> +}
> +if ($lt_i == "" || $lt_i == ".") continue;
> +if (!lt_multi) {
>if ($lt_i == "..") {
> -lt_count++;
> +lt_canon_count++;
> + } else if (lt_canon_count == 0) {
> +lt_canon_foo = "/" $lt_i lt_canon_foo;
>} else {
> -if (lt_count == 0) {
> - lt_foo = "/" $lt_i lt_foo;
> -} else {
> - lt_count--;
> -}
> +lt_canon_count--;
>}
> }
> +if ($lt_i == "..") {
> + lt_multi_count++;
> +} else if (lt_multi_count == 0) {
> + lt_multi_foo = "/" $lt_i lt_multi_foo;
> +} else {
> + lt_multi_count--;
> +}
>}
> - if (lt_foo != "") { lt_freq[[lt_foo]]++; }
> - if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
> + if (lt_canon_foo != "") { lt_canon_freq[lt_canon_foo]++; }
> + if (lt_canon_freq[lt_multi_foo]) { lt_multi_foo = lt_canon_foo; }
> + if (lt_multi_foo != "") { lt_multi_freq[lt_multi_foo]++; }
> + if (lt_multi_freq[lt_multi_foo] == 1) { print lt_multi_foo; }
> }'`
># AWK program above erroneously prepends '/' to C:/dos/paths
># for these hosts.
>
--
O.S.
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
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. >>> >>> 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 >>> >>> >> >> Attached ./libtool --config output after configuration. Attached >> config.log. > > Your error messages indicate that libtool cannot find any files > matching the various things associated with -lole32 (and other > w32 libraries). I.e. it's not that the any files found are not > considered good enough, it's that libtool doesn't find them > at all. So, the dlltool --identify code path is in all likelihood > perfectly fine, it's just that nothing is being fed to dlltool > in the first place. > > So, something seems to be fishy with your library search path. > I notice this in your libtool --config: > > # Compile-time system search path for libraries. > sys_lib_search_path_spec="/opt/W64_180676/lib/gcc > /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 " > > Do you have any libole32.a (or something such) in any of those > places? If not, where are they? (and why didn't libtool pick > that up when it did $host-gcc --print-search-dirs?) > You are on the right track, and I think my new msg hasn't arrived yet. See the attached new file libtool--config-1.5.out which is the output if I use libtool-1.5, and yes the the important difference is sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is: sys_lib_search_path_spec="/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 " With 1.5, it is: sys_lib_search_path_spec=" /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/ /opt/W64_180676/bin/../lib/gcc/ /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/ /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/ /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/ /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/ /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/ /opt/W64_180676/bin/../../cross_win64/mingw/lib/" The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and using /x86_64-w64-mingw32/lib64 instead for reasons unfathomable to me. /x86_64-w64-mingw32/lib64 does exist, but it only holds gcc's libs, and as a result, the necessary libs aren't found. -- O.S. libtool--config-1.5.out Description: Binary data ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
On 9/10/13, Peter Rosin wrote: > 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 >>> *** shared version of the library, which you do not appear to have >>> *** because I did check the linker path looking for a file starting >>> *** with libole32 but no candidates were found. (...for file magic test) >>> >>> *** Warning: linker path does not have real file for library -ldsound. >>> *** 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 >>> *** shared version of the library, which you do not appear to have >>> *** because I did check the linker path looking for a file starting >>> *** with libdsound but no candidates were found. (...for file magic >>> test) >>> >>> *** Warning: linker path does not have real file for library -lwinmm. >>> *** 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 >>> *** shared version of the library, which you do not appear to have >>> *** because I did check the linker path looking for a file starting >>> *** with libwinmm but no candidates were found. (...for file magic test) >>> *** The inter-library dependencies that have been dropped here will be >>> *** automatically added whenever a program is linked with this library >>> *** or is declared to -dlopen it. >>> >>> I am stuck with this. Can anyone see what I am doing wrong? >>> >> >> This needs to be taken up with the libtool developers. >> >> libtool is technically correct, but libole32.a is a mixed shared lib >> with static data inserted. >> >> libtool should use dlltool --identify when available. > > Just to clarify, sufficiently new libtools (since 2.4) do in fact make > use of dlltool --identify when available, and I do not have any problem > handling -lole32 -ldsound -lwinmm when I try. We need more context to > help. > > Wild guess, could it be a missing -L /lib/w32api at play? The line just before it reports its failure is like this: libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I./include -I./include -DMIKMOD_BUILD=1 -g -O2 -finline-functions -funroll-loops -ffast-math -Wall -MT playercode/virtch_common.lo -MD -MP -MF playercode/.deps/virtch_common.Tpo -c playercode/virtch_common.c -o playercode/virtch_common.o >/dev/null 2>&1 /bin/sh ./libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -DMIKMOD_BUILD=1 -g -O2 -finline-functions -funroll-loops -ffast-math -Wall -no-undefined -version-info 4:0:1 -o libmikmod.la -rpath /usr/local/lib drivers/drv_AF.lo drivers/drv_aiff.lo drivers/drv_aix.lo drivers/drv_alsa.lo [many other *.lo] -ldsound -lwinmm -lm This is using a cross-toolchain on linux, /opt/cross_win64/bin is first in the $PATH, /opt/cross_win64/x86_64-w64-mingw32/lib does have lib*.a required, and if I compile using a lite Makefile without using libtool then all links fine. Background on the issue is like the following. The project in question is here: http://sourceforge.net/u/sezero/mikmod/ci/default/tree/ $ hg clone http://hg.code.sf.net/u/sezero/mikmod u-sezero-mikmod $ cd u-sezero-mikmod/libmikmod $ libtoolize -c && autoreconf -i $ (then run the attached lt_patch.sh if using libtool-1.5) $ export PATH=/opt/cross_win64/bin:$PATH $ ./configure --host=x86_64-w64-mingw32 $ make The mingw-w64 toolchain is one of my old, using gcc-4.5 and our stable-1.x branch (to be precise, this is the toolchain: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_2001/ using mingw-w64-bin_i686-linux_2001_sezero.tar.gz plus the update-rev.5747.zip thing.) Libtool is requested from configure.ac: - for libtool-1.5 AC_LIBTOOL_WIN32_DLL AC_PROG_LIBTOOL - for libtool-2.2.x and 2.4[.2] : either the sameas above, or simply LT_INIT([win32-dll]) With libtool-1.5.x (1.5.26 to be precise) there are no problems, I can create a dll (I have to use the attached lt_patch.sh to make it work, but then all are good.) With libtool-2.2.8, 2.2.10, 2.4, 2.4.2 and 2.4.2.393-5d4a (git), I hit the failure and it gives me only a static library. Tell me if you need anything else. > > Cheers, > Peter > > -- O.S. lt_patch.sh Description: Bourne shell script ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
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: >>>>> 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 >>>>> >>>>> >>>> >>>> Attached ./libtool --config output after configuration. Attached >>>> config.log. >>> >>> Your error messages indicate that libtool cannot find any files >>> matching the various things associated with -lole32 (and other >>> w32 libraries). I.e. it's not that the any files found are not >>> considered good enough, it's that libtool doesn't find them >>> at all. So, the dlltool --identify code path is in all likelihood >>> perfectly fine, it's just that nothing is being fed to dlltool >>> in the first place. >>> >>> So, something seems to be fishy with your library search path. >>> I notice this in your libtool --config: >>> >>> # Compile-time system search path for libraries. >>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc >>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 " >>> >>> Do you have any libole32.a (or something such) in any of those >>> places? If not, where are they? (and why didn't libtool pick >>> that up when it did $host-gcc --print-search-dirs?) >>> >> >> You are on the right track, and I think my new msg hasn't arrived yet. > > The messages crossed each other, yes. :-) > >> See the attached new file libtool--config-1.5.out which is the output >> if I use libtool-1.5, and yes the the important difference is >> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is: >> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc >> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 >> " >> >> With 1.5, it is: >> sys_lib_search_path_spec=" >> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/ >> /opt/W64_180676/bin/../lib/gcc/ >> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/ >> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/ >> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/ >> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/ >> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/ >> /opt/W64_180676/bin/../../cross_win64/mingw/lib/" >> >> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib >> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and >> using /x86_64-w64-mingw32/lib64 instead for reasons >> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist, >> but it only holds gcc's libs, and as a result, the necessary libs >> aren't found. > > So, what output do you get from > > x86_64-w64-mingw32-gcc --print-search-dirs > > I get: > > $ x86_64-w64-mingw32-gcc --print-search-dirs > install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/ > programs: > =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/ > libraries: > =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/../lib64/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/4.5.3/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib64/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/ > > Mine says: $ x86_64-w64-mingw32-gcc --print-search-dirs install: /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/ programs: =/opt/W64_180676/bin/../libexec/
Re: libtool woes
On 9/10/13, 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. >> >> Can you provide the output from "libtool --config" and >> config.log? I'm not set up to easily duplicate your >> environment... >> >> Cheers, >> Peter >> >> > > Attached ./libtool --config output after configuration. Attached > config.log. OK, actually libtool --config output does give a clue. Attached new file libtool--config-1.5.out which is the output if I use libtool-1.5 The important difference, I think, is sys_lib_search_path_spec With 2.4.2.393-5d4a, it is: sys_lib_search_path_spec="/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 " With 1.5, it is: sys_lib_search_path_spec=" /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/ /opt/W64_180676/bin/../lib/gcc/ /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/ /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/ /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/ /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/ /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/ /opt/W64_180676/bin/../../cross_win64/mingw/lib/" The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib but 2.4 is doing it and using lib64 instead for reasons unfathomable to me. -- O.S. libtool--config-1.5.out Description: Binary data ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
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: >>>>> 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. >>>>>>> >>>>>>> Can you provide the output from "libtool --config" and >>>>>>> config.log? I'm not set up to easily duplicate your >>>>>>> environment... >>>>>>> >>>>>>> Cheers, >>>>>>> Peter >>>>>>> >>>>>>> >>>>>> >>>>>> Attached ./libtool --config output after configuration. Attached >>>>>> config.log. >>>>> >>>>> Your error messages indicate that libtool cannot find any files >>>>> matching the various things associated with -lole32 (and other >>>>> w32 libraries). I.e. it's not that the any files found are not >>>>> considered good enough, it's that libtool doesn't find them >>>>> at all. So, the dlltool --identify code path is in all likelihood >>>>> perfectly fine, it's just that nothing is being fed to dlltool >>>>> in the first place. >>>>> >>>>> So, something seems to be fishy with your library search path. >>>>> I notice this in your libtool --config: >>>>> >>>>> # Compile-time system search path for libraries. >>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc >>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 >>>>> " >>>>> >>>>> Do you have any libole32.a (or something such) in any of those >>>>> places? If not, where are they? (and why didn't libtool pick >>>>> that up when it did $host-gcc --print-search-dirs?) >>>>> >>>> >>>> You are on the right track, and I think my new msg hasn't arrived yet. >>> >>> The messages crossed each other, yes. :-) >>> >>>> See the attached new file libtool--config-1.5.out which is the output >>>> if I use libtool-1.5, and yes the the important difference is >>>> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is: >>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc >>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 >>>> " >>>> >>>> With 1.5, it is: >>>> sys_lib_search_path_spec=" >>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/ >>>> /opt/W64_180676/bin/../lib/gcc/ >>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/ >>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/ >>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/ >>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/ >>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/ >>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/" >>>> >>>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib >>>> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and >>>> using /x86_64-w64-mingw32/lib64 instead for reasons >>>> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist, >>>> but it only holds gcc's libs, and as a result, the necessary libs >>>> aren't found. >>> >>> So, what output do you get from >>> >>> x86_64-w64-mingw32-gcc --print-search-dirs >>> >>> I get: >>> >>> $ x86_64-w64-mingw32-gcc --print-search-dirs >>> install: /usr/lib/gcc/x86_64-w64-mingw32/4.5.3/ >>> programs: >>> =/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/:/usr/lib/gcc/x86_64-w64-mingw32/:/usr/lib/gcc/x86_64-w64-mingw32/4.5.3/../../../../x86_64-w64-mingw32/bin/x86
Re: libtool woes
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-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? >>> >> >> No, it does not. With this patch applied, I see >> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc " >> .. in the libtool --config output. > > Crap, I didn't do any final test and managed to exclude a couple > of critical changes, and I did a couple of silly mistakes too. Sorry > about that. Attached is what I should have sent the first time... > Thanks, this one makes it to work. ./libtool --config output now has: sys_lib_search_path_spec="/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 /opt/W64_180676/x86_64-w64-mingw32/lib /opt/cross_win64/mingw/lib " which is suitable. >> (Note that, this is not a multilib compiler: it targets only win64.) > > Even so, I believe that it outputs ../lib64 when you > -print-multi-os-directory, right? > Well yeah, it does :) Is it hard to implement a way of directly respecting --print-search-dirs output of the compiler though? -- O.S. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
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: >>>>> 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. >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Attached ./libtool --config output after configuration. Attached >>>>>>> config.log. >>>>>> >>>>>> Your error messages indicate that libtool cannot find any files >>>>>> matching the various things associated with -lole32 (and other >>>>>> w32 libraries). I.e. it's not that the any files found are not >>>>>> considered good enough, it's that libtool doesn't find them >>>>>> at all. So, the dlltool --identify code path is in all likelihood >>>>>> perfectly fine, it's just that nothing is being fed to dlltool >>>>>> in the first place. >>>>>> >>>>>> So, something seems to be fishy with your library search path. >>>>>> I notice this in your libtool --config: >>>>>> >>>>>> # Compile-time system search path for libraries. >>>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc >>>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 >>>>>> " >>>>>> >>>>>> Do you have any libole32.a (or something such) in any of those >>>>>> places? If not, where are they? (and why didn't libtool pick >>>>>> that up when it did $host-gcc --print-search-dirs?) >>>>>> >>>>> >>>>> You are on the right track, and I think my new msg hasn't arrived yet. >>>> >>>> The messages crossed each other, yes. :-) >>>> >>>>> See the attached new file libtool--config-1.5.out which is the output >>>>> if I use libtool-1.5, and yes the the important difference is >>>>> sys_lib_search_path_spec. With 2.4.2.393-5d4a, it is: >>>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc >>>>> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 >>>>> " >>>>> >>>>> With 1.5, it is: >>>>> sys_lib_search_path_spec=" >>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/ >>>>> /opt/W64_180676/bin/../lib/gcc/ >>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/4.5.4/ >>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/../lib64/ >>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/x86_64-w64-mingw32/4.5.4/ >>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/../lib64/ >>>>> /opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/ >>>>> /opt/W64_180676/bin/../../cross_win64/mingw/lib/" >>>>> >>>>> The correct path should be /opt/W64_180676/x86_64-w64-mingw32/lib >>>>> i.e. /x86_64-w64-mingw32/lib, but 2.4 is not doing it and >>>>> using /x86_64-w64-mingw32/lib64 instead for reasons >>>>> unfathomable to me. /x86_64-w64-mingw32/lib64 does exist, >>>>> but it only holds gcc's libs, and as a result, the necessary libs >>>>> aren't found. >>>> >>>> So, what output do you get from >>>> >>>>x86_64-w64-mingw32-gcc --print-search-dirs >>>> >>>> I get: >>>> >>>> $ x86_64-w64-mingw32-gcc --print-search-dirs &
Re: libtool woes
On 9/10/13, Peter Rosin wrote: [...] >> @@ -2416,10 +2416,22 @@ >>sys_lib_search_path_spec="$sys_lib_search_path_spec >> /usr/lib/w32api"]) >>;; >> mingw* | cegcc*) >># MinGW DLLs use traditional 'lib' prefix >>soname_spec='$libname`echo $release | $SED -e >> 's/[[.]]/-/g'`$versuffix$shared_ext' >> + sys_lib_search_path_spec=`$CC -print-search-dirs | grep >> "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"` >> + if echo "$sys_lib_search_path_spec" | [grep ';[c-zC-Z]:/' >>> /dev/null]; then >> +# It is most probably a Windows format PATH printed by >> +# mingw gcc, but we are running on Cygwin. Gcc prints its search >> +# path with ; separators, and with drive letters. We can handle >> the >> +# drive letters (cygwin fileutils understands them), so leave >> them, >> +# especially as we might pass files found there to a mingw >> objdump, >> +# which wouldn't understand a cygwinified path. Ahh. >> +sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | >> $SED -e 's/;/ /g'` >> + else >> +sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | >> $SED -e "s/$PATH_SEPARATOR/ /g"` >> + fi >>;; >> pw32*) >># pw32 DLLs use 'pw' prefix rather than 'lib' >>library_names_spec='`echo $libname | sed -e 's/^lib/pw/'``echo >> $release | $SED -e 's/[[.]]/-/g'`$versuffix$shared_ext' >>;; >> >> [...] >> However, the last third hunk is the heart of it: adding that fixes >> the issue. That part was present in 2.2.6 but was removed in 2.2.8 >> and later. What was the reason? (I couldn't find in the history using >> gitweb, but didn't try hard enugh either..) > > That last hunk will evade the multilib loop by redoing the > -print-search-dirs > thing one more time after that loop. However, it is severely broken on > native MinGW [1] and can definitely not be added as is. Sorry. > > [1] http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00052.html > That effectively cripples libtool for cross-compilers. Can the behavior be refined instead? Can you contact Charles Wilson about this? -- O.S. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
On 9/10/13, Ozkan Sezer wrote: > On 9/10/13, Peter Rosin wrote: > [...] >>> @@ -2416,10 +2416,22 @@ >>>sys_lib_search_path_spec="$sys_lib_search_path_spec >>> /usr/lib/w32api"]) >>>;; >>> mingw* | cegcc*) >>># MinGW DLLs use traditional 'lib' prefix >>>soname_spec='$libname`echo $release | $SED -e >>> 's/[[.]]/-/g'`$versuffix$shared_ext' >>> + sys_lib_search_path_spec=`$CC -print-search-dirs | grep >>> "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"` >>> + if echo "$sys_lib_search_path_spec" | [grep ';[c-zC-Z]:/' >>>> /dev/null]; then >>> +# It is most probably a Windows format PATH printed by >>> +# mingw gcc, but we are running on Cygwin. Gcc prints its >>> search >>> +# path with ; separators, and with drive letters. We can handle >>> the >>> +# drive letters (cygwin fileutils understands them), so leave >>> them, >>> +# especially as we might pass files found there to a mingw >>> objdump, >>> +# which wouldn't understand a cygwinified path. Ahh. >>> +sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | >>> $SED -e 's/;/ /g'` >>> + else >>> +sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | >>> $SED -e "s/$PATH_SEPARATOR/ /g"` >>> + fi >>>;; >>> pw32*) >>># pw32 DLLs use 'pw' prefix rather than 'lib' >>>library_names_spec='`echo $libname | sed -e 's/^lib/pw/'``echo >>> $release | $SED -e 's/[[.]]/-/g'`$versuffix$shared_ext' >>>;; >>> >>> > [...] >>> However, the last third hunk is the heart of it: adding that fixes >>> the issue. That part was present in 2.2.6 but was removed in 2.2.8 >>> and later. What was the reason? (I couldn't find in the history using >>> gitweb, but didn't try hard enugh either..) >> >> That last hunk will evade the multilib loop by redoing the >> -print-search-dirs >> thing one more time after that loop. However, it is severely broken on >> native MinGW [1] and can definitely not be added as is. Sorry. >> >> [1] >> http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00052.html >> > > That effectively cripples libtool for cross-compilers. Can the behavior > be refined instead? Can you contact Charles Wilson about this? > OK, I sent a message to bug-libtool about this (hopefully it arrives there.) -- O.S. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
On 9/10/13, Peter Rosin wrote: > 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-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? >>>>> >>>> >>>> No, it does not. With this patch applied, I see >>>> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc " >>>> .. in the libtool --config output. >>> >>> Crap, I didn't do any final test and managed to exclude a couple >>> of critical changes, and I did a couple of silly mistakes too. Sorry >>> about that. Attached is what I should have sent the first time... >>> >> >> Thanks, this one makes it to work. ./libtool --config output now has: >> >> sys_lib_search_path_spec="/opt/W64_180676/lib/gcc >> /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 >> /opt/W64_180676/x86_64-w64-mingw32/lib /opt/cross_win64/mingw/lib " >> >> which is suitable. > > *snip* > >> Is it hard to implement a way of directly respecting --print-search-dirs >> output of the compiler though? > > Which is the crux of the matter, isn't it? The thing is, I'm not at all > comfortable with applying this change, and have no clue if it breaks > any existing setup. I mean, to me it seems obvious that if > -print-search-dirs outputs *both* a .../lib64 and a .../lib variant, then > someone really thought the tools should look in both places even if the > -print-multi-os-directory is ../lib64. But at the same time, it is very > likely that this loop in libtool (which is problematic for this case) > solves a real problem somewhere. Since I do not know why the loop is > there in the first place (the natural thing would be to simply trust > -print-search-dirs, just as you say) I'm uneasy to change it. > > Peter O'Gorman (explicitly CC:ed) added the loop [1], hopefully he can > fill in some blanks... > > Cheers, > Peter > > [1] http://lists.gnu.org/archive/html/libtool-patches/2006-10/msg8.html > 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 from me, but the ones from you from this thread are there, so I don't know whether any of the mails I send arrive at the list..) -- O.S. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
On 9/11/13, Peter Rosin wrote: > 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 >>> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html >>> doesn't list any mails from me, but the ones from you from this thread >>> are there, so I don't know whether any of the mails I send arrive at >>> the list..) >> >> That's strange, but you are correct in that all mails I have >> received from you have been coming directly too me, and none have >> arrived through the list. Maybe they are stuck in moderation, but >> I don't know the details of that??? >> >> Anyway, I managed to dig up at least some background, see this thread >> >> http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html > > More background [1], [2]: > > Alan Modra hints in [1] that -print-search-dirs was fixed in GCC 4.2, > so that it nowadays automatically appends -print-multi-os-directory > for the applicable directories. I.e. it should no longer be necessary > for libtool to append a second ../lib64 when GCC has already done so. > Also, the multi-os appending crap seems to have been added specifically > for early (arguably broken) bi-arch enabled GCCs that printed -m32 > directories even though -m64 was the default. So, my conclusion is > that we want any libtool magic to affect -print-search-dirs output from > contemporary GCCs as little as possible, while continuing to append > the -print-multi-os-directory for the legacy case. > > The thing to look out for could be if any of the -print-search-dirs > ends with /$lt_multi_os_dir and use that as an indicator that we have > a sufficiently new GCC, and all -print-search-dirs should be left as > is (we should probably continue prune those that don't exist, though). > > I have attached a version that implements the above idea. I can confirm that with this applied to libtool-git, I can build a dll using cross-toolchains on linux. The `libtool --config` output for sys_lib_search_path_spec contains, - for a i686-pc-mingw32 toolchain with gcc-3.4.5: "/usr/local/cross-win32/i686-pc-mingw32/lib /usr/local/cross-win32/lib /usr/local/cross-win32/usr/lib " - for a i686-w64-mingw32 toolchain with gcc-4.5.4: "/opt/W32_180676/lib/gcc /opt/W32_180676/i686-w64-mingw32/lib32 /opt/cross_win32/mingw/lib32 /opt/W32_180676/i686-w64-mingw32/lib /opt/cross_win32/mingw/lib " - for an x86_64-w64-mingw32 toolchain with gcc-4.5.4: "/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64 /opt/cross_win64/mingw/lib64 /opt/W64_180676/x86_64-w64-mingw32/lib /opt/cross_win64/mingw/lib " Thanks for working on this. > I feel > pretty good about that one actually, but would still like some > feedback from someone more familiar with multilib... > > Or should we just ditch support for those early, arguably broken, > bi-arch GCC versions and start trusting -print-search-dirs > unconditionally??? > > Cheers, > Peter > > [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425 > [2] http://gcc.gnu.org/ml/gcc/2006-09/msg00184.html > -- O.S. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool woes
On Wed, Sep 11, 2013 at 1:32 PM, Ozkan Sezer wrote: > On 9/11/13, Peter Rosin wrote: >> 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 >>>> http://lists.gnu.org/archive/html/bug-libtool/2013-09/index.html >>>> doesn't list any mails from me, but the ones from you from this thread >>>> are there, so I don't know whether any of the mails I send arrive at >>>> the list..) >>> >>> That's strange, but you are correct in that all mails I have >>> received from you have been coming directly too me, and none have >>> arrived through the list. Maybe they are stuck in moderation, but >>> I don't know the details of that??? >>> >>> Anyway, I managed to dig up at least some background, see this thread >>> >>> http://lists.gnu.org/archive/html/bug-libtool/2006-09/msg00019.html >> >> More background [1], [2]: >> >> Alan Modra hints in [1] that -print-search-dirs was fixed in GCC 4.2, >> so that it nowadays automatically appends -print-multi-os-directory >> for the applicable directories. I.e. it should no longer be necessary >> for libtool to append a second ../lib64 when GCC has already done so. >> Also, the multi-os appending crap seems to have been added specifically >> for early (arguably broken) bi-arch enabled GCCs that printed -m32 >> directories even though -m64 was the default. So, my conclusion is >> that we want any libtool magic to affect -print-search-dirs output from >> contemporary GCCs as little as possible, while continuing to append >> the -print-multi-os-directory for the legacy case. >> >> The thing to look out for could be if any of the -print-search-dirs >> ends with /$lt_multi_os_dir and use that as an indicator that we have >> a sufficiently new GCC, and all -print-search-dirs should be left as >> is (we should probably continue prune those that don't exist, though). >> >> I have attached a version that implements the above idea. > > I can confirm that with this applied to libtool-git, I can build a dll > using cross-toolchains on linux. The `libtool --config` output for > sys_lib_search_path_spec contains, > > - for a i686-pc-mingw32 toolchain with gcc-3.4.5: > "/usr/local/cross-win32/i686-pc-mingw32/lib /usr/local/cross-win32/lib > /usr/local/cross-win32/usr/lib " > > - for a i686-w64-mingw32 toolchain with gcc-4.5.4: > "/opt/W32_180676/lib/gcc /opt/W32_180676/i686-w64-mingw32/lib32 > /opt/cross_win32/mingw/lib32 /opt/W32_180676/i686-w64-mingw32/lib > /opt/cross_win32/mingw/lib " > > - for an x86_64-w64-mingw32 toolchain with gcc-4.5.4: > "/opt/W64_180676/lib/gcc /opt/W64_180676/x86_64-w64-mingw32/lib64 > /opt/cross_win64/mingw/lib64 /opt/W64_180676/x86_64-w64-mingw32/lib > /opt/cross_win64/mingw/lib " > > Thanks for working on this. > > >> I feel >> pretty good about that one actually, but would still like some >> feedback from someone more familiar with multilib... >> >> Or should we just ditch support for those early, arguably broken, >> bi-arch GCC versions and start trusting -print-search-dirs >> unconditionally??? >> >> Cheers, >> Peter >> >> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425 >> [2] http://gcc.gnu.org/ml/gcc/2006-09/msg00184.html >> > Any chance that this patch, or a patch that fixes bug #15321 [1], gets applied any time? -- O.S. [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15321 ___ https://lists.gnu.org/mailman/listinfo/libtool
bootstrap breakage starting with fec7d87
Starting with fec7d87 ("funclib.sh: simplify version comparison
functions") I am getting the following error from bootstrap:
bootstrap: error: 'makeinfo' version == 4.13 is too old
bootstrap:'makeinfo' version >= 4.8 is required
9fd7b88 is fine.
This is with Fedora 16, with grep-2.9-3.fc16.x86_64,
sed-4.2.1-9.fc16.x86_64, and bash-4.2.37-1.fc16.x86_64
--
O.S.
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: bootstrap breakage starting with fec7d87
> Starting with fec7d87 ("funclib.sh: simplify version comparison
> functions") I am getting the following error from bootstrap:
>
> bootstrap: error: 'makeinfo' version == 4.13 is too old
> bootstrap:'makeinfo' version >= 4.8 is required
>
> 9fd7b88 is fine.
>
> This is with Fedora 16, with grep-2.9-3.fc16.x86_64,
> sed-4.2.1-9.fc16.x86_64, and bash-4.2.37-1.fc16.x86_64
>
Will this be fixed anytime soon?
--
O.S.
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: git commit forces bootstrap
On Fri, Dec 6, 2013 at 10:11 AM, Peter Rosin wrote: > 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: executing libtool commands > GEN ../../build-aux/ltmain.sh > inline-source: error: file 'build-aux/funclib.sh' not found > inline-source: error: file 'build-aux/options-parser' not found > GEN libtool > config.status: executing libtool commands > GEN libtoolize > GEN public-submodule-commit > > Is it expected that I need to manually rerun bootstrap after every commit? > I guess git status change is forcing a version change, thus requiring a bootstrap? -- O.S. ___ https://lists.gnu.org/mailman/listinfo/libtool
status of the os2 patches
Will the os2 patches posted by KO Myung-Hun back in november 2011 (links below) be merged mainline? http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg4.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg5.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg6.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg7.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg8.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg9.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg00010.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg00011.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg00012.html http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg00013.html -- O.S. http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg4.html From: KO Myung-Hun Subject: [PATCH] OS/2 patches Date: Sun, 4 Nov 2012 21:13:25 +0900 Hi/2. These are the patches for OS/2. Review, please. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg5.html From: KO Myung-Hun Subject: [PATCH 1/9] libtool: add -shortname option Date: Sun, 4 Nov 2012 21:13:26 +0900 OS/2 limits a length of a DLL base name up to 8 characters. If a name of a shared library is longer than 8 characters, OS/2 cannot load it. So the option to specify a short name is needed. * NEWS: Add news for -shortname. * build-aux/ltmain.in(func_mode_help): Add a description for -shortname. (fund_mode_link): Add -shortname. * doc/libtool.texi: Add -shortname item. * m4/libtool.m4: Introduce shortname_cmds for -shortname. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg6.html From: KO Myung-Hun Subject: [PATCH 2/9] libtool: don't eliminate duplications in $postdeps and $predeps on OS/2 Date: Sun, 4 Nov 2012 21:13:27 +0900 * build-aux/ltmain.h(libtool_validate_options): Add *os2* to the list. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg7.html From: KO Myung-Hun Subject: [PATCH 3/9] libtool: set lt_prog_compiler_static to -Bstatic on OS/2 Date: Sun, 4 Nov 2012 21:13:28 +0900 * m4/libtool.m4(_LT_COMPILER_PIC): Same as the title. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg8.html From: KO Myung-Hun Subject: [PATCH 4/9] ltdl: OS/2 uses other APIs to load a DLL than LoadLibrary() on Windows Date: Sun, 4 Nov 2012 21:13:29 +0900 *m4/ltdl.m4: Remove os2* from a list for loadlibrary.la. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg9.html From: KO Myung-Hun Subject: [PATCH 5/9] libtool: there is no need to relink DLLs on OS/2 Date: Sun, 4 Nov 2012 21:13:30 +0900 *build-aux/ltmain.in(func_mode_link): Set need_relink to no on OS/2. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg00010.html From: KO Myung-Hun Subject: [PATCH 6/9] libtool: set lt_cv_deplibs_check_method to pass_all on OS/2 Date: Sun, 4 Nov 2012 21:13:31 +0900 *m4/libtool.m4(_LT_CHECK_MAGIC_METHOD): Same as the title. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg00011.html From: KO Myung-Hun Subject: [PATCH 7/9] libtool: support -Zxxx options used on OS/2 Date: Sun, 4 Nov 2012 21:13:32 +0900 *build-aux/ltmain.in(fund_mode_link): Add -Z* case. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg00012.html From: KO Myung-Hun Subject: [PATCH 8/9] libtool: create an import libraries instead of links to the real library on OS/2 Date: Sun, 4 Nov 2012 21:13:33 +0900 Link is not supported on OS/2. *build-aux/ltmain.in(fund_mode_install): Create an import library. (fund_mode_link): Likewise. -- http://lists.gnu.org/archive/html/libtool-patches/2012-11/msg00013.html From: KO Myung-Hun Subject: [PATCH 9/9] libtool: fix a problem that it fails to find proper libraries if .la is a dependency on OS/2 Date: Sun, 4 Nov 2012 21:13:34 +0900 *build-aux/ltmain.in(func_mode_link): Same as the title. diff --git a/NEWS b/NEWS index c8730c7..a372a77 100644 --- a/NEWS +++ b/NEWS @@ -107,6 +107,8 @@ NEWS - list of user-visible changes between releases of GNU Libtool ** Changes in supported systems or compilers: + - Added -shortname option to specify a short name for a DLL (OS/2 only) + - Support for bitrig (*-*-bitrig*). - Solaris 7 and earlier requires ECHO=/usr/ucb/echo in the build diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index f452e54..d768af3 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -497,7 +497,7 @@ libtool_validate_options () test : = "$debug_cmd" || func_append preserve_args " --debug" case $host in - *cygwin* | *mingw* | *pw32* | *cegcc*) + *cygwin* | *mingw* | *pw32* | *cegcc* | *os2*) # don't eliminate duplications in $postdeps and $predeps opt_duplicate_compiler_generated_deps=: ;; @@ -1815,6 +1815,7 @@ The following components of LINK-COMMAND are treated specially: -rpath LIBDIR the created library
Re: New release with OSX Yosemite fix?
On 10/23/14, Gary V. Vaughan wrote: >> On 23 Oct 2014, at 15:06, Volker Braun wrote: >> >> Is there any chance for cutting a new release with the OSX Yosemite >> version parsing fix? This is going to affect a lot of users, and right >> now there isn't even a released version of libtools to run reconfigure >> with. >> >> http://lists.gnu.org/archive/html/libtool-patches/2014-09/msg2.html > > > Ugh. I'm surprised that one hasn't bitten me already! > > The master branch still has known bugs that I don't want to release, so the > best bet is to make a patch release from the last stable release. The > process is fiddly and takes several hours to complete though, so I'll leave > it for a few days to give people a chance to point me at any other critical > patches that should be rolled in too... > > Cheers, > -- > Gary V. Vaughan (gary AT gnu DOT org) I'd like to see this particular one in such an interim release: http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commit;h=0ebb734910bf56186dd0c0e84b1c8be507bad336 to fix http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15321 -- O.S. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] any critical patches for a release this weekend?
> On Oct 23, 2014, at 3:10 PM, Gary V. Vaughan wrote: > > I plan to roll a release based off the v2.4.2 tag, incorporating fixes > for version mismatches against Mac OS Yosemite this weekend - in > consideration of the fact that there are still known regressions in > master. > > If there's anything else I should include, or suggestions for a better > revision to base the release from, please reply ASAP :-) > I'd like to see this particular one: http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commit;h=0ebb734910bf56186dd0c0e84b1c8be507bad336 to fix http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15321 -- O.S. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: New libtool maintainer
On 10/27/21, Alex Ameen wrote: > Howdy! > > This is Alex Ameen reporting in from Austin, Texas. I'm a long time GNU > and `autotools' user who specializes in ELF linking and loading. I'm > writing you today to introduce myself and announce that I was recently > approved as the new maintainer of `libtool'! > > I'm excited to bring some updates to the tool and want to thank everyone > for their patience while I work my through the pending patch/bug lists > and get familiar with some of the maintenance infrastructure. > > In the near future I look forward to extending `libtool' support for > modern ELF shared objects, and improved integration with the rest of > `autotools'. I'll share a more detailed roadmap after I've worked my > through the pending tasks in the mailing lists. > > I want to express my appreciation for all of the `autotools' and > `libtool' maintainers/contributors before me. I understand that > `libtool' is an important piece of infrastructure for a number of > important pieces of software, and I aim to treat modifications and > extensions appropriately with that responsibility in mind ( don't worry > I'm not going to break legacy behavior with reckless abandon haha ). > > Feel free to reach out if you have pending patches/issues you want to > "bump", ideas for improvements, general advice for a new GNU maintainer > - and above all if you'd like to lend a hand toward getting `libtool' up > and running again. > > Thank you for your time, > > -Alex Ameen It would be nice if the patches for the following long-standing bugs were applied: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21137 (also reported duplicately as 22895, 31900 and 36762) https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22373 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38305 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46559 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44605 (also see 44684) And maybe this? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41837 -- O.S.
Re: disable invocation of winepath by libtool
On 12/5/21, ilya Basin wrote: > Dear List. I'm cross compiling a program on Linux for a mingw host and > sometimes this shows Wine dialogs like "updating wine configuration" or > "download and install Mono". I believe it's only needed to run `make check` > successfully, but I want to skip the test suite. How to properly prevent the > invocation if winepath? Using winepath in libtool really is an abomination and must be removed. Related: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253
Re: New libtool maintainer
On 2/8/22, Julien ÉLIE wrote: > Hi Alex, > >> Feel free to reach out if you have pending patches/issues you want to >> "bump", ideas for improvements, general advice for a new GNU maintainer >> - and above all if you'd like to lend a hand toward getting `libtool' up >> and running again. > > Many thanks for your work on Libtool! > > I believe a good start would be to integrate suggestions and patches > from the issue tracker > >https://savannah.gnu.org/patch/?group=libtool > > and maybe also some patches Debian (and other distributions) have added > over the years to the last 2.4.6 release. For instance: > >https://sources.debian.org/patches/libtool/2.4.6-15/ Some of the outstanding bugs with existing patches : https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38305 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21137 (and its dups at 22895, 31900, and 36762) https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21503 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22373 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46559 Some of the outstanding bugs without any suggested patches: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45738 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53479
Re: New libtool maintainer
On 2/8/22, Roumen Petrov wrote: > As result is expected Debian to be flooded with defects. > >> Some of the outstanding bugs with existing patches : >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38305 >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348 >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21137 >> (and its dups at 22895, 31900, and 36762) >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21503 >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22373 >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46559 >> >> Some of the outstanding bugs without any suggested patches: >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45738 >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53479 > > If those bugs are not Debian specific someone could look at them. They have nothing to do with debian. -- O.S.
Re: Introducing a new maintainer of libtool
Please remember to check with debbugs.gnu.org: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=libtool;max-bugs=100;base-order=1;bug-rev=1 There are plenty of bugs in there. E.g.: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45738 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46559 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53479 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41837 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348 (... some of which have already been fixed, I haven't checked.) -- O.S.
Re: Introducing a new maintainer of libtool
On 1/18/24, Mike Frysinger wrote: > On 17 Jan 2024 20:07, Ozkan Sezer wrote: [...] >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253 > > doesn't look like a regression. it can wait. It's a regression from 2.2.6, later versions have the issue, so how is it not a regression?
Re: [sr #111069] libtool: patch: Fix dynamic_lookup warnings from new Mac linker
> I have merged a patch in the development branch to append '-no_fixup_chains' > for macOS versions 11.3*-14* and Xcode versions 13-15*. I have verified this > removes the warning that I was seeing on macOS 12.7.5, Xcode > 14.2.0.0.1.1668646533 [1][2]. I have not seen any regressions from this on > macOS 11-14 CI tests, so I will close this issue now. I believe the patch is this, yes? http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=001d22d7d587e85a911c71c4d0c798ede8014b77 I haven't tested yet, but unless I'm missing something, it relies on the build environment not being a cross-environment. Can we not check linker version instead?
Re: [sr #111069] libtool: patch: Fix dynamic_lookup warnings from new Mac linker
On Thu, Jun 27, 2024 at 5:29 PM Ileana Dumitrescu wrote: > > Follow-up Comment #16, sr #111069 (group libtool): > > I have updated development with a feature test: > > https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=3d1baeeef90a6b9e16c545babe833f28dca155a7 > > Please tell me if there are any issues with it. Working for me: -no_fixup_chains support is detected correctly against several Apple linker versions in my linux-to-mac cross-compile attempts. -- O.S.
Re: -no_fixup_chains patch
[Sorry, I seem to have deleted the mailing list message from my inbox] Regarding -no_fixup_chains patch i.e. http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=3d1baeeef90a6b9e16c545babe833f28dca155a7 Is '+=' universally supported?? Maybe change to something like the following?? diff --git a/m4/libtool.m4 b/m4/libtool.m4 index 381d4cb..31f1be0 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -1032,3 +1032,3 @@ [ save_LDFLAGS=$LDFLAGS -LDFLAGS+=" -Wl,-no_fixup_chains" +LDFLAGS="$LDFLAGS -Wl,-no_fixup_chains" AC_LINK_IFELSE( @@ -1093,3 +1093,3 @@ _LT_EOF if test yes = "$lt_cv_support_no_fixup_chains"; then -_lt_dar_allow_undefined+=' $wl-no_fixup_chains' +_lt_dar_allow_undefined='$_lt_dar_allow_undefined $wl-no_fixup_chains' fi
[PATCH] fix appending of -no_fixup_chains to _lt_dar_allow_undefined
With current development branch, 'allow_undefined_flag' in the libtool
script generated after running configure looked like this:
allow_undefined_flag="\$_lt_dar_allow_undefined \$wl-no_fixup_chains"
The solution I ended up with and applied in SDL is the following:
(also attached as I'm sure gmail will mangle the patch)
Any better solution is welcome, of course.
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 31f1be0..5357a3d 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1089,9 +1089,10 @@ _LT_EOF
10.[[012]],*|,*powerpc*-darwin[[5-8]]*)
_lt_dar_allow_undefined='$wl-flat_namespace $wl-undefined
${wl}suppress' ;;
*)
- _lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup'
if test yes = "$lt_cv_support_no_fixup_chains"; then
-_lt_dar_allow_undefined='$_lt_dar_allow_undefined
$wl-no_fixup_chains'
+_lt_dar_allow_undefined='$wl-undefined
${wl}dynamic_lookup $wl-no_fixup_chains'
+ else
+_lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup'
fi
;;
esac
From 6bf0f2866144135dc52777d63ffbd74772a987f8 Mon Sep 17 00:00:00 2001
From: Ozkan Sezer
Date: Sat, 29 Jun 2024 17:51:56 +0300
Subject: [PATCH] libtool.m4: fix appending of -no_fixup_chains to _lt_dar_allow_undefined
---
m4/libtool.m4 |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 31f1be0..5357a3d 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1089,9 +1089,10 @@ _LT_EOF
10.[[012]],*|,*powerpc*-darwin[[5-8]]*)
_lt_dar_allow_undefined='$wl-flat_namespace $wl-undefined ${wl}suppress' ;;
*)
- _lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup'
if test yes = "$lt_cv_support_no_fixup_chains"; then
-_lt_dar_allow_undefined='$_lt_dar_allow_undefined $wl-no_fixup_chains'
+_lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup $wl-no_fixup_chains'
+ else
+_lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup'
fi
;;
esac
--
1.7.1
Re: -no_fixup_chains patch
On Wed, Jul 3, 2024 at 6:42 PM Ileana Dumitrescu
wrote:
>
> On 02/07/2024 22:01, Václav Haisman wrote:
> > On 28. 06. 24 0:41, Ozkan Sezer wrote:
> >> [Sorry, I seem to have deleted the mailing list message from my inbox]
> >>
> >> Regarding -no_fixup_chains patch i.e.
> >>
> >> http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=3d1baeeef90a6b9e16c545babe833f28dca155a7
> >>
> >> Is '+=' universally supported?? Maybe change to something like the
> >> following??
> >
> > Is there a reason not to use AS_VAR_APPEND?
> > (https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Polymorphic-Variables.html)
> >
>
> I do not think there is a reason not to, so I generated a patch for it:
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index e9eef32f..36e5bf4e 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -1089,10 +1089,9 @@ _LT_EOF
> 10.[[012]],*|,*powerpc*-darwin[[5-8]]*)
> _lt_dar_allow_undefined='$wl-flat_namespace $wl-undefined
> ${wl}suppress' ;;
> *)
> + _lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup'
> if test yes = "$lt_cv_support_no_fixup_chains"; then
> -_lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup
> $wl-no_fixup_chains'
> - else
> -_lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup'
> +AS_VAR_APPEND([_lt_dar_allow_undefined], ['
> $wl-no_fixup_chains'])
> fi
> ;;
> esac
> --
>
> It should result in:
> allow_undefined_flag="\$wl-undefined \${wl}dynamic_lookup
> \$wl-no_fixup_chains"
Seems to work for me. IMO, it is a bit of an extravaganza, but I have no
strong no feelings against it...
However, if you guys do this: AS_VAR_APPEND requires autoconf 2.64. What
is the minimum required autoconf version for libtool.m4?
--
O.S.
Re: -no_fixup_chains patch
On Thu, Jul 4, 2024 at 4:54 PM Ileana Dumitrescu wrote: > > On 03/07/2024 21:28, Ozkan Sezer wrote: > > On Wed, Jul 3, 2024 at 6:42 PM Ileana Dumitrescu > > wrote: > > However, if you guys do this: AS_VAR_APPEND requires autoconf 2.64. What > > is the minimum required autoconf version for libtool.m4? > > The current minimum autoconf version required is 2.62 for libtool.m4. > For bootstrapping libtool, it requires 2.64 already, and standalone > libtool needs 2.59 of autoconf. I do not think it should be an issue to > bump the required minimum autoconf version for libtool.m4 from 2.62 to > 2.64, but tell me if there are concerns. No concerns from me
