Opened 14 years ago
Closed 14 years ago
#8826 closed defect (fixed)
Changeset [25856] brakes windows compilation with non default MinGW path
Reported by: | Owned by: | robertm | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | Ports - Windows | Version: | Unspecified |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
It seems that the introduction of a different source for MinGW in [25856] brakes setup for a non-default MinGW path as it seems to install in in the mingw folder in the root of the drive where win32-packager.pl is located. If I run it from D:\... it is installed in D:\mingw where I specified D:\MinGW\5.1.6\
This wrecked up my other MinGW build environment using a default installed MinGW, which is a bit of a bummer as I use that for other software.
Attachments (1)
Change History (6)
comment:1 Changed 14 years ago by
comment:2 Changed 14 years ago by
The same seems to hold for coreutils as well:
D:\mythtv\packaging\Win32\build\win32-packager.pl (5 hits) Line 351: [ archive => $sources.'coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2', Line 353: '/coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2' ] , Line 383: [ dir => $sources.'coreutils-5.97', Line 384: extract => [$sources.'coreutils-5.97-MSYS-1.0.11-snapshot.tar'] ], Line 386: shell => ["cd ".$unixsources."coreutils-5.97","cp -r * / "] ],
Perhaps we can backup the offensive changeset until properly fixed and tested as this makes building on windows rather complicated again.
comment:3 Changed 14 years ago by
Owner: | changed from Nigel to robertm |
---|---|
Status: | new → assigned |
Not backing it out, as the previous build script was 100% broken-- it only worked for people who already had all the dependencies-- will accept a patch, though.
Changed 14 years ago by
Attachment: | 8826-w32pkgr-pathfix.patch added |
---|
Fix mingw install path, zlib extraction
comment:4 Changed 14 years ago by
Patch attached to address the reported issues with MinGW path and zlib extraction. Coreutils extracts fine for me (and is unchanged from old versions of the script), so more detail is needed if you are experiencing a problem with it.
comment:5 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
It also brakes zlib extraction. Not sure why but the filenames are inconsequent:
Last reference does not seem to have the proper extension, after changing that it seems to bail out as well on the extract step.