[argyllcms] Re: Building Argyll CMS 1.3.2 from source under Windows 7
- From: Donald Craig <dmc@xxxxxxxxxxx>
- To: Graeme Gill <graeme@xxxxxxxxxxxxx>
- Date: Fri, 04 Feb 2011 15:07:52 -0800
Hello Graeme,
The trouble with these build battles is that as
soon as the fog of war clears, I just want to
go on with other things. I wasn't as clear as I
need to be in my documentation attempt -
plus, I forgot some stuff.
First thing is versions. The current MinGW
is dated 2010-10-30. The gcc that comes
with it is 4.5.2. This is what I was using.
On 2/3/2011 5:10 PM, Graeme Gill wrote:
Don Craig wrote:
2. Download ftjam-2.5.2.zip from
http://sourceforge.net/projects/freetype/files/ftjam/
3. Download ajam-2.5.2.zip from
http://www.argyllcms.com/ajam-2.5.2.zip
One or other is all that's required. You don't really need both,
I figured out how to build ftjam before I could figure out how to
build ajam. ajam won't build with make -f builds/win32-gcc.mk
because there's something malformed in the rule for building
jamgram.obj. Make says:
$ make -f builds/win32-gcc.mk
gcc -o jam0.exe -DNT builtins.c command.c compile.c execnt.c execunix.c
execvms.c expand.c filent.c fileos2.c fileunix.c
filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c
make.c make1.c newstr.c option.c parse.c
pathunix.c pathvms.c regexp.c rules.c scan.c search.c timestamp.c variable.c
attrib -r jambase.c
jam0
Compiler is MingW
WARNING :- no project Jamtop found, no TOP set !
Jamrules: No such file or directory
...found 158 target(s)...
...updating 31 target(s)...
Cc_ builtins.obj
Cc_ command.obj
Cc_ compile.obj
Cc_ execunix.obj
Cc_ filent.obj
Cc_ pathunix.obj
Cc_ jamgram.obj
gcc: no input files
gcc -c -o jamgram.obj -DNT -DNT
...failed Cc_ jamgram.obj ...
Cc_ expand.obj
and it goes on from there but ultimately fails without jamgram.
ftjam will build with the make command,
but ftjam won't build Argyll V1.3.2 because it needs
SubDir statements which ajam doesn't. (I think that's what's
going on. It could be something as simple as not using
the right Jambase.) However, ftjam will build ajam, after (and here's
something I forgot) the user converts all the source file newlines
back to unix. If you don't do that gcc blows up in jam.h on
lines 804/822/832/884 with "operator || has no right operand".
So after unpacking ajam from its .zip, you have to issue:
dos2unix --safe -U * ; dos2unix --safe -U builds/*
Thus the sequence is:
Download ftjam
Download ajam
Unpack 'em
Convert ajam source newlines to unix
build ftjam with make -f builds/win32-gcc.mk after setting JAM_TOOLSET
build ajam with ftjam (just type "jam install" in the ajam directory)
17. Edit numlib/numsup.c. Add:
#include<limits.h>
after line 17.
{This works, but it might break other build
environments since limits.h is now required.
It is required since otherwise PATH_MAX is
undeclared.}
MAX_PATH is in stdlib.h, which is what's included.
PATH_MAX is in limits.h, but I don't use it anywhere,
so I don't understand why you made this change.
I should have said exactly what was going on. PATH_MAX is
used in lines 117 and 123 (and 124 as text) of numsup.c
18. Edit spectro/dispwin.c. Delete the static part of the
forward declaration for int paintColor on line 2525
and for the actual declaration on line 2766. The
new versions of those lines become:
2525: int paintColor(HWND hwnd); /* Forward declaration */
2766: int paintColor(HWND hwnd) {
{Having paintColor be static causes the error message:
"invalid storage class for function 'paintColor'"
Removing static from the definition makes paintColor
a global function, but doesn't seem to cause any
other problems. I had some theories about this being
related to the ISO C99 deprecation of static functions,
but there's lots of other static function declarations
that work just fine. So I dunno...}
Hmm. static functions are standard C. Perhaps the declaration being
within the context is what's confusing it. This code is not actually
being used anymore, so I might remove it.
(I don't see the problem with the version of MingW that I have installed.)
static functions are indeed standard C, but the newish ISO
standards don't like 'em and there's now this thing called
the function visibility attribute that's supported by ELF,
but doesn't work in MinGW. I have a standard curse that
I hurl at standards bodies in cases like this, but perhaps
I'm just not modern enough.
Thank you for the response. I hope I'm clearing up
my mis-communication rather than adding to the fog.
cheers,
Don Craig
Other related posts:
