[news.eclipse.dsdp.rtsc] Re: xdctools and gcc / conflicting cygwin1.dll

[dave russo <d-russo@xxxxxx>]

Anthony Seely wrote:
> I noticed that xdctools_3_15_02_62 includes cygwin1.dll in it's 
> installation.
> I think that invoking 'xdc' also puts this dll ahead of any other in the 
> path.
Right, the path seen by commands invoked "under" xdc has $XDCROOT/bin at 
the front.  This directory contains a subset of cygwin sufficient for 
GNU make to use as a "unix-like shell".

The xdc command simply sets a few environment variables and exec's GNU 
make.  Gnu make then finds $XDCROOT/bin/sh.exe which it uses to invoke 
commands named in the makefiles it reads, like the compiler.  In the 
interest of efficiency, however, GNU make does _not_ use sh.exe _if_ it 
can directly execute the command.  In other words, GNU sometimes 
directly invokes commands in the makefiles and sometimes "hands them" to 
sh.exe to execute.

Why do you care?  Because commands run by sh.exe (provided with 
XDCtools) must either be native Windows executables or cygwin 
executables _that are compatible_ with the version of cygwin used to 
build sh.exe.

> Issue I'm having is as follows:
>  a) built an arm-none-eabi-gcc cross compiler under cygwin, with a recent
>     cygwin install.  (dll is 1005.25.0.0).  b) in the same directory 
> where I would invoke xdc, I can execute     'arm-none-eabi-gcc 
> -dumpversion' and get a correct result (4.4.0)
>  c) invoking 'xdc' does the same thing as an initial step, but an error
>     'entry point __getreent could not be located in the dynamic link 
> library
>      cygwin1.dll pops up'.
If GNU make uses sh.exe to run your compiler
   1. sh.exe loads the old cygwin1.dll it requires from $XDCROOT/bin
   2. sh.exe then executes your compiler that requires a newer
      cygwin1.dll with __getreent (which is not present in the old
      cygwin1.dll)

If GNU make runs your compiler directly (via Windows CreateProcess)
   1. Windows loads your compiler which requires cygwin1.dll
   2. cygwin1.dll is searched for in the compiler's directory, various
      Windows directories, and then along the PATH
   3. since xdc places an old cygwin1.dll at the front of the path,
      if your cygwin1.dll is not found, the an old one will be

>  d) copying over the newer dll that I built gcc against
>     version 1005.25.0.0 - on top of the xdctools_3_15_02_62     version 
> 1003.12.0.0 seems to correct the issue.
This may fix the compiler but sh.exe will probably have problems.

>     (although I am running into other issues that appear unrelated;
>      so I can't say for sure this works as a workaround)
I suspect the "unrelated" problems are in fact related to sh.exe not 
loading a compatible cygwin1.dll.  Many things will work since GNU make 
is trying not to use sh.exe whenever possible.

For this reason, we've always wanted to remove our dependence on cygwin :(

> It seems like installing a local cygwin1.dll and putting it first in the 
> path
> is a bad idea for xdc if the local dll is older.  but I could see the 
> opposite
> case being true - where there is an older dll somewhere in the system.
>
> Is there a way to modify xdc so that this conflict is avoided?
The root of the problem is that, if a cygwin sh.exe invokes a 
cygwin-based compiler, both sh.exe and the compiler must be able to use 
a single compatible cygwin1.dll.

There are a few possibilities, but none are very attractive:
    1. remove sh.exe from XDCtools (and use native Windows ports of
       rm, cp, ...)
    2. replace cygwin sh.exe with MSYS sh.exe (or some other shell)
    3. write the target to generate commands that GNU make will invoke
       directly (which avoids the incompatibility between sh.exe and a
       cygwin-based compiler).

If we remove sh.exe from XDCtools, the behavior of XDCtools will depend 
on the user's choice of shell.  Unfortunately on Windows, the behavior 
of shells varies widely.  There are very few open source posix shells 
for Windows.

We are currently looking into using MSYS in-lieu of cygwin, but there 
appear to be some performance and compatibility issues with this 
approach.

In the near-term the only workaround is option 3.  You can try placing 
your new cygwin1.dll in the compiler's directory (or one of the other 
places Windows looks for dlls before PATH: 
http://msdn.microsoft.com/en-us/library/7d83bc18%28VS.80%29.aspx).  So 
_if_ GNU make invokes the compiler directly it will not conflict with 
sh.exe.  You can see what GNU make is doing by invoking xdc with the 
'-d' option.

If this works, we can fix xdc to place $XDCROOT/bin at the end of the 
path rather than at the beginning.  But _if_ GNU make ever runs the 
compiler via sh.exe, the problem will be back.