Hi,
Humm... seems I've found the source of error.
In icc34.h there are some typedefs for declaring basic types.
icUInt8Number;
icUInt16Number;
icUInt32Number;
icUInt64Number;
icInt8Number;
icInt16Number;
icInt32Number;
icInt64Number;
Rest of library does rely on these. Specially for I/O. Then, the original
icc34.h does something like this:
#ifdef __sgi
... declare proper types for SGI
#else
... use defaults **FOR MS WINDOWS**
#endif
Of course, if you are using the default icc34.h, you reverts to MS Windows
defines. This is enough to silent the compiler, but there are things, like for
example
typedef long icInt32Number;
That doesn't apply to your system, nor on many others. In such way, I did
the modification in icc34.h in order to support all those. But since tru64 wasn't
included, it was no #ifdef __tru64 or anything like it. So, here is why compiler
complained.
What we really need to know is wich sizes does have your basic types.
Do you know if is there any #defined symbol like __tru64 to tailor them?
Another thing, we should know the type sizes. I guess this small program could
give us some clues:
----cut---
#include <stdio.h>
int main(int argc, char* argv[])
{
printf("char=%d, int=%d, long=%d, short=%d\n", sizeof(char), sizeof(int),
sizeof(long), sizeof(short));
return 0;
}
---cut---
Or, better, to know if there are already defined base types like:
uint8_t
uint16_t
uint32_t
... etc..
Some platforms does have sligtly different identifiers:
u_int8_t
u_int16_t
u_int32_t
.. etc..
Some other does ones like these
__uint8_t
__uint16_t
__uint32_t
... etc..
If so, is just a matter of using these symbols to get the library working.
Regards,
Mart� Maria
The little cms project
http://www.littlecms.com
[EMAIL PROTECTED]
----- Original Message -----
From: "Philip Goisman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, April 16, 2002 12:26 PM
Subject: Re: [Lcms-user] install lcms-1.08 in tru64 unix 5.1A
> Hi,
>
> You need not apologize for anything. I'm thankful you're
> willing to work on this implementation with me.
>
> I did try the USE_BIG_ENDIAN toggle, but got the following error:
>
> OOOPPSS! You have USE_BIG_ENDIAN toggle misconfigured!
>
> Please, edit lcms.h and comment the USE_BIG_ENDIAN toggle.
> make[2]: *** [test] Error 1
>
> So the compile failed. But the liblcms.a and liblcms.so.1.0.8 libraries
> built.
>
> I thought I originally did try the gcc compiler. The problem was the icc34.h
> file with your changes for wide portability. I couldn't get past the error limit
> when compiling. The difference this time is I changed the CFLAGS
> from -g3 -O4 -fomit-frame-pointer -Wall to -lm -O2 -W. With
> the original CFLAGS, I get the following error:
>
> please wait ...
> /bin/ld:
> Warning: Unresolved:
> pow
> floor
> log
> sqrt
> frexp
> ldexp
> atan2
> cos
> sin
> hypot
> tan
> icctrans.c: In function `GetVal':
> icctrans.c:314: warning: subscript has type `char'
> icctrans.c: In function `GetDbl':
> icctrans.c:345: warning: subscript has type `char'
> testcms.c: In function `TestFixedPoint':
> testcms.c:107: warning: int format, different type arg (arg 2)
> testcms.c:112: warning: int format, different type arg (arg 2)
> testcms.c: In function `TestInducedError':
> testcms.c:857: warning: cast from pointer to integer of different size
> little cms testbed. Ver 1.08 [build Apr 16 2002 07:02:39]
>
>
> OOOPPSS! You have USE_BIG_ENDIAN toggle misconfigured!
>
> Please, edit lcms.h and comment the USE_BIG_ENDIAN toggle.
> make[2]: *** [test] Error 1
>
> Of course, that's with the new icc34.h.
> When the patch you put in icc34.h on Sep6, gave errors,
> I thought of just removing them. But with your pointer in README to
> http://www.color.org, I just went there and got the file.
>
> I did recompile using the original flags in the Makefiles. To eliminate the
> "Warning: Unresolved:" above, I put -lm at the end of the CFLAGS in
> src/Makefile. I gives 15 compile messages like
> "gcc: -lm: linker input file unused because linking not done"
> which is exactly the number of source files. But, the math functions
> warning is eliminated. I'm not sure what's right there.
>
> For completeness, I retried compiling using the native C compiler.
> I modified the CFLAGS in src, testbed, and tifficc to delete
> "-fomit-frame-pointer -Wall." Other than a lot of warnings, the results are
> the same with gcc.
> Or as follows:
>
> little cms testbed. Ver 1.08 [build Apr 16 2002 08:33:08]
>
> Testing fixed point: 2.8848960205 = 2.8848
> 0.437499269828536 = 0.4374
> Testing fixed scaling...pass.
> Testing linear interpolation ...pass. (2249910 tics)
> Testing descending tables (linear interpolation)...pass.
> Testing reverse linear interpolation
> on normal monotonic curve...pass.
> on degenerated curve ...pass.
> Testing 3D interpolation on LUT...pass.
> Testing virtual profiles (Emulating sRGB)...pass.
> lcms: Error #12288; Bad file format: 'sRGB Color Space Profile.icm'
> Testing sRGB built-in spacemake[2]: *** [test] Error 1
>
>
> To debug the function ICCFileOpen(), I would appreciate you sending the
> cmsio1.c file with the proper printf() checkpoints.
>
> Thanks again for the help,
>
> Philip
>
>
> From [EMAIL PROTECTED] Tue Apr 16 00:53:38 2002
> To: "Philip Goisman" <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]>
> Subject: Re: [Lcms-user] install lcms-1.08 in tru64 unix 5.1A
> Date: Tue, 16 Apr 2002 09:55:00 -0320
>
> Hi,
>
> > I gave your patch a try, but, as you may expect, Solaris patches
> > don't work on tru64 machines. So, I went to http://www.color.org and
> > downloaded the latest icc34.h. Then, there is a install help at
> > http://beyond.linuxfromscratch.org/view/cvs/chapter04/lcms.html which
> > I used with the following CFLAGS: -lm -O2 -W.
>
>
> Amazing. I have compared both icc34.h and are almost identical.
> Perhaps the default compiler wasn't gcc? This could explain why now
> it compiles.
>
> So far... we have done a step ahead, and if you care, we could try to
> get it working. As said tru64 was not tested, and it be nice to support
> it too. For what you are reporting, the testbed passes all tests up to
> reading real profiles. This is good, since it means all math, interpolation,
> curves, etc etc are working. It seems to fail on file I/O.
>
> The error you report could be due to several factors. One could be the
> machine endianess. I doubt this is the cause since the testbed program
> does check this. But you could give a try. This is controlled by the toggle
> USE_BIG_ENDIAN in lcms.h
>
> Other could be the alignment. lcms expects to be BYTE aligned (it handles
> alignment by its own) and this should be controlled by the #pragma pack(1)
> statements. I don't know if the gcc in tru64 does ignore alignment #pragmas.
> Anyway, the source of error is located in a check of the profile header in
> function ICCFileOpen(), in file cmsio1.c
>
> This is a trivial function, that reads a struct from the file and then compares
> signature. placing a couple of printf() could give us some clues on what is
> going wrong. If you want I can send to you the file with proper checkpoints.
>
> Sorry... I would like lcms to run out of box in your system, but right now there
> are so quantity of supported platforms that is physically impossible to me to
> check everyone. So... is thanks to people like you that we can get lcms to
> be truly cross-platform by the only feasible way: checking it on every platform.
>
> Regards,
> Mart� Maria
> The little cms project
> http://www.littlecms.com
> [EMAIL PROTECTED]
>
>
_______________________________________________
Lcms-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lcms-user
