Re: ITA: gcc-mingw-* gcc-3 -mno-cygwin support packages; ITP: mingw-binutils/mingw-gcc-* cross compiler

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

On 11/23/2010 6:32 PM, Peter Rosin wrote:
> Would it be possible to have a postinstall script for one of the new
> packages that includes the awkward fixups? That way automatic fixup is
> possible if you just reinstall the appropriate package, which seems
> simple to support?

The problem is, because the symlinks already exist (thanks to the OLD
gcc-mingw- packages), they can screw up unpacking the *new* files --
redirecting them from their intended location in the new scheme under
/usr/i686-pc-mingw32, and into the OLD location under /usr/lib/

So, somehow, you have to *remove* the symlinks *before* you unpack the
packages that need from them to be removed.  You can't do that in a
"postinstall" script of the same package -- because by the time you get
to the postinstall script, you've already unpacked the files...into the
"bad" place.

The same is true when you want to use symlinks to re-direct files in the
first place -- this is why both the old and the new gcc-mingw- packages
used the very odd "unpack the REAL tarball from a postinstall script"
mechanism.

Now, maybe I'm wrong about this, and setup.exe itself will be fine with
unpacking the tarballs and will ignore the "lib.lnk" symlinks.  But even
if it WERE capable of doing that, then I'd have a directory with the
following contents;

   lib.lnk
   lib/
   bin.lnk
   bin/
   include.lnk
   include/

I'm not sure how a cygwin bash shell will treat those elements;
supposing you were to create such a dir structure, how do you then rm
the symlinks without affecting the dirs, since as far as bash is aware,
the contents are;

   lib@
   lib/
   bin@
   bin/
   include@
   include/

It's a nightmare, honestly.

--
Chuck