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

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,

http://git.videolan.org/?p=vlc.git;a=blob;f=configure.ac;h=4aef56f06e3d16c8fe378055155126943d7ed69#l526

by manually setting this:

lt_cv_deplibs_check_method=pass_all

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

*** Warning: Trying to link with static lib archive C:/code/llvm-mingw/lib/clang/9.0.0/lib/windows/libclang_rt.builtins-x86_64.a.
*** 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
    ;;

  cegcc*)


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:

> Mike,
>
> Do you know who can commit this?
>
> On Mon, Jul 23, 2018 at 8:33 AM, Martin Storsjö <[email protected]> wrote:
>> Mike and Manoj,
>>
>> Another gentle ping on this subject...
>>
>> // Martin
>>
>>
>> On Sat, 17 Mar 2018, Manoj Gupta wrote:
>>
>>> Mike,
>>> Any ideas who can commit this to upstream libtool?
>>>
>>> On Wed, Feb 28, 2018 at 12:55 PM, Martin Storsjö
>>> <[email protected]> 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
>>>                   *.${libext}
>>>                   handle both cases?
>>>
>>>
>>>             libext is only "a".  for shared
>>>             libs, it can be calculated from
>>>             shrext_cmds.
>>>              eval
>>>             std_shrext=\"$shrext_cmds\"
>>>              -L* | -R* | -l* | *.${libext} |
>>>             *${std_shrext})
>>>
>>>             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
>>>
>>>
>>>
>>
>

_______________________________________________
Bug-libtool mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-libtool