#981 inconsistent -Wl,option paths handling


Situation, under MSYS, running bash:

$ pwd
$ mount | grep tmp
T:\Temp on /tmp type user (binmode,noumount)
$ cat v.c
extern void foo();
$ ls -l /t/Temp/vs
-rw-r--r-- 1 zeitlin Administ 38 Nov 9 11:49
$ cat vs
V_1_0 {


$ g++ -shared -o v.dll v.c -Wl,--version-script,/t/Temp/vs
cannot open l
inker script file /t/Temp/vs: No such file or directory
collect2: ld returned 1 exit status

And -Wl,--version-script,/tmp/vs gives the same error.

But all of these commands work as expected:

$ g++ -shared -o v.dll v.c -Wl,--version-script,vs
$ g++ -shared -o v.dll v.c -Wl,--version-script,t:/Temp/vs
$ g++ -shared -o v.dll v.c -Wl,--version-script=/tmp/vs
$ g++ -shared -o v.dll v.c -Wl,--version-script,/t/Temp/vs

IOW, everything works ok if -Wl,--version-script= is
used but if comma is used instead of '=' then only the
paths not starting with slash (or backslash) work. This
is pretty weird and while the workaround is obvious
once you know it and version script is useless under
Win32 anyhow (but is still used by packages using
configure to detect ld version-script option support --
why does mingw32 ld support it at all?), it still was
not obvious to fix and it would be nice if it could
work or at least fail with some intelligible error
message. Thanks!

Information about the system used:

OS: Windows Server 2003 SP1
MINGW32_NT-5.2 NAMEDOESNTMATTER 1.0.10(0.46/3/2)
2004-03-15 07:17 i686 unknown

sh --version
GNU bash, version 2.04.0(1)-release (i686-pc-msys)
Copyright 1999 Free Software Foundation, Inc.

gcc -v
Reading specs from
Configured with: ../gcc/configure --with-gcc
--with-gnu-ld --with-gnu-as --host=mingw32 --target=min
gw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --dis
able-win32-registry --disable-shared
--enable-sjlj-exceptions --enable-libgcj
--disable-java-awt --w
ithout-x --enable-java-gc=boehm --disable-libgcj-debug
--enable-interpreter --enable-hash-synchroniz
ation --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)

ld -v
GNU ld version 2.15.91 20040904


  • Vadim Zeitlin

    Vadim Zeitlin - 2006-11-09

    Logged In: YES

    I'm updating this bug because it turns out that exactly the
    same problem affects -Wl,--out-implib (works with '=' but
    not with ',') and this is much more serious as it can't be
    just avoided, unlike -Wl,--version-script.

  • Vadim Zeitlin

    Vadim Zeitlin - 2006-11-09
    • summary: inconsistent version-script paths handling --> inconsistent -Wl,option paths handling
  • Danny Smith

    Danny Smith - 2006-11-09
    • assigned_to: dannysmith --> bblanchon
    • labels: 103946 --> MSYS
  • Danny Smith

    Danny Smith - 2006-11-09

    Logged In: YES

    Not mine.


  • Benoît Blanchon

    • assigned_to: bblanchon --> nobody
  • Earnie Boyd

    Earnie Boyd - 2006-11-24

    Logged In: YES
    Originator: NO

    I'll need to take a look at the coding but I think at the moment my stance will be that you *must* use the work around. I don't remember if I took care of this in the 1.0.11 update. It certainly is low on the round tuit list.

  • Earnie Boyd

    Earnie Boyd - 2006-11-24
    • priority: 5 --> 1
    • assigned_to: nobody --> earnie
    • status: open --> open-remind
  • Earnie Boyd

    Earnie Boyd - 2012-10-30

    Do we really want to do this? How do we handle the heuristics to decide when to and when not to?

  • Earnie Boyd

    Earnie Boyd - 2012-10-30
    • assigned_to: earnie --> cstrauss
    • status: open-remind --> pending-remind
  • Earnie Boyd

    Earnie Boyd - 2013-02-04
    • labels: MSYS -->
    • status: pending-remind --> pending
    • resolution: --> remind
    • category: --> Known_bugs
    • milestone: --> MSYS
  • Earnie Boyd

    Earnie Boyd - 2013-02-04

    Cesar any thought on this issue? Keith, how about you? I'm inclined to close it as a Known_Feature.

  • Vadim Zeitlin

    Vadim Zeitlin - 2013-02-04

    Sorry but how exactly is this supposed to be "known"? Is this documented somewhere? Even if it is (although I'm quite confident it wasn't at the time when I opened this bug), this behaviour is IMNSHO still very surprising, even to moderately experienced MinGW users.

  • Earnie Boyd

    Earnie Boyd - 2013-02-04

    If we make it a known_feature we will document as such. As noted in other comments this may not be wanted in all cases and having to decide in MSYS may not be the right thing to do.

  • Keith Marshall

    Keith Marshall - 2013-02-04

    Is this still an issue today? (With latest currently available GCC/binutils versions)? If still an issue, is it even within our purview to fix it? Or should it rather be directed upstream, to GCC or binutils maintainers?

    I've already "voiced" my concerns relating to "known" issues, on other tickets. There is only one valid reason for ever classifying an issue as a "known bug": it must be a duplicate report for an issue, already either dismissed, or assigned to someone who is already seeking a resolution; in such cases, you may close it as a "duplicate", or as a "known bug", and include a reference to the original ticket.

    If you're going to close it as a "known feature", (which I consider as a euphemism for a bug which you don't intend to fix), then please provide a reference to public documentation -- more visible than this bug tracker -- which conveys the knowledge, and identifies the work around.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks