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 <ripley@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,                  ripley@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]]

