For what it is worth, GitHub turned it into an email, I posted at the site at #1 which is also how your emailed reply got to me. Let me know if I can help -- this should be straightforward.

This is a linker error

clang++-19 -std=gnu++17 -shared -L/home/hornik/tmp/R/lib -Wl,-O1 -o glamlasso.so RcppExports.o rcppfunc.o -L/home/hornik/tmp/R/lib -lR
installing to /srv/hornik/tmp/CRAN_pretest/glamlasso.Rcheck/00LOCK-glamlasso/00new/glamlasso/libs
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘glamlasso’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/srv/hornik/tmp/CRAN_pretest/glamlasso.Rcheck/00LOCK-glamlasso/00new/glamlasso/libs/glamlasso.so':
  /srv/hornik/tmp/CRAN_pretest/glamlasso.Rcheck/00LOCK-glamlasso/00new/glamlasso/libs/glamlasso.so: undefined symbol: dsyev_
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/srv/hornik/tmp/CRAN_pretest/glamlasso.Rcheck/glamlasso’

is a linking error, meaning the build requires (LAPACK/BLAS) function dsyev (the underscore is IIRC Fortran related for historical reasons) but is not finding it on this machine.

Now, when we look into the corresponding Windows build, it works so it is likely not R. Comparing Windows

g++ -std=gnu++17 -shared -s -static-libgcc -o glamlasso.dll tmp.def RcppExports.o rcppfunc.o -fopenmp -LD:/RCompile/recent/R/bin/x64 -lRlapack -LD:/RCompile/recent/R/bin/x64 -lRblas -lgfortran -lquadmath -Ld:/rtools45/x86_64-w64-mingw32.static.posix/lib/x64 -Ld:/rtools45/x86_64-w64-mingw32.static.posix/lib -LD:/RCompile/recent/R/bin/x64 -lR
installing to d:/RCompile/CRANincoming/R-devel/lib/00LOCK-glamlasso/00new/glamlasso/libs/x64

to the above we that _on Windows you correctly linked with -fopenmp -LD:/RCompile/recent/R/bin/x64 -lRlapack -LD:/RCompile/recent/R/bin/x64 -lRblas -lgfortran -lquadmath whereas on Unix you did not -- in the first line quoted above you did specify these library. So it looks like you messed up file src/Makevars.

On the machine I prepared the patch on I have src/Makevars as it should be:

PKG_CXXFLAGS = $(SHLIB_OPENMP_CXXFLAGS) 
PKG_LIBS = $(SHLIB_OPENMP_CXXFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

What do you have?

Please explain how you "have the file" yet the link instructions do not use it:

using C++ compiler: ‘Debian clang version 19.1.7 (7)’
clang++-19 -std=gnu++17 -I"/home/hornik/tmp/R/include" -DNDEBUG  -I'/home/hornik/lib/R/Library/4.6/x86_64-linux-gnu/Rcpp/include' -I'/home/hornik/lib/R/Library/4.6/x86_64-linux-gnu/RcppArmadillo/include' -I/usr/local/include -DUSE_TYPE_CHECKING_STRICT -D_FORTIFY_SOURCE=3   -fpic  -g -O3 -Wall -pedantic -Wno-missing-template-arg-list-after-template-kw -Wdeprecated-literal-operator  -c RcppExports.cpp -o RcppExports.o
clang++-19 -std=gnu++17 -I"/home/hornik/tmp/R/include" -DNDEBUG  -I'/home/hornik/lib/R/Library/4.6/x86_64-linux-gnu/Rcpp/include' -I'/home/hornik/lib/R/Library/4.6/x86_64-linux-gnu/RcppArmadillo/include' -I/usr/local/include -DUSE_TYPE_CHECKING_STRICT -D_FORTIFY_SOURCE=3   -fpic  -g -O3 -Wall -pedantic -Wno-missing-template-arg-list-after-template-kw -Wdeprecated-literal-operator  -c rcppfunc.cpp -o rcppfunc.o
clang++-19 -std=gnu++17 -shared -L/home/hornik/tmp/R/lib -Wl,-O1 -o glamlasso.so RcppExports.o rcppfunc.o -L/home/hornik/tmp/R/lib -lR
installing to /srv/hornik/tmp/CRAN_pretest/glamlasso.Rcheck/00LOCK-glamlasso/00new/glamlasso/libs

This compiles two source files RcppExports.cpp and rcppfunc.cpp into their object files and then links those but not the required libraries into the shared package library. Which then fails as Armadillo does need LAPACK and BLAS etc.

Contrast with any other package, you will see that these do link. You do not supply me with current sources so there is not anything more I can offer. But the log analysis is conclusive.

Maybe start from with the token (working !!) demo you get from RcppArmadillo.package.skeleton("temppkg") and see where things differ.

PS Check for simple things. Maybe it slipped into .Rbuildignore? Does the tar.gz created by R CMD build really have it?

Sorry my bad: between going for run, returning, shower, breakfast I overlooked that I have your files (if they are current...) in this repo so I will take another (closer) look in a bit.

Well, ball in your court. The PR worked under Linux when I made it, so maybe brew a good cup of coffee or tea and carefully compare to a working reference, e.g. from the skeleton generator. Having CI can help too, see e g. my r-ci setup or other helpers. I can assist if need be

Given that I made a PR, I had a fork so I just checked that out (locally) and made minimal (but hopefully "helpful" changes):

• commit b5ff944 turns on continouous integrations, you can see the result with success for macos and ubuntu here

• commit 0840ddc removes a few files that should not be in a repo: the .DS_store files macos creates, and the compilation results

• commit 0998ecc is more of a test for me where the ubuntu test is now done twice with the second (faster!) variant in an r2u-based container to avoid a slower-these-days setup step; you can ignore this it is a change I will release to my r-ci setup 'soon'

PS Also see this blog post from yesterday and the corresponding email to the r-package-devel list -- I can offer help in informal 'office hours' over zoom or google meet. Looks like you have a few more packages with the same issue. This may be dealt with most easily over a screen share...

could be an idea. however, ive now updated this repo after struggling with the 2fa and ssh and the terminal for a bit. now the repo is exactly as the source committed to cran.

also thank you very much for your help! and the bit above i wrote about .win ending is probably not really correct

Excellent. That is a very good first step. The (single, easy to view) commit you made clearly states what is at fault:

You deleted src/Makevars (not src/Makevars.win) and without it it only builds with the errors I described / you experienced at CRAN under Debian (standing in for all Linux systems).

You can tests build under Linux or macos. Either via GitHub actions, or for example by uploading to mac builder. If you try that with the tarball missing src/Makevars you will almost surelt see the same failure.

You can also study the commits I made today, one by one. Two of them give / refine 'GitHub Actions' which will build for you. It will most likely also fail without src/Makevars but should work with it. Maybe give it a try?

well i have submitted it to rhub and tested it on 31 systems using actions and it seemed to work. here is the various submits to rhub.

https://github.com/r-hub2/hillocked-disguisable-eel-glamlasso/actions

Can you do me a favour and do R CMD build ... (or whatever equivalent command you use) and then tar tvfz glamlasso*tar.gz | grep src/ ?

That it builds on some systems at RHub is no guarantee that it will build an all systems. Some Unix systems can be configured to have an R build with the implicit Rlapack, in that case the linker instructions are not needed. But others are not and you will still fail here. I can demonstrate that to you by opening another branch in my git checkout and remove src/Makevars there. I just did that in eddelbuettel@deff050 and (some of) the builds then fails as can be seen at the actions page which also shows all the previous one succeeding. That macOS still builds in this CI run does not mean it will now work in Vienna on the Debian machine. You just have to take my word on this, and I feel I have been repeating myself here for a while.

You also do not have to take my word for it, Writing R Extension (with 37 mentions of src/Makevars) and other documentation will be equally clear.

And again it is right here:

You deleted src/Makevars and that is not a good idea, even if you may still build on your macOS machine. That is the very crux of the matter. Maybe sleep it over for a night or two, look at some other packages you know and trust (it is such a resource to have these 22k CRAN packages to look at) and maybe revisit in a day or two.

(PS You should actually delete files .DS_Store and files *.o and *.so.)

thats is exacty right; following popper we should avoid induction like that. however following the r guidelines is does show that the package is likely good on a "majority" of platforms as its formulated somewhere on cran and that the contributor has made sure that is the case as best as possible

One last time: No.

But I said my piece, and I will leave this thread now. They will throw your package off CRAN as it will not build on those (perfectly valid and very common) systems that have an external LAPACK installation -- which R 4.5.* and later make the default / preference anyway e.g. stated in doc/NEWS in r-devel:

BLAS and LAPACK:

• The bundled BLAS and LAPACK sources have been updated to those
shipped as part of January 2025's LAPACK 3.12.1.

• It is intended that this will be the last update to BLAS and
LAPACK in the R sources. Those building R from source are
encouraged to use external BLAS and LAPACK and this will be
required in future.

no to what? the makevars file is there. the fault is still there. it can build on some systems and not on others but again on all but one of the systems used via rhub. i cant test on every personal computer on the planet can i?

the makevars file is there.

It is not. As I demonstrated here by screenshot, and here by showing your own commit deleting it.

Your initial and basic error on the CRAN Debian machine configured with an external LAPACK and BLAS is a link error "missing symbol" which is due to the fact that you removed the very linker instructions by removing src/Makevars. -- Which can be seen in all the link lines I pointed you too -- -- which can be seen in all the link lines I pointed you too --

The fact that it "works on some systems" (which have R with Rlapack) does not mean it works on others. But don't listen to me, maybe just use the CRAN mirror here at GitHub and view some of the 1200+ packages uses RcppArmadillo. I do think that you will not find another one among these without a src/Makevars.

But "peace out" -- I did not come here to argue. If any of the help I offered here upsets you, feel free to ignore it. Your package is currently broken, and that is simply more of an issue to you than it is to me so I will leave you to it.

right, but you really should look at the directory before posting..

thats the makevars file right there.

as explained above in simple terms the checks cannot be carried out on my mac or the rhub mac without the .win designation on that file. with no makevars.win the checks are not succesful on win systems. should be easy enough to understand.

further if you are able to parse the info in this link https://github.com/r-hub2/hillocked-disguisable-eel-glamlasso/actions you should also understand that on a majority of systems -including linux contratry to what you say above- the package passes checks.

Please look again, the file src/Makevars.win is there. It is used only on Windows. The file src/Makevars is missing as I said.

On the other hand you correctly and as needed have a file src/Makevars in your other repositories:

• https://github.com/adam-lund/FRESHD/blob/main/src/Makevars
• https://github.com/adam-lund/SMME/blob/master/src/Makevars
• https://github.com/adam-lund/dynamo/blob/master/src/Makevars

(If a Makevars is present but not Makevars.win, the latter is implied. The reverse is not true: you cannot use a Makevars.win outside of Windows. See below.)

with no makevars.win the checks are not succesful on win systems. should be easy enough to understand.

You never shared the error, nor did you let me reproduce it. Whereas I showed you working macos builds in CI at GH when a Makevars is there.

On the other hand I showed a successful CI run on macos and linux when both Makevars.win and Makevars are present (plus two more). I explained to you how when a Linux system is optionally configured to have libRlapack.so from R it can get by. But the other systems will fail. I demonstrated how it fails when Makevars is removed in a branch and its actions. I can reproduce this on my system (using an external LAPACK).

So we continue to talk past each other. Which is not a problem per se, but it won't correct your package and will continue to fail on the Debian Linux machine in Vienna (and every other machine with external LAPACK) as its setup differs from all your other packages.

It is as I said.

If I upload your current repo state to the R Project 'mac builder' I get (full build logs here)

clang++ -arch arm64 -std=gnu++17 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -L/Library/Frameworks/R.framework/Resources/lib -L/opt/R/arm64/lib -o glamlasso.so RcppExports.o init.o rcppfunc.o -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/lib -lRblas -L/opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/14.2.0 -L/opt/gfortran/lib -lemutls_w -lheapt_w -lgfortran -lquadmath -F/Library/Frameworks/R.framework/.. -framework R
ld: warning: could not create compact unwind for _allocate_tramp_ctrl: does not use standard frame
ld: warning: could not create compact unwind for ___gcc_nested_func_ptr_created: does not use standard frame
ld: warning: could not create compact unwind for ___gcc_nested_func_ptr_deleted: does not use standard frame
ld: warning: could not create compact unwind for ___emutls_get_address: does not use standard frame
installing to /Volumes/PkgBuild/work/1760267406-5ee272bb82e94a9b/packages/big-sur-arm64/results/4.5/glamlasso.Rcheck/00LOCK-glamlasso/00new/glamlasso/libs
** generating debug symbols (dSYM)

Note that it succeeds (with warnings) as it **clearly uses -Rlapack just as I said all along.

When I add the missing Makevars and try again, log here (using version 3.0.4.1 to differentiate) it passes the same way (as these variables in the Makevars (and Makevars.win) are filled in by the local R configuration)

clang++ -arch arm64 -std=gnu++17 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -L/Library/Frameworks/R.framework/Resources/lib -L/opt/R/arm64/lib -o glamlasso.so RcppExports.o rcppfunc.o -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/lib -lRblas -L/opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/14.2.0 -L/opt/gfortran/lib -lemutls_w -lheapt_w -lgfortran -lquadmath -F/Library/Frameworks/R.framework/.. -framework R
ld: warning: could not create compact unwind for ___emutls_get_address: does not use standard frame
ld: warning: could not create compact unwind for _allocate_tramp_ctrl: does not use standard frame
ld: warning: could not create compact unwind for ___gcc_nested_func_ptr_created: does not use standard frame
ld: warning: could not create compact unwind for ___gcc_nested_func_ptr_deleted: does not use standard frame
installing to /Volumes/PkgBuild/work/1760267807-72028d7a599ed1c0/packages/big-sur-arm64/results/4.5/glamlasso.Rcheck/00LOCK-glamlasso/00new/glamlasso/libs
** generating debug symbols (dSYM)

so adding a src Makevars does no damage to systems with libRlapack.

On the other hand, using a local container without libRlapack but external LAPACK as in Vienna where you failed leads to your 3.0.4 failing with the exact same error as I have been saying all along

root@e9d96f4172e4:/work# R CMD INSTALL glamlasso_3.0.4.tar.gz 
* installing to library ‘/usr/local/lib/R/site-library’
* installing *source* package ‘glamlasso’ ...
** this is package ‘glamlasso’ version ‘3.0.4’
** using staged installation
** libs
using C++ compiler: ‘g++ (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0’
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG  -I'/usr/lib/R/site-library/Rcpp/include' -I'/usr/lib/R/site-library/RcppArmadillo/include'     -fpic  -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/r-base-wwoKA3/r-base-4.5.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/r-base-wwoKA3/r-base-4.5.1=/usr/src/r-base-4.5.1-1.2404.0 -Wdate-time -D_FORTIFY_SOURCE=3   -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG  -I'/usr/lib/R/site-library/Rcpp/include' -I'/usr/lib/R/site-library/RcppArmadillo/include'     -fpic  -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/r-base-wwoKA3/r-base-4.5.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/r-base-wwoKA3/r-base-4.5.1=/usr/src/r-base-4.5.1-1.2404.0 -Wdate-time -D_FORTIFY_SOURCE=3   -c rcppfunc.cpp -o rcppfunc.o
g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -o glamlasso.so RcppExports.o rcppfunc.o -L/usr/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/00LOCK-glamlasso/00new/glamlasso/libs
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘glamlasso’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/usr/local/lib/R/site-library/00LOCK-glamlasso/00new/glamlasso/libs/glamlasso.so':
  /usr/local/lib/R/site-library/00LOCK-glamlasso/00new/glamlasso/libs/glamlasso.so: undefined symbol: dsyev_
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/usr/local/lib/R/site-library/glamlasso’
* restoring previous ‘/usr/local/lib/R/site-library/glamlasso’
root@e9d96f4172e4:/work# 

but the 3.0.4.1 with a src/Makevars building (and note the -fopenmp -llapack -lblas -lgfortran in the link line)

root@e9d96f4172e4:/work# R CMD INSTALL glamlasso_3.0.4.1.tar.gz 
* installing to library ‘/usr/local/lib/R/site-library’
* installing *source* package ‘glamlasso’ ...
** this is package ‘glamlasso’ version ‘3.0.4.1’
** using staged installation
** libs
using C++ compiler: ‘g++ (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0’
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG  -I'/usr/lib/R/site-library/Rcpp/include' -I'/usr/lib/R/site-library/RcppArmadillo/include'    -fopenmp  -fpic  -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/r-base-wwoKA3/r-base-4.5.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/r-base-wwoKA3/r-base-4.5.1=/usr/src/r-base-4.5.1-1.2404.0 -Wdate-time -D_FORTIFY_SOURCE=3   -c RcppExports.cpp -o RcppExports.o
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG  -I'/usr/lib/R/site-library/Rcpp/include' -I'/usr/lib/R/site-library/RcppArmadillo/include'    -fopenmp  -fpic  -g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffile-prefix-map=/build/r-base-wwoKA3/r-base-4.5.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -fdebug-prefix-map=/build/r-base-wwoKA3/r-base-4.5.1=/usr/src/r-base-4.5.1-1.2404.0 -Wdate-time -D_FORTIFY_SOURCE=3   -c rcppfunc.cpp -o rcppfunc.o
g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -o glamlasso.so RcppExports.o rcppfunc.o -fopenmp -llapack -lblas -lgfortran -lm -lquadmath -L/usr/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/00LOCK-glamlasso/00new/glamlasso/libs
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (glamlasso)
root@e9d96f4172e4:/work# 

So in sum

• without src/Makevars build on some systems and fails on others
• with src/Makevars builds on all

and the difference is the internal-vs-external LAPACK configuration R systems may have. For the latter RcppArmadillo has providng a working src/Makevars since Day 1. You deleted it, and thereby rendered your package less portable. No more, no less. Just add src/Makevars back in (as you do in your other packages) and all is good.

yes again with makevars file without win it doesnt build on my local but have pushed a version with both makevars to the github now.