[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mingw-cross-env-list] VENDOR in host triplet (was mingw-w64 and mingw-c
[Mingw-cross-env-list] VENDOR in host triplet (was mingw-w64 and mingw-cross-env)
Thu, 22 Mar 2012 03:29:13 +1100
On 21 March 2012 08:43, Tony Theodore <address@hidden> wrote:
> On 21 March 2012 07:24, Volker Grabsch <address@hidden> wrote:
>> I didn't ever see a build script which checks for the
>> VENDOR part of the target. However, some helper scripts
>> like config.guess might have trouble with "mingw" instead
>> of "mingw32",
> binutils doesn't recognise mingw, so we may have to stick with mingw32.
Thankfully, this failed early. I get the impression that mingw32 is
going to take a long time to change.
The VENDOR part, however, doesn't seem to be used at all. If you do:
four packages will fail(poco, qt, sdl, sdl_mixer). Three of those (qt,
sdl, sdl_mixer) will fail even if you use the canonical:
since they have TARGET variables in various makefiles that relate to
actual build targets, and the value specified at the command line
overrides the makefiles. We can get around this by simply prefixing
the target variable (MCE_TARGET in this case) or simply not worrying
about it since we're more likely to have a TARGETS (plural) variable
in the future which won't conflict with makefiles. If you change
TARGET in the main Makefile, they build without issue.
The other causes of failure are hard-coded references to
i686-pc-mingw32 in poco and qt. For poco, it's a simple make variable:
$(MAKE) -C '$(1)' -j '$(JOBS)' install CROSSENV=$(TARGET)
for qt, a sed replacement:
$(SED) -i 's,i686-pc-mingw32,$(TARGET),g'
All in all, I think we can re-purpose the VENDOR segment without any
- [Mingw-cross-env-list] VENDOR in host triplet (was mingw-w64 and mingw-cross-env),
Tony Theodore <=