Various parts with some comments about not using CC_ and friends: # NB: we can't use the normal $(CC_) here because msvccmd.mak # adds /Za which conflicts with the lcms source. LCMS_CC=$(CC) $(CFLAGS) $(I_)$(LCMSSRCDIR)$(D)include $(LCMSCF_) put it under color for Michael for the time being - feel free to bounce it back for build process.
Seems that two files are compiled specially to break 'make so'. base/gsicc_littlecms.c base/gsicc_create.c
I think I have an idea how to fix this - probably similar to libtiff's solution (have platform-specific compiles).
fixed in r11451 - splitting the icc object target into window-specific and non-windows general builds.
reopening and assign to Michael to review the revert r11451 which requires r11460 and r11461 in ghostpdl to work. I have a 2nd thought and think that if I had been more verbose with base/bcwin32.mak, base/msvclib.mak, base/watclib.mak, base/watcw32.mak, psi/msvc32.mak, and do: +!ifndef LCMSPLATFORM +LCMSPLATFORM=win32 +!endif instead of rolling it inside LCMSSRCDIR, !ifndef LCMSSRCDIR LCMSSRCDIR=lcms +LCMSPLATFORM=win32 !endif r11461 may not be needed, but I haven't tested this idea yet. In any case, the change is to fix the "quick fix" of using "GLLCMSCC=$(CC) ..." (instead of ".. $(CC_)...") to allow for microsoft language extensions. On many kind of unix systems (and x86_64 linux in particular, but also Solaris etc for which there are a few more "make so not working" bugs), object files intended for linking into the final shared libraries needs to have a central CFLAGS (-fPIC for gcc but -KPIC for Solaris) and other machineries involving LDFLAGS, so it is best not to override the central compiler/linker flags for specific files; if it is necessary, make it explicitly platform specific as done here, and provide generic ("no override") targets for other platforms. The per-module *CC's ideally should only add includes/libraries, rather than dropping/enabling language/platform specific extensions. I hope this is clear about the intention of the patch.
We want to remove /Za from msvccmd.mak to address this issue but that uncovered a compile time problem in zlib/zutil.[ch] in visual studio 2008, visual studio 9: 1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\stdio.h(358) : error C3163: '_vsnprintf': attributes inconsistent with previous declaration 1> C:\Program Files\Microsoft Visual Studio 9.0\VC\include\stdio.h(350) : see declaration of '_vsnprintf' 1>NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\cl.EXE"' : return code '0x2' 1>Stop. 1>NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\nmake.EXE"' : return code '0x2' 1>Stop.
Created attachment 6443 [details] no_za.patch patch to disable ansi compiler option which results in the compile error in the previous comment. platform: Visual C++ 2008 Express Edition
(In reply to comment #6) > Created an attachment (id=6443) [details] > no_za.patch > > patch to disable ansi compiler option which results in the compile error in the > previous comment. platform: Visual C++ 2008 Express Edition The issue is apparently fixed in zlib 1-2.5 as follows: # if !defined(_MSC_VER) || ( defined(_MSC_VER) && _MSC_VER < 1500 ) # define vsnprintf _vsnprintf # endif
Somebody might want to have a look at r10989 of the jpx_openjpeg branch to see what it is doing with CC_WX .
We agreed, by a thin margin, to disable ansi in mscv (no_za.patch attached), to do that either a new zlib is needed or the fix in comment #7 that correctly defines vnsprintf can be used. The latter might be preferable before the release. Then the LCMS_CC compiler variable (lcms.mak) can be backed out and as Hin-Tak points out in comment #8 CC_WX should no longer be needed. Once that's done "make so" should compile okay.
Created attachment 6521 [details] patch zutil.h for vs 2008 wihtout /Za The proposed patch in comment #6, along with the patch above to zutil.h (as suggested by Henry in comment #7) work for me on both Visual Studio 2005 and Visual Studio 2008. Command line nmake and Visual Studio solution both build and run.
Unfortunately, more complex jobs do not work. Examples include Bug687845.ps as well as my example file for imagemasks painted with a Pattern colour involving an image with a SMask. For reasons I haven't investigated, these work correctly on a *release* build, but give a C stack overflow error on a debug build. While this wouldn't be a problem for customers, it makes debugging impossible on Windows. Removing the 'no_za' patch, comment #6, restores normal behaviour.
(In reply to comment #11) > For reasons I haven't investigated, these work correctly on a *release* build, > but give a C stack overflow error on a debug build. On a debug build we call fstat on the input file. This is inlined to call _fstat64i32, but this seems to be bound straight back to fstat. Pretty quickly the C stack is exhausted and we get an error. Defining __STDC__ makes the application work, but makes me rather nervous. I'm not convinced this is a good way to proceed. The msvc help does say: "__STDC__ Indicates full conformance with the ANSI C standard. Defined as the integer constant 1 only if the /Za compiler option is given and you are not compiling C++ code; otherwise is undefined. "
Created attachment 6527 [details] proposed simple solution This (attached) patch seems a much safer solution. The solution to "make so" is just the base/lib.mak change, and the base/unix-dll.mak change resolves the problems with "make sodebug".
resolved with r11538