Pasting a prior posted thread on the R-Mac list:
Ah, well, I see now that libR.dylib was not built or linked in
tools.so simply because I had not configured with --enable-R-shlib
... 'make' succeeds but only when I build R as a shared library.
The dlopen error isn't seen in the nightly builds, which also use
--enable-R-shlib. It would be good to know if others are able to
reproduce the error when configuring in the _default_ way, i.e.,
without --enable-R-shlib.
Mikael
> On 2022-02-10 4:30 pm, Mikael Jagan wrote:
>> On 2022-02-10 1:42 pm, Mikael Jagan wrote:
>> It seems my first message to mailing list, which had all of the
attachments,
>> was caught in the spam filter. In case it helps, I've dumped the
config.site,
>> config.log, and build.out on GitHub:
>>
>>
https://github.com/jaganmn/attachments/tree/6a7257014792f5e8cf7bb0bcd3bb27c7fabf7577/r-sig-mac/2022-02-10
>>
>>> On 2022-02-10 1:11 pm, Prof Brian Ripley wrote:
>>>> On 10/02/2022 17:28, Mikael Jagan wrote:
>>>> Oops - forgot to mention: I am trying to build R-devel,
currently at r81706.
>>>>
>>>> Mikael
>>>>
>>>>> On 2022-02-10 12:13 pm, Mikael Jagan wrote:
>>>>> Hello,
>>>>>
>>>>> I am running Big Sur on an M1 Mac and trying to build R
from sources.
>>>>> Some system details:
>>>>>
>>>>> R> sessionInfo()
>>>>> > Platform: aarch64-apple-darwin20 (64-bit)
>>>>> > Running under: macOS Big Sur 11.6.3
>>>>>
>>>>> $ clang --version
>>>>> > Apple clang version 13.0.0 (clang-1300.0.29.30)
>>>>> > Target: arm64-apple-darwin20.6.0
>>>>>
>>>>> $ /opt/R/arm64/gfortran/bin/gfortran --version
>>>>> > GNU Fortran (GCC) 11.0.0 20201219 (experimental)
>>>>>
>>>>> It has been a few months since I last built R on this
machine.
>>>>> At the time, I was building with LLVM clang rather than
Apple clang
>>>>> to obtain OpenMP support. I was recently nudged about the
OpenMP
>>>>> runtime library made available here:
>>>>>
>>>>> https://mac.r-project.org/openmp/
>>>>>
>>>>> which would allow me to build "normally" with
Apple clang.
>>>>> I am trying now to make the switch.
>>>>>
>>>>> I have installed all of the binaries hosted here
>>>>>
>>>>> https://mac.r-project.org/bin/darwin20/arm64/
>>>>>
>>>>> rather than those hosted here
>>>>>
>>>>> https://mac.r-project.org/libs-arm64/
>>>>>
>>>>> which I had previously installed. (Though: the first URL is
missing
>>>>> binaries for gfortran, pandoc, tcl, tk, and tkTable. I
obtained
>>>>> these from the second URL. _Both_ URLs are missing a zlib
binary,
>>>>> so I reluctantly obtained zlib from Homebrew.)
>>>
>>> zlib is part of the OS. For pkg-config you need the zlib stub
available from https://mac.r-project.org/libs-4/. That *is* in the R-admin
manual. Also, that tcl, tk, and tkTable can be installed as part of an R binary
installation.
>>
>> Thanks - I wasn't sure whether that zlib stub was suitable for my
system.
>>
>>>
>>> For pandoc I use the official Intel builds under emulation without
any problems (including checking all of CRAN). But you don't need pandoc to
build R.
>>>
>>> I understand that the transition to https://mac.r-project.org/bin
is work in progress, but its newer versions of libs are preferred.
>>>
>>>>>
>>>>> Anyway, I'm running into trouble now... I have attached
my
>>>>> config.site, config.log, and build.out (from 'make
>&') ...
>>>>> config.log seems completely normal, but in build.out I see
>>>>> many linker warnings of the form
>>>>>
>>>>> > ld: warning: could not create compact unwind for
_dchdc_: registers 72 and 73 not saved contiguously in frame
>>>>> > ld: warning: could not create compact unwind for
_dpoco_: registers 72 and 73 not saved contiguously in frame
>>>>> > ld: warning: object file
(/opt/R/arm64/lib/libreadline.a(history.o)) was built for newer macOS version
(20.0) than being linked (11.0)
>>>>> > ld: warning: object file
(/opt/R/arm64/lib/liblzma.a(liblzma_la-alone_decoder.o)) was built for newer
macOS version (20.0) than being linked (11.0)
>>>
>>> Hmm, that's about a binary liblzma. I'd download again
(maybe try both sites), and if it is still wrong, build from the sources.
>> If you search build.out, you'll find that this warning is issued
>> for _every_ binary obtained from
>>
>> https://mac.r-project.org/bin/darwin20/arm64/
>>
>> I'll try the old site again.
> Reverting to the old binaries resolves all of the version mismatch
warnings,
> so perhaps there is just a glitch in the way the new binaries were built.
>>
>>>>> And the build eventually fails for a seemingly unrelated
>>>>> reason:
>>>>>
>>>>> > clang -arch arm64 -dynamiclib
-Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module
-multiply_defined suppress -falign-functions=64 -g -O2 -Wall -pedantic
-Wno-implicit-function-declaration -flto=thin -fPIC -Wl,-mllvm,-threads=4
-L/opt/homebrew/opt/zlib/lib -L/opt/R/arm64/lib -L/usr/local/lib -lomp -o
tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o
gramLatex.o gramRd.o pdscan.o -Wl,-framework -Wl,CoreFoundation
>>>>> mkdir ../../../../library/tools/libs
>>>>> > installing 'sysdata.rda'
>>>>> > Error in dyn.load(file, DLLpath = DLLpath, ...) :
>>>>> > unable to load shared object
'/Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so':
>>>>> >
dlopen(/Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so, 6):
Symbol not found: _INTEGER
>>>>> > Referenced from:
/Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so
>>>>> > Expected in: flat namespace
>>>>> > in
/Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so
>>>>> > Error: unable to load R code in package
'tools'
>>>>> > Execution halted
>>>>>
>>>>> I've seen (and ignored) the "compact unwind"
warnings before.
>>>>> I've come across suggestions to append
'-Wl,-no_compact_unwind'
>>>>> to LDFLAGS, but it is not obvious to me that that is safe.
>>>
>>> They can be ignored: they are from the use of gfortran which does
not fully use Apple conventions.
>>>
>>>>> The warnings about macOS version mismatch are new, and
strange,
>>>>> given that 20 is my Darwin version and 11 is my macOS
version.
>>>>> I have tried all of
>>>>>
>>>>> CC=clang
>>>>> CC="clang -target arm64-apple-macos11" [copied
from an example in R-admin]
>>>>> CC="clang -arch arm64" [copied
from CRAN's Makeconf]
>>>>>
>>>>> (and similarly for CXX) to no avail. I can trick the linker
>>>>> with '-target arm64-apple-macos20' but that
doesn't seem safe
>>>>> either.
>>>
>>> But that is not the issue, which is
>>>
>>> >>
dlopen(/Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so,
>>> >> 6): Symbol not found: _INTEGER
>>>
>>> Now tools.so should require that symbol, and it is linked to
libR.dylib
>>> which supplies it:
>>>
>>> auk2% nm -g library/tools/libs/tools.so | grep _INTEGER
>>> U _INTEGER
>>>
>>> auk2% otool -L library/tools/libs/tools.so
>>> library/tools/libs/tools.so:
>>> tools.so (compatibility version 0.0.0, current version 0.0.0)
>>> libR.dylib (compatibility version 4.2.0, current version
4.2.0)
>>>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1856.105.0)
>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 1311.0.0)
>>>
>>> auk2% nm -g lib/libR | grep _INTEGER
>>> libR.dylib* libRblas.dylib* libRlapack.dylib*
>>> auk2% nm -g lib/libR.dylib | grep _INTEGER
>>> 0000000000103490 T _INTEGER
>>>
>>> which comes from
>>>
>>> auk2% nm -g src/main/memory.o | grep _INTEGER
>>> 00000000000066a8 T _INTEGER
>>>
>>> So my next step would be to investigate the building of libR.dylib.
> Indeed, my proximal problem seems to be that libR.dylib wasn't built:
> $ otool -L library/tools/libs/tools.so
> library/tools/libs/tools.so:
> tools.so (compatibility version 0.0.0, current version 0.0.0)
> /usr/local/lib/libomp.dylib (compatibility version 5.0.0, current
version 5.0.0)
>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1856.105.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1311.0.0)
> $ ls lib
> libRlapack.dylib
> I don't see any indication of problems in the build output prior to
> the loading of tools.so, so I'm not quite sure what to investigate...
> Updated files are here:
>
https://github.com/jaganmn/attachments/tree/793f2e312d217a8c3898dce46b9c5dadad9fb615/r-sig-mac/2022-02-10
Mikael
>>>
>>> BTW, if one symbol is missing likely many are -- linkers usually
only report the first one they encounter.
>>>
>>>>>
>>>>> I'd be grateful for any hints on how to get things
working,
>>>>> again.
>>>>>
>>>>> Mikael
>>>>
>>>
>>>
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Sent from my iPhone
> On May 30, 2022, at 1:56 PM, Stacey Stein via R-help <r-help at
r-project.org> wrote:
>
> ?Hi.
>
> I'm a novice programmer trying to cross-compile R 4.2.0 on my up to
date Intel Mac and get the same error about not having an updated zlib as
previously was mentioned 5 years ago:
>
> https://stat.ethz.ch/pipermail/r-help/2017-January/444162.html
>
> I have the latest zlib 1.2.12 and headers installed on my Mac and suspect
it is the same problem. Has anyone else had the same problem with compiling R
4.2.0 from source with zlib 1.2.12? Is there any work around I should I for now
go back to try and cross- compiling a previous R version from source?
>
> Thanks,
> Mike
>
> Sent from my iPad
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.