[argyllcms] Re: Building Argyll CMS 1.3.2 from source under Windows 7

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 04 Feb 2011 12:10:43 +1100

Don Craig wrote:
I'm new to Argyll and wanted to try some things that needed
access to source. Building from source under Windows 7
was a sufficiently annoying process that I'm recording
it here. I think this is right, but no guarantees -
your mileage could easily vary.

Hi,
        compiling code is always annoying - stuff breaks
far too easily. One advantage of Argyll's source, is that
I've tried to eliminate dependencies on other libraries.

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,

14. Type to the shell prompt
       jam
       which should build ajam. {I'm doing this double bootstrap
       since I couldn't get ajam to build without a copy of jam
       already running. ftjam, on the other hand, builds just fine
       from scratch as instructed above.  And don't even think about
       the old jam at perforce.com.}

I'm not sure why that would be so. You should be able to build ajam
using make, since it is based on ftjam-2.5.2. The advantage
of ajam is that you can use an environment variable to tell
it which Jambase to use, rather than having to supply it on
the command line all the time.
[Maybe I'll re-create ajam, and that may make it build a bit
 more easily.]

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.

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.)

It's really, really important to be working with a clean zip archive
extraction.  If you have failed build attempts they will horse things
up in very obscure ways. I ended up deleting the source directories
and re-unzipping in order to make sure I had a clean build environment.

Normally a "jam clean" cleans everything that it knows about up,
but if you're busy fiddling with compile environment, you might
well need something more drastic.

I also tried cygwin instead of MinGW, but it looks too much like Unix,
and the Argyll build ends up not finding libXxf86vm and libXss
which are something from the bowels of the Xorg X-Windows distro.

cygwin isn't currently supported. You'd have to hack a lot of code
to make it work, since it's a weird Unix/MSWin hybrid, and there's
no point since it's much simpler to keep the MingW and MSVCC compiles
in sync.

I'm not really sure what version of MingW I currently have,
although I updated it to gcc440 at some stage, without any issues.

Graeme Gill.

Other related posts: