[Rd] Fortran underscore problem persists on Linux x86/64 (PR#11206)

Thibaut Jombart jombart at biomserv.univ-lyon1.fr
Sun Apr 20 12:40:13 CEST 2008

Prof Brian Ripley wrote:

> And your machine is? -- you haven't given the 'at a minimum' 
> information asked for in the posting guide.
> Neither example is reproducible on my Fedora 8 x86_64 systems (nor in 
> the case of tripack, on CRAN's).  It will need someone with an 
> affected system to debug this.  One possibility is that they are using 
> double underscores, where the code does not look right to me -- but 
> few systems do and this code is the same as in 2.6.2.
> For the record, 'iniaqua' is a not a valid Fortran entry point, and 
> all these issues will go away if you register your package's symbols.
> What does nm -g report on the affected DSOs?
My mistake, I thought sessionInfo() would be enough. My system is an 
Ubuntu Dapper Drake (6.06.2 LTS, 64 bits version). R installed from the 
sources, same for the packages, using install.packages (one warning for 
tripack: an unmatched right brace in a manpage). My fortran and C 
compilers are respectively g77 and gcc:
 > g77 -dumpversion
GNU Fortran (GCC) 3.4.6 (Ubuntu 3.4.6-1ubuntu2)

 > gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

# This may be useful:
 > ld --version
GNU ld version 2.16.91 20060118 Debian GNU/Linux

# Your request:
 > nm -g /usr/local/lib64/R-rc/library/tripack/libs/tripack.so
0000000000001f40 T addcst_
0000000000002270 T addnod_
0000000000002820 T areap_
0000000000002890 T bdyadd_
00000000000029c0 T bnodes_
0000000000001cc0 T border_
000000000010c53c A __bss_start
0000000000002a40 T circum_
0000000000002c40 T crtri_
                 w __cxa_finalize@@GLIBC_2.2.5
0000000000002cd0 T delarc_
0000000000002eb0 T delnb_
0000000000003050 T delnod_
                 U do_fio
000000000010c53c A _edata
0000000000003910 T edge_
000000000010c568 A _end
                 U e_wsfe
000000000000a6c8 T _fini
0000000000004570 T getnp_
                 w __gmon_start__
0000000000005010 T indxcc_
0000000000001740 T inhull_
00000000000014c0 T _init
0000000000005090 T insert_
00000000000050c0 T intadd_
00000000000051f0 T intsec_
0000000000005370 T jrand_
                 w _Jv_RegisterClasses
0000000000005450 T left_
0000000000005490 T lstptr_
00000000000054c0 T nbcnt_
00000000000054e0 T nearnd_
0000000000001940 T onhull_
0000000000005910 T optim_
0000000000001d10 T qsort_
000000000000a620 T rmshnb_
000000000010c550 B stcom_
0000000000005b90 T store_
0000000000005ba0 T swap_
000000000010c560 B swpcom_
0000000000005d60 T swptst_
                 U s_wsfe
0000000000005e90 T trfind_
0000000000006730 T trlist_
0000000000006be0 T trlprt_
0000000000007080 T trmesh_
00000000000076a0 T trmshr_
0000000000009d80 T troutp_
0000000000009e80 T troutq_
0000000000008190 T trplot_
00000000000097e0 T trprnt_
0000000000009fc0 T voronoi_

I can see one single difference in the compilation logs for tripack 
using R 2.6.2 vs R-rc (2008-04-15 r45347), and the same sources:
in R 2.6.2, gcc uses the option -lgcc_s to produce the shared object, 
which is not used in R-rc. Command in R 2.6.2 is:
gcc -std=gnu99 -shared -L/usr/local/lib64 -o tripack.so inhull.o qsort.o 
tr ipack.o troutp.o troutq.o voronoi.o  
-L/usr/lib/gcc/x86_64-linux-gnu/3.4.6 -lg2c -lm -lgcc_s

I hope this helps. I'd be glad to provide more details if needed.



>> > sessionInfo()
>> R version 2.7.0 RC (2008-04-15 r45347)
>> x86_64-unknown-linux-gnu
>> locale:
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>> other attached packages:
>> [1] tripack_1.2-11
>> loaded via a namespace (and not attached):
>> [1] tools_2.7.0
>> ###
>> Best regards,
>> Thibaut.

CNRS UMR 5558 - Laboratoire de Biométrie et Biologie Evolutive
Universite Lyon 1
43 bd du 11 novembre 1918
69622 Villeurbanne Cedex
Tél. :
Fax :
jombart at biomserv.univ-lyon1.fr

More information about the R-devel mailing list