Summary
"csc -deploy" does not find libchicken.dll on windows
Metadata
- Id: 706034a69e2cc27241b23cc3e31ecd96abf1ec82
- Trac id: 1054
- Type: defect
- Reporter: roti
- Owner:
- Cc:
- Status: closed
- Component: compiler
- Estimated difficulty:
- Resolution: fixed
- Priority: minor
- Milestone: 4.11.0
- Version: 4.8.x
- Changetime: 2016-01-15 09:02:45 UTC
- Created: 2013-09-27 11:48:55 UTC
- Keywords:
Description
When calling csc with "-deploy", an error occurs because libchicken.dll is not found (see example below). csc looks for the dll in %CHICKEN_PREFIX%\lib, but the file resides in %CHICKEN_PREFIX%\bin. In the example below, the environment variable CHICKEN_PREFIX is set to "C:\Program Files (x86)\Chicken Scheme".
D:\scheme>csc -deploy test.scm -o test The system cannot find the file specified. Error: shell command terminated with non-zero exit status 1: "copy /Y "C:\Program Files (x86)\Chicken Scheme\lib\libchic ken.dll" "test""
After execution, the folder "d:\scheme\test" was created and test.exe copied to it, but not libchicken.dll.
Changes and comments
[2013-12-08 18:40:24 UTC] mario changed the reporter to roti
[2014-07-30 09:04:45 UTC] sjamaan changed milestone from someday to 4.10.0
[2015-08-27 08:54:50 UTC] sjamaan changed milestone from 4.10.0 to 4.11.0
[2015-11-28 18:34:01 UTC] sjamaan wrote:
The GHC folks are also looking into this stupid problem: This blog post describes a nasty undocumented feature to allow absolute paths instead of plain DLL names, but it can't be scripted AFAICT. On the GHC wiki there's some more information on how to fix linking on Windows. The "side by side" assembly stuff sounds promising, but I haven't found any docs that are actually human-readable enough to figure out how to make use of this.
I've also read that there's application-specific DLL path support but that requires messing about with the Registry, which means installation/uninstallation is no longer simple.
So far the simplest solution seems to be to simply differentiate between bin and lib in the Scheme code, to match the way we install binaries into the system.
[2015-11-28 18:34:01 UTC] sjamaan wrote:
1448732225884818
[2015-11-28 18:51:20 UTC] sjamaan wrote:
The MSDN documentation for assemblies seems to indicate that assemblies will only work from Windows 7 onwards (search for the string "privatePath", the description under the title "probing" explains a bit).
[2015-11-28 20:25:09 UTC] sjamaan wrote:
hm, it looks like this bug has been fixed by 870c3538c04b3c6294bf850234c32e29eeb030fa. I've pinged the original bug reporter about it.
[2016-01-15 09:02:45 UTC] sjamaan changed status from new to closed
[2016-01-15 09:02:45 UTC] sjamaan set resolution to fixed
[2016-01-15 09:02:45 UTC] sjamaan wrote:
Never heard back, I'll just assume we fixed it.