Home » Archived » DSDP - Real-Time Software Components (RTSC) » xdctools and gcc / conflicting cygwin1.dll versions
| xdctools and gcc / conflicting cygwin1.dll versions [message #478784] |
Thu, 06 August 2009 21:14  |
Eclipse User |
|
|
|
Originally posted by: a-seely.ti.com
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.
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'.
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.
(although I am running into other issues that appear unrelated;
so I can't say for sure this works as a workaround)
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?
|
|
|
| Re: xdctools and gcc / conflicting cygwin1.dll versions [message #479426 is a reply to message #478784] |
Tue, 11 August 2009 00:36  |
 Dave Russo
Messages: 172
Registered: July 2009 |
Senior Member |
|
|
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.
|
|
|
| Re: xdctools and gcc / conflicting cygwin1.dll versions [message #481081 is a reply to message #479426] |
Wed, 19 August 2009 14:44 |
| Eclipse User |
|
|
|
Originally posted by: a-seely.ti.com
dave russo wrote:
> 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
Hi David, I believe the latter option (running directly through windows
CreateProcess) is what was happening. It was a while ago but I remember
looking up CreateProcess. The problem with this is the compiler doesn't
work with the older cygwin1.dll.
>> 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.
So far - no issues I can attribute or even suspect to be a shell problem.
[I was having really unrelated issues - like going up a learning curve to
build gcc / newlib for a big-endian thumb2 arm target]
> 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).
Is another way propose option 2: If the user has already installed cygwin
then don't install a local copy in the xdc install directory?
I might try later simply deleting or renaming the cygwin tools under the
XDC install to simulate this - and seeing if everything will work properly
from the full cygwin install I have on the machine.
This does seem to be a problem especially on windows. I've run into this
with other combinations of tool chains that install different snapshots
of cygwin.
> 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.
Yes! The above tip is a really good one and someone else just turned me
onto it the other day. I've been pretty 'frustrated' by the lack of
visibility using xdc - until someone pointed out that you can pass through
all the usual make options. *Now* I know this tip is in the xdc
documentation
as well - but of course I'm I haven't read it fully.
That's a good one to put on a TIPs or FAQ page.
> 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.
|
|
|
Goto Forum:
Current Time: Thu Apr 18 09:19:47 GMT 2024
Powered by FUDForum. Page generated in 0.01636 seconds |
] 
Search
Help
Register
Login
Home
