chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Re: Chicken fails to build on Windows (mingw)


From: Fadi Moukayed
Subject: Re: [Chicken-users] Re: Chicken fails to build on Windows (mingw)
Date: Wed, 26 Aug 2009 00:34:54 +0200

Hi Felix,

Thanks, I just tested the newest trunk and it compiles fine. However, executing the install command (mingw32-make PLATFORM=mingw PREFIX=c:/chicken) fails with the following:

xcopy  chicken-setup.exe c:\\chicken\\bin
C:chicken-setup.exe
1 Datei(en) kopiert
del /f /q c:\\chicken\\lib\\chicken\\4/compiler.import.so
Ungültige Option - "compiler.import.so".

This is probably because Windows' del command doesn't like the duplicated backslash / forward slash in the middle of the path. xcopy seems to be ok with it for some reason though. Fortunately, make install/uninstall work fine after doing some minor modifications to the makefiles - like replacing all the unixish path separators in rules.make with $(SEP) (ugly, I know).

Also, there seems to be a problem with SEP in Makefile.mingw. I'm assuming that 'SEP = \\' should result in SEP having a value of '\' (due to escaping), but this doesn't seem to happen however.

I don't know whether this is useful, but I pastebin'd a diff containing the changes I made to hack(fix) the install/uninstall process here: http://pastebin.com/m51e3001f - I didn't put much effort into it though; I just hacked around the various problems until it worked :d

Regards,
Fadi.


2009/8/25 felix winkelmann <address@hidden>
On Mon, Aug 24, 2009 at 8:05 PM, Fadi Moukayed<address@hidden> wrote:
>> Hm...  how did you invoke make? Did you pass "PLATFORM=mingw"?
>
> Yes, I used the following build command, nothing special really:
>
> mingw32-make PREFIX=c:/chicken PLATFORM=mingw
> C_COMPILER_OPTIMIZATION_OPTIONS="-O2 -pipe"
>

That looks good.

> Anyway, I think I found where the problem lies: Line 86 in extras.scm
> contains this:
>
>> ;;; Random numbers:
>>
>> (cond-expand
>>  (unix
>>   ...
>>  (else
>>   ...
>
> Apparently, the C files used for bootstrapping were generated on a unix
> machine - which means that the C files will always contain the unix-specific
> code branch, unless they were regenerated on the target platform. Shouldn't
> this kind of check be done using C preprocessor instead?
>

Absolutely. I have removed this and will update the bootstrap tarball in
the next hour. Thanks for reporting this.


cheers,
felix


reply via email to

[Prev in Thread] Current Thread [Next in Thread]