Thank you both for the replies. The shared library aspect didn't seem to be the problem, and while I looked into including $R_HOME/etc/Makevars in my Makefile and using variables defined there, that seemed to create other difficulties.
Instead I decided for the time being to avoid using mathematical functions in my code, and thereby skirt the problem. R CMD LINK now builds the binary successfully on both platforms. Regards, Jon On 6 July 2013 06:52, Prof Brian Ripley <rip...@stats.ox.ac.uk> wrote: > On 06/07/2013 03:19, Simon Urbanek wrote: > >> Jon, >> >> On Jul 4, 2013, at 10:52 AM, Jon Clayden wrote: >> >> Dear all, >>> >>> I have a simple front-end program which uses the APIs described in >>> section >>> 8 of "Writing R Extensions" to deviate from the standard R behaviour in >>> fairly minor ways. However, I'm having some difficulty getting it to link >>> reliably across different platforms. >>> >>> R CMD LINK seemed like it would help, but I've had difficulty finding >>> many >>> real-world examples online. I've tried >>> >>> R CMD LINK $(R CMD config CC) $(R CMD config --cppflags) $(R CMD config >>> --ldflags) -o ../bin/exec/tractor tractor.c >>> >>> and this works on one of my test platforms (OS X.8.4, R 3.0.1), but not >>> the >>> other (Ubuntu 12.04 LTS, R 2.14.1). In the latter case I get the error >>> >>> /usr/bin/ld: /tmp/ccmKf57E.o: undefined reference to symbol 'log10@ >>> @GLIBC_2.0' >>> /usr/bin/ld: note: 'log10@@GLIBC_2.0' is defined in DSO >>> /lib/i386-linux-gnu/libm.so.6 so try adding it to the linker command line >>> /lib/i386-linux-gnu/libm.so.6: could not read symbols: Invalid >>> operation >>> collect2: ld returned 1 exit status >>> >>> I can correct this by adding "-lm" manually to the command, but I'm not >>> sure how portable that will itself be. >>> >>> >> My guess would be that you did not use --enable-R-shlib when compiling R >> on Ubuntu so you don't have a shared version of the R library to link >> against (which is needed to resolve the dependencies). Could that be the >> case? >> > > I was able to reproduce this on Fedora: that is not the error if R was not > built as a shared library. > > I would simply copy how R does it (for R.bin in src/main). libtool (used > by R CMD LINK) is not coming up with the same flags. On my system R is not > using -lm: > > gcc -std=gnu99 -Wl,--export-dynamic -fopenmp -L/usr/local/lib64 -o R.bin > Rmain.o -L../../lib -lR -lRblas > > > Adding -lm is not portable (some OSes do not have a separate libm and some > always add it when linking via $(CC)), but there is a LIBM macro in > etc/Makeconf which tells you if configure found one. > > > > > Cheers, >> Simon >> >> >> Could anyone advise on the best way to make this work portably, please? >>> For >>> this application I'm not concerned about Windows compatibility - >>> portability across Unix-alikes is sufficient. The source code is at < >>> https://github.com/jonclayden/**tractor/blob/master/src/**tractor.c<https://github.com/jonclayden/tractor/blob/master/src/tractor.c>>, >>> if that >>> is useful. >>> >>> All the best, >>> Jon >>> >> > > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Professor of Applied Statistics, > http://www.stats.ox.ac.uk/~**ripley/<http://www.stats.ox.ac.uk/~ripley/> > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UK Fax: +44 1865 272595 > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
