[PATCH] PE direct linking to dlls, accept any filename.

[Pedro Alves]

Danny Smith wrote:
 >
 > Pedro Alves
 > Tuesday, 19 December 2006 12:47 a.m.
 >>
 >>Danny Smith wrote:
 >>
 >>
 >>>Could you add a test for symlinks (on cygwin), eg where
 >>
 >>
 >>
 >>I've added tests for symlinks.  Should I guard them for MinGW?  How?
 >>The symlink functionality comes from the host not from the target.
 >>Using msys or 'gcc -mno-cygwin' should work, no?
 >>
 >
 >
 > Mingw-hosted ld.exe (whether in  msys env  or built with -mno-cygwin,
 > depends on MS msvcrt.dll,
 > which has not a clue about cygwin symlinks. Cygwin-hosted ld.exe depends
 > on cygwin1.dll so does recognize symlinks.
 >
 >

I understand that.  What I was missing, was the fact that you probably
are using cygwin to drive dejagnu, but building with
--host=i686-pc-mingw32.
Well, I tried doing the same and this is what I came up with.

First, I tried puting c:/MinGW first on the PATH, and then building with
configure --host=i686-pc-mingw32 --target=i686-pc-mingw32.  That has
the problem that absolute paths won't match between cygwin and MinGW, so
I came up with the scripts in the attached cygming_wrappers.tar.gz.
They are wrappers around gcc, g++, gas and ld, which will do the path
translation using cygpath.  Works pretty well, but to run the testsuite,
we would need the mingw.exp --host_board file attached.  It was only after
doing this, that I realized that MinGW understands the /mingw path, so
if I do a /mingw mount on cygwin, the paths will match in both environments.
Next, I put the binutils sources under /mingw/src, and I don't need the
scripts anymore. :) Talk about overengineering. :)
Well, the scripts are still useful, me thinks, because they allow me to
build MinGW stuff even when the sources are not under /mingw.  It is
just for the testsuite that they become a nuisance.  So, I attached
them anyway since someone may find them useful.  (Of course, they are
a proof of concept, so don't expect them to be complete, or even fully correct.
But, they did build binutils.  )

Now back to the /mingw mount mode.

I now see the problem you where seing.  Cygwin's ln -s puts a symlink
under tmpdir/ld, but the mingw/msvcrt ld doesn't understand it.  To
me this sounds clearly as a "if I do this, then it breaks. Then don't"
do it!" case.  I solved it in two ways.  One without any changes to
binutils whatsoever, and another one with a testsuite patch.

-  The first solution was to devise an "ln" wrapper script, that filters
out "-s | --symlink" and converts a symlink request into a hardlink,
which resolves to a copy on Windows.  This makes cygwin's ln look like
msys ln.  This works pretty well, and doesn't need any change in
binutils, but it is awkward to have to remember to put that script on
the PATH.

- The second solution is to change a bit the testsuite to detect
when we are building a mingw target under cygwin.  That is implemented
in the diff attached.  I only implemented it in ld, but if this is
wanted I can provide patches for the rest of the testsuites.

What do you guys think?  Both versions of the "ln -s" fix look ugly, but
I would rather go the with the testsuite fix.

Cheers,
Pedro Alves

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygming_wrappers.tar.gz
Type: application/gzip
Size: 1435 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20061221/1743cfd7/attachment.gz>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ln
URL: <https://sourceware.org/pipermail/binutils/attachments/20061221/1743cfd7/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: binutils_mingw_ln.diff
URL: <https://sourceware.org/pipermail/binutils/attachments/20061221/1743cfd7/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mingw.exp
URL: <https://sourceware.org/pipermail/binutils/attachments/20061221/1743cfd7/attachment-0002.ksh>