Re: bfd and cygpath

[NightStrike]

On Wed, Apr 24, 2013 at 2:47 AM, Peter Rosin <address@hidden> wrote:
> On 2013-04-23 16:12, NightStrike wrote:

>> 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.

Thank you for this analysis!  Do you think setting the --with-gnu-ld
configure option will do the trick?  (I'm using gnu ld)

I'll try it now and see what happens.


> 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)

Interesting...  it even goes so far as to make the lib extension be
that of MSVC.  Ok, point taken, I'll treat the cause and not the
symptom.  binutils really could use a libtool update, though.