[PATCH] ltmain.in: correct windows compiler preprocessor checks
Commit f54924fa5d8d5959038e58adab7c552c3ca495ae seems to have been wrongly applied. Regards. -- O.S. From e84eddb8b98fee7a31d95bb1b8e701f5ef3dca50 Mon Sep 17 00:00:00 2001 From: Ozkan Sezer Date: Fri, 1 Mar 2024 11:37:28 +0300 Subject: [PATCH] ltmain.in: correct windows compiler preprocessor checks Commit f54924fa5d8d5959038e58adab7c552c3ca495ae seems to have been wrongly applied. --- build-aux/ltmain.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in index 1b8d503..af4970b 100644 --- a/build-aux/ltmain.in +++ b/build-aux/ltmain.in @@ -3638,7 +3638,7 @@ EOF #endif #include #include -#if defined (WIN32) && !defined (__GNUC_) +#if defined (_WIN32) && !defined (__GNUC__) # include # include # include -- 1.7.1
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: 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: 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: 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: 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 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: bug#44684: libtool.m4 linker flag selection does not work for macOS Big Sur
On 11/16/20, Ryan Schmidt wrote: > Duplicate of #44605. Be that as it may, but this #44684 has, as it seems, a sensible patch. Shall no one review it?
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 kom...@gmail.com 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
Re: git commit forces bootstrap
On Fri, Dec 6, 2013 at 10:11 AM, Peter Rosin p...@lysator.liu.se 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
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
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: libtool woes
On Wed, Sep 11, 2013 at 1:32 PM, Ozkan Sezer seze...@gmail.com wrote: On 9/11/13, Peter Rosin p...@lysator.liu.se 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
Re: libtool woes
On 9/11/13, Peter Rosin p...@lysator.liu.se 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 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 p...@lysator.liu.se 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 p...@lysator.liu.se wrote: On 2013-09-10 09:47, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se 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. topdir/x86_64-w64-mingw32/lib, but 2.4 is not doing it and using topdir/x86_64-w64-mingw32/lib64 instead for reasons unfathomable to me. topdir/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 p...@lysator.liu.se 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 21 /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 p...@lysator.liu.se wrote: On 2013-09-10 10:55, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se wrote: On 2013-09-10 09:47, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se 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. topdir/x86_64-w64-mingw32/lib, but 2.4 is not doing it and using topdir/x86_64-w64-mingw32/lib64 instead for reasons unfathomable to me. topdir/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/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/ libraries: =/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/ In a rather hopeless attempt to fix this, I tried
Re: libtool woes
On 9/10/13, Ozkan Sezer seze...@gmail.com wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se 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 p...@lysator.liu.se wrote: On 2013-09-10 11:26, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se wrote: On 2013-09-10 10:55, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se wrote: On 2013-09-10 09:47, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se 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. topdir/x86_64-w64-mingw32/lib, but 2.4 is not doing it and using topdir/x86_64-w64-mingw32/lib64 instead for reasons unfathomable to me. topdir/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/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/ libraries: =/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
Re: libtool woes
On 9/10/13, Peter Rosin p...@lysator.liu.se wrote: On 2013-09-10 15:00, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se 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 seze...@gmail.com wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se wrote: On 2013-09-10 11:26, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se wrote: On 2013-09-10 10:55, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se wrote: On 2013-09-10 09:47, Ozkan Sezer wrote: On 9/10/13, Peter Rosin p...@lysator.liu.se 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. topdir/x86_64-w64-mingw32/lib, but 2.4 is not doing it and using topdir/x86_64-w64-mingw32/lib64 instead for reasons unfathomable to me. topdir/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/gcc/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../libexec/gcc/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/x86_64-w64-mingw32/4.5.4/:/opt/W64_180676/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/ libraries: =/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
