Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

[Charles Wilson]

On 9/8/2010 5:52 PM, Peter Rosin wrote:
> Den 2010-09-05 23:29 skrev Ralf Wildenhues:
>> * Peter Rosin wrote on Sun, Sep 05, 2010 at 10:02:11PM CEST:
>>> Subject: [PATCH 6/7] Convert file name to toolchain format when invoking 
>>> $NM.
>>>
>>> * libltdl/config/ltmain.m4sh (func_generate_dlsyms)
>>> (func_win32_libid, func_cygming_gnu_implib_p)
>>> (func_cygming_ms_implib_p): When using the name lister to find
>>> symbols in files, convert the file names to a format appropriate
>>> for the tool.
>>
>> You're gonna hate me for this, I already know, but: does this patch fix
>> testsuite failures, are all code paths covered?  If not, we need to
>> improve the test suite.  If yes, please mention them in the log, thanks.
> 
> Those in func_cygming_gnu_implib_p and func_cygming_ms_implib_p
> appear to be dead code. Both functions are only called from
> func_cygming_dll_for_implib_fallback which only use is that it
> is assigned to the cache variable lt_cv_sharedlib_from_linklib_cmd
> whose value is in turn only assigned to the LT_DECL variable
> sharedlib_from_linklib_cmd, which is not used anywhere according
> to my searching.

Err...yes it is, around line 2546 in ltmain.m4sh:

  for dlprefile in $dlprefiles; do
    func_verbose "extracting global C symbols from \`$dlprefile'"
    func_basename "$dlprefile"
    name="$func_basename_result"
    case $host in
      *cygwin* | *mingw* | *cegcc* )
        # if an import library, we need to obtain dlname
        if func_win32_import_lib_p "$dlprefile"; then
    func_tr_sh "$dlprefile"
    eval "curr_lafile=\$libfile_$func_tr_sh_result"
    dlprefile_dlbasename=""
    if test -n "$curr_lafile" && func_lalib_p "$curr_lafile"; then
      # Use subshell, to avoid clobbering current variable values
      dlprefile_dlname=`source "$curr_lafile" && echo "$dlname"`
      if test -n "$dlprefile_dlname" ; then
        func_basename "$dlprefile_dlname"
        dlprefile_dlbasename="$func_basename_result"
      else
        # no lafile. user explicitly requested -dlpreopen <import library>.
        $sharedlib_from_linklib "$dlprefile"
        dlprefile_dlbasename=$sharedlib_from_linklib_result
      fi

Now, this happens only when "-dlprepen foo.dll.a" (as opposed to
foo.la). AND sharedlib_from_linklib is only assigned to
func_cygming_dll_for_implib_fallback when dlltool does not support the
--identify and --identify-strict options.  All *current* binutils
packages shipped by MinGW, MinGW64, and cygwin support that option.

So to trigger this, you have to

a) configure with
lt_cv_sharedlib_from_linklib_cmd=func_cygming_dll_for_implib_fallback

b) link using -dlpreopen /path/to/foo.dll.a

I've actually done that manually sometime in the last six months or so,
but I don't remember exactly when.  It worked then...




My initial plan was to remove _fallback and its supporting functions
about a year after the first official release of libtool containing this
stuff (gak, that giant sed script is AWFUL...)

We haven't even HAD that official release yet, so it's still a bit
premature to remove it, IMO. :-)

(However, there is an unfixed bug here; apparently something has changed
in libtool between when this patch was created, and when it was
committed, such that the static lib part no longer works properly; this
is why on cygwin and mingw the mdemo-exec tests STILL fail.  Very
frustrating.  I plan to track this down in the next day or so).

--
Chuck