Re: bfd and cygpath

[Peter Rosin]

On 2013-04-23 16:12, NightStrike wrote:
> On Tue, Apr 23, 2013 at 4:02 AM, NightStrike <address@hidden> wrote:
>> Building bfd in a particular cross compiler scenario requires that
>> cygpath be set to "echo".  bfd configury has the tools to do this, but
>> it's broken.  Configure properly does this:
>>
>> # test whether we have cygpath
>> if test -z "$CYGPATH_W"; then
>>   if (cygpath --version) >/dev/null 2>/dev/null; then
>>     CYGPATH_W='cygpath -w'
>>   else
>>     CYGPATH_W=echo
>>   fi
>> fi
>>
>> But then fails to actually use that variable where it counts:
>>
>>       fix_srcfile_path='`cygpath -w "$srcfile"`'
>>
>> and the subsequent build fails because of this.
>>
>> I see this in the resultant configure, but I don't see how it is
>> getting into the bfd configure.  There is a similar gcc bug here:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56412
>>
>> If it comes from libtool upstream, can somebody from binutils update
>> the libtool stuff?
> 
> Looks like it went in here:
> 
> http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/configure?rev=1.262&content-type=text/x-cvsweb-markup&cvsroot=src
> 
> Directly from updating libtool.
> 
> I can't find it in upstream libtool, though, so can somebody update
> libtool again?

The only code branch in libtool.m4 that in the past did set the
fix_srcfile_path variable can only be entered if libtool thinks
that GNU ld is not in use.

In libtool.m4, near the start of _LT_LINKER_SHLIBS, we have

  case $host_os in
  cygwin* | mingw* | pw32* | cegcc*)
    # FIXME: the MSVC++ port hasn't been tested in a loooong time
    # When not using gcc, we currently assume that we are using
    # Microsoft Visual C++.
    if test yes != "$GCC"; then
      with_gnu_ld=no
    fi
    ;;

So, either "$GCC" is not "yes", or with_gnu_ld ends up "no"
somewhere else, otherwise you can't hit the below code branch.

I will go out on a limb here and say that even if you "fix" the
symptom (fix_srcfile_path), you still do NOT want the other
assignments in that code branch and that you will be much
better off examining why you end up there, and fix that instead.
I'm including those assignments here, so that you can see
clearly why...

      *)
        # Assume MSVC wrapper
        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)=' '
        _LT_TAGVAR(allow_undefined_flag, $1)=unsupported
        # Tell ltmain to make .lib files, not .a files.
        libext=lib
        # Tell ltmain to make .dll files, not .so files.
        shrext_cmds=.dll
        # FIXME: Setting linknames here is a bad hack.
        _LT_TAGVAR(archive_cmds, $1)='$CC -o $lib $libobjs $compiler_flags 
`func_echo_all "$deplibs" | $SED '\''s/ -lc$//'\''` -link -dll~linknames='
        # The linker will automatically build a .lib file if we build a DLL.
        _LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
        # FIXME: Should let the user specify the lib program.
        _LT_TAGVAR(old_archive_cmds, $1)='lib -OUT:$oldlib$oldobjs$old_deplibs'
-       _LT_TAGVAR(fix_srcfile_path, $1)='`cygpath -w "$srcfile"`'
        _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
        ;;

(the fix_srcfile_path line was removed by commit d243a1ec5, first
released in Libtool 2.4)

Cheers,
Peter