Since requests keep trickling in, I have finally gotten around to polishing my rtiff package for R. This package will read TIFF images into a pixmap for subsequent processing. However, I am encountering a couple problems with compiling the shared library. 1. On windows (R 2.2.0): R CMD INSTALL successfully compiles a dll, but the dll has no entry points (as revealed by nm rtiff.dll), leading to "C entry point ... not in load table" errors when I try to use the library. Here is how R CMD INSTALL built the dll: -------8<-------------------------------------------------------------- MkRules:143: warning: ignoring old commands for target `.c.o' making rtiff.d from rtiff.c g++ -Ic:/usr/include -Wall -O2 -c rtiff.c -o rtiff.o rtiff.c: In function `void reduce(int*, int*, int*, int*, double*)': rtiff.c:138: warning: converting to `int' from `double' rtiff.c:139: warning: converting to `int' from `double' ar cr rtiff.a rtiff.o ranlib rtiff.a windres --include-dir c:/usr/include -i rtiff_res.rc -o rtiff_res.o gcc --shared -s -o rtiff.dll rtiff.def rtiff.a rtiff_res.o -Lc:/usr/src/gnuwin32 -ltiff -lg2c -lR ... DLL made -------8<-------------------------------------------------------------- However, if I simply do the following: gcc -shared -o rtiff.dll rtiff.c -ltiff I get a functional shared library. Any clues as to why R CMD INSTALL is resulting in an entry-pointless dll? (And couldn't the shared library compilation be greatly simplified as I have demonstrated above?) 2. On (ubuntu) Linux (R 2.1.0): R CMD INSTALL results in an rtiff.so that crashes with a segmentation fault. Again, gcc -shared -o rtiff.so rtiff.c -ltiff results in a function shared library. Here, I have traced the problem to the -O2 flag with which R was compiled. If I "hand compile" with the -O2 flag, I get the segmentation fault back. A search of the internet suggests this is likely a GCC bug, which perhaps I could patch, but I don't want to expect potential users of my library to have to patch their GCC. So...can I eliminate the -O2 option via Makevars somehow, or do I need my own custom Makefile to get around this? Thank you, Eric This email message, including any attachments, is for the so...{{dropped}}