[R] Two problems compiling my shared library...

[Kort, Eric]

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}}