[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27866: Handle clang's internal libraries when finding compiler's int

From: Martin Storsjö
Subject: bug#27866: Handle clang's internal libraries when finding compiler's internal libraries
Date: Wed, 14 Aug 2019 23:46:04 +0300 (EEST)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

Hi Manoj, Mike, Pavel and others,

While this isn't yet fixed upstream, I noted that this fix isn't enough for me in mingw setups.

I've mostly been running into this issue in trying to compile VLC, where this fix has been enough, but with other projects the issue remains. The root cause for this seems to be that VLC overrides one libtool decision here,


by manually setting this:


In other projects that don't set this, linking with libtool prints this warning:

*** Warning: Trying to link with static lib archive 
*** 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 the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.

Manoj, did you run into this issue anywhere?

I'm able to work around it by patching libtool to do essentially the same, to set lt_cv_deplibs_check_method to pass_all, e.g. like this:

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index b55a6e57..c1eebf4c 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3487,17 +3487,7 @@ cygwin*)

 mingw* | pw32*)
-  # Base MSYS/MinGW do not provide the 'file' command needed by
-  # func_win32_libid shell function, so use a weaker test based on 'objdump',
-  # unless we find 'file', for example because we are cross-compiling.
-  if ( file / ) >/dev/null 2>&1; then
-    lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
-    lt_cv_file_magic_cmd='func_win32_libid'
-  else
-    # Keep this pattern in sync with the one in func_win32_libid.
-    lt_cv_deplibs_check_method='file_magic file format 
(pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64)'
-    lt_cv_file_magic_cmd='$OBJDUMP -f'
-  fi
+  lt_cv_deplibs_check_method=pass_all


However, this doesn't seem ideal. Is there any other way around it, to link against a literal path to an .a file while building a shared library?

// Martin

On Mon, 23 Jul 2018, Manoj Gupta wrote:


Do you know who can commit this?

On Mon, Jul 23, 2018 at 8:33 AM, Martin Storsjö <address@hidden> wrote:
Mike and Manoj,

Another gentle ping on this subject...

// Martin

On Sat, 17 Mar 2018, Manoj Gupta wrote:

Any ideas who can commit this to upstream libtool?

On Wed, Feb 28, 2018 at 12:55 PM, Martin Storsjö
<address@hidden> wrote:
      On Fri, 19 Jan 2018, Mike Frysinger wrote:

            On 19 Jan 2018 17:34, Manoj
            Gupta wrote:
                  I think that both .a
                  and .so libraries
                  should be handled
                  here. Will
                  handle both cases?

            libext is only "a".  for shared
            libs, it can be calculated from
             -L* | -R* | -l* | *.${libext} |

            that would only support libs
            that end in ".so".  but maybe
            that's OK.

      Gentle ping - I'm also running into this
      issue, and would like to have a canonical
      fix for it upstream.

      // Martin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]