Add recipe for r-sweater

[rgaiacs]

Follow up from #4298 targeting emscripten-4x branch.

The rule is failing due to

Error:   × Failed to resolve dependencies: Cannot solve the request because of: No candidates were found for cpp_emscripten-wasm32 *.
  │ 
  ╰─▶ Cannot solve the request because of: No candidates were found for cpp_emscripten-wasm32 *.

Help wanted. Thanks!

[IsabelParedes]

r-liblinear requires compilation, so you'll need to add a recipe for r-liblinear as well.

[IsabelParedes]

And another recipe for r-quanteda which will need a recipe for r-snowballc

Welcome to dependency hell! 😂

[rgaiacs]

Welcome to dependency hell!

Should the dependencies be resolved in their own pull request? Or can all the dependencies be bundled in this pull request?

[IsabelParedes]

Welcome to dependency hell!

Should the dependencies be resolved in their own pull request? Or can all the dependencies be bundled in this pull request?

You can add them all in this pull request and rattler-build should build them in the correct order.

[IsabelParedes]

Just a heads up, I just renamed the branches so emcripten-4x became main. Your PR is correct, no need to do anything.

[rgaiacs]

Regarding the r-liblinear, it is a wrapper around the LIBLINEAR C/C++ library. The LIBLINEAR C/C++ library must be package as it own, right?

When do I need to patch the C/C++ library?

[IsabelParedes]

Regarding the r-liblinear, it is a wrapper around the LIBLINEAR C/C++ library. The LIBLINEAR C/C++ library must be package as it own, right?

When do I need to patch the C/C++ library?

I don't think you need to. The conda-forge recipe for r-liblinear does not list an additional liblinear package.

Btw, could you rebase or merge the changes from main? That way I could check the build logs

[rgaiacs]

Btw, could you rebase or merge the changes from main? That way I could check the build logs

Done. Thanks for the help!

[rgaiacs]

@IsabelParedes The build is failing because it request the file

https://cran.r-project.org/src/contrib/snowballc_0.7.1.tar.gz

instead of

https://cran.r-project.org/src/contrib/SnowballC_0.7.1.tar.gz

Note the different case. What is the correct way to handle this case? Thanks!

[rgaiacs]

The CI for 7ff1aea reported another missing library (r-fastmatch).

The CI for aeaf6a1 reported some cross-compilation error.

Running build script
* installing *source* package ‘fastmatch’ ...
** this is package ‘fastmatch’ version ‘1.1-8’
** package ‘fastmatch’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
shared:INFO: (Emscripten: Running sanity checks)
using C compiler: ‘emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.9 (bbf1caa6e24f64fca9eb6a13a9e02d3f42123e77)’
emcc -I"$BUILD_PREFIX/lib/R/include" -DNDEBUG   -Oz -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -I$PREFIX/include    -fPIC  -Oz -fPIC -fwasm-exceptions -sSUPPORT_LONGJMP=wasm  -c ctapply.c -o ctapply.o
emcc -I"$BUILD_PREFIX/lib/R/include" -DNDEBUG   -Oz -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -I$PREFIX/include    -fPIC  -Oz -fPIC -fwasm-exceptions -sSUPPORT_LONGJMP=wasm  -c dummy.c -o dummy.o
emcc -I"$BUILD_PREFIX/lib/R/include" -DNDEBUG   -Oz -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -I$PREFIX/include    -fPIC  -Oz -fPIC -fwasm-exceptions -sSUPPORT_LONGJMP=wasm  -c fasthash.c -o fasthash.o
emcc -I"$BUILD_PREFIX/lib/R/include" -DNDEBUG   -Oz -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -I$PREFIX/include    -fPIC  -Oz -fPIC -fwasm-exceptions -sSUPPORT_LONGJMP=wasm  -c fastmatch.c -o fastmatch.o
emcc -Oz -sSIDE_MODULE=1 -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -shared -L$PREFIX/lib/R/lib -Oz -L$PREFIX/lib -o fastmatch.so ctapply.o dummy.o fasthash.o fastmatch.o -L$PREFIX/lib/R/lib -lR
wasm-ld: error: function signature mismatch: R_useDynamicSymbols
>>> defined as () -> void in dummy.o
>>> defined as (i32, i32) -> i32 in $PREFIX/lib/R/lib/libR.so
wasm-ld: error: function signature mismatch: R_registerRoutines
>>> defined as () -> void in dummy.o
>>> defined as (i32, i32, i32, i32, i32) -> i32 in $PREFIX/lib/R/lib/libR.so
emcc: error: '$BUILD_PREFIX/bin/wasm-ld -o fastmatch.so -L$PREFIX/lib/R/lib -L$PREFIX/lib ctapply.o dummy.o fasthash.o fastmatch.o -L$PREFIX/lib/R/lib -lR -L$BUILD_PREFIX/opt/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/pic -L$BUILD_PREFIX/opt/emsdk/upstream/emscripten/src/lib -mllvm -combiner-global-alias-analysis=false -mllvm -wasm-enable-sjlj -mllvm -wasm-use-legacy-eh -mllvm -disable-lsr -mllvm -wasm-enable-eh -mllvm -wasm-use-legacy-eh -mllvm -exception-model=wasm --import-memory --strip-debug --export=__wasm_call_ctors --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-if-defined=__wasm_apply_data_relocs --experimental-pic --unresolved-symbols=import-dynamic -shared --no-export-dynamic' failed (returned 1)
make: *** [$BUILD_PREFIX/lib/R/share/make/shlib.mk:10: fastmatch.so] Error 1
ERROR: compilation failed for package ‘fastmatch’

Any recommendation regarding how to patch the source code?

[rgaiacs]

The cross-compilation error was reported upstream s-u/fastmatch#13. Any reading documentation regarding how to create the patch file? Thanks!

[IsabelParedes]

Here's a basic workflow for creating a patch (feel free to add it to the documentation 🙂):

1. Download the tar ball for the package

wget https://cran.r-project.org/src/contrib/fastmatch_1.1-8.tar.gz

2. Extract the contents and navigate to the package directory
3. Initialize a repository and add all the files, this will make the creation of the patch easier

git init
git add .
git commit -m "First commit"

4. Make the changes you need. In this case, probably commenting out the problematic symbols in dummy.c or removing this file entirely.
5. Commit your changes

git add .
git commit -m "Fix the thing"

6. Get the hash for the first commit from with git log
7. Create the patches. This will create one patch per commit starting from the first commit (or whichever hash you provide)

git format-patch d7c9948

8. And then you'll have some nicely formatted patches that you can copy/paste to your recipe directory

[rgaiacs]

Thanks for the guidance with the patch. I included the patch in f9b77e6 and we progressed to the next circle of dependency hell. 🍾 🤣

The build script fails with error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory. Based on https://github.com/gcc-mirror/gcc/tree/ef8af34e0d173723a607789cf7cabc61366babbf/libatomic, libatomic is part of GCC but normally packaged separately, e.g. libatomic1 on Debian.

I didn't find libatomic in recipes/recipes_emscripten. What is the process next? And thanks a lot for hold my hand when navigating the circles of dependency hell for the first time.

The full build script output is

Running build script
* installing *source* package ‘fastmatch’ ...
** this is package ‘fastmatch’ version ‘1.1-8’
file ‘src/dummy.c’ is missing
** using staged installation
** libs
shared:INFO: (Emscripten: Running sanity checks)
using C compiler: ‘emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.9 (bbf1caa6e24f64fca9eb6a13a9e02d3f42123e77)’
emcc -I"$BUILD_PREFIX/lib/R/include" -DNDEBUG   -Oz -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -I$PREFIX/include    -fPIC  -Oz -fPIC -fwasm-exceptions -sSUPP
ORT_LONGJMP=wasm  -c ctapply.c -o ctapply.o
emcc -I"$BUILD_PREFIX/lib/R/include" -DNDEBUG   -Oz -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -I$PREFIX/include    -fPIC  -Oz -fPIC -fwasm-exceptions -sSUPP
ORT_LONGJMP=wasm  -c fasthash.c -o fasthash.o
emcc -I"$BUILD_PREFIX/lib/R/include" -DNDEBUG   -Oz -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -I$PREFIX/include    -fPIC  -Oz -fPIC -fwasm-exceptions -sSUPP
ORT_LONGJMP=wasm  -c fastmatch.c -o fastmatch.o
emcc -Oz -sSIDE_MODULE=1 -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -shared -L$PREFIX/lib/R/lib -Oz -L$PREFIX/lib -o fastmatch.so ctapply.o fasthash.o fastma
tch.o -L$PREFIX/lib/R/lib -lR
$BUILD_PREFIX/bin/wasm-opt: error while loading shared libraries: libatomic.so.1: cannot open shared object file: No such file or directory
emcc: error: error running binaryen executable ($BUILD_PREFIX/bin/wasm-opt). Please check your binaryen installation
make: *** [$BUILD_PREFIX/lib/R/share/make/shlib.mk:10: fastmatch.so] Error 1
ERROR: compilation failed for package ‘fastmatch’
* removing ‘$PREFIX/lib/R/library/fastmatch’

[IsabelParedes]

Hi @rgaiacs !
So libatomic should be part of the compiler package, just like it is part of GCC, in our case it is part of Emscripten.

${BUILD_PREFIX}/opt/emsdk/upstream/emscripten/src/lib/libatomic.js

When I test your PR locally, there are no errors when building r-fastmatch. The error you are seeing might only be an issue in your local setup. In that case, it might be an environment variable causing the trouble. Something might be trying to link with the libraries in the $BUILD_PREFIX, which are not WebAssembly so it's not what we want. But it's hard for me to tell.

You can move the r-fastmatch recipe to a separate PR if that makes things easier.

[IsabelParedes]

I checked the build logs again. Everything looks good for r-fastmatch.

Files in package:

  ├─ lib/R/library/fastmatch/DESCRIPTION (992 B)
  ├─ lib/R/library/fastmatch/INDEX (208 B)
  ├─ lib/R/library/fastmatch/Meta/Rd.rds (363 B)
  ├─ lib/R/library/fastmatch/Meta/features.rds (123 B)
  ├─ lib/R/library/fastmatch/Meta/hsearch.rds (398 B)
  ├─ lib/R/library/fastmatch/Meta/links.rds (165 B)
  ├─ lib/R/library/fastmatch/Meta/nsInfo.rds (388 B)
  ├─ lib/R/library/fastmatch/Meta/package.rds (958 B)
  ├─ lib/R/library/fastmatch/NAMESPACE (229 B)
  ├─ lib/R/library/fastmatch/NEWS (4.33 KiB)
  ├─ lib/R/library/fastmatch/R/fastmatch (1.03 KiB)
  ├─ lib/R/library/fastmatch/R/fastmatch.rdb (2.43 KiB)
  ├─ lib/R/library/fastmatch/R/fastmatch.rdx (400 B)
  ├─ lib/R/library/fastmatch/help/AnIndex (111 B)
  ├─ lib/R/library/fastmatch/help/aliases.rds (135 B)
  ├─ lib/R/library/fastmatch/help/fastmatch.rdb (13.85 KiB)
  ├─ lib/R/library/fastmatch/help/fastmatch.rdx (215 B)
  ├─ lib/R/library/fastmatch/help/paths.rds (183 B)
  ├─ lib/R/library/fastmatch/html/00Index.html (1.71 KiB)
  ├─ lib/R/library/fastmatch/html/R.css (1.80 KiB)
  ├─ lib/R/library/fastmatch/libs/fastmatch.so (12.13 KiB)
  ├─ info/about.json (543 B)
  ├─ info/hash_input.json (138 B)
  ├─ info/index.json (341 B)
  ├─ info/licenses/DESCRIPTION (922 B)
  ├─ info/paths.json (4.38 KiB)
  ├─ info/recipe/patches/0001-Remove-dummy.c.patch (834 B)
  ├─ info/recipe/recipe.yaml (1.09 KiB)
  ├─ info/recipe/rendered_recipe.yaml (77.26 KiB)
  ├─ info/recipe/variant_config.yaml (118 B)
  └─ info/tests/tests.yaml (3 B)

Now you just need a recipe for r-xml2

Error:   × Failed to resolve dependencies: Cannot solve the request because of: No
  │ candidates were found for r-xml2 *.
  │ 
  ╰─▶ Cannot solve the request because of: No candidates were found for r-xml2
      *.

[rgaiacs]

The error you are seeing might only be an issue in your local setup.

Interesting. In my memory, I followed the steps in described in https://emscripten-forge.org/development/local_builds/ using Pixi. I will try to replicate it and document in a separate issue / pull request.

Now you just need a recipe for r-xml2

👍 I will continue my "The Divine Comedy" journey.

[rgaiacs]

Good morning! New week. New energy to navigate the dependency hell for this PR.

I created a recipe for r-xml2. The GitHub Actions https://github.com/emscripten-forge/recipes/actions/runs/21584013994/job/62187618134 failed during "resolving build environment" with

Error:   × Failed to resolve dependencies: Cannot solve the request because of: No candidates were found for libxml2 2.13.*.

r-xml2 should be compatible with libxml2 2.15.1 that was already packaged, see https://github.com/emscripten-forge/recipes/blob/04d5cda6ae3b9a9bda4b8c44055f7e4e0f757847/recipes/recipes_emscripten/libxml2/recipe.yaml.

@IsabelParedes any tip on how to investigate this further? Thanks!

[IsabelParedes]

So the commit I just pushed is one way to fix it. The other way (and probably better way) is to update this line

recipes/variant.yaml

Line 476 in 66ceb12

- 2.13

So that when solving the environment it picks version 2.15 and not 2.13 and that would work for all other packages depending on libxml2.

Hope this helps!

[rgaiacs]

So the commit I just pushed is one way to fix it.

Thanks for the commit. I was not sure if add this type of constrains was OK or not.

1f9bd8b was with a problem regarding the license_file field. I fixed it with ac6d2a9.

Now, r-usethis is creating some problem. r-usethis is a noarch package that is being provided by conda-forge, see https://github.com/conda-forge/r-usethis-feedstock. The log says that r-usethis is only compatible with R 3.5.1

Cannot solve the request because of: r-stopwords * cannot be installed
because there are no viable options:
├─ r-stopwords 2.3 would require
│  └─ r-usethis *, which cannot be installed because there are no viable
options:
│     └─ r-usethis 1.4.0 | 1.5.0 | 1.5.1 | 1.5.1 | 1.5.1 | 1.6.0 | 1.6.0 | 1.6.1 | 1.6.1 | 1.6.1 | 1.6.1 | 1.6.3 | 1.6.3 | 2.0.0 | 2.0.0 | 2.0.1 | 2.0.1 | 2.0.1 | 2.1.0 | 2.1.0 | 2.1.2 | 2.1.2 | 2.1.3 | 2.1.3 | 2.1.5 | 2.1.5 | 2.1.6 | 2.1.6 | 2.1.6 | 2.1.6 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.0 | 2.2.1 | 2.2.1 | 2.2.2 | 2.2.2 | 2.2.3 | 2.2.3 | 2.2.3 | 2.2.3 | 3.0.0 | 3.0.0 | 3.1.0 | 3.1.0 | 3.2.0 | 3.2.0 | 3.2.1 | 3.2.1 | 3.2.1 | 3.2.1
would require
│        └─ r-base >=3.5.1,<3.5.2.0a0, for which no candidates were found.
└─ r-stopwords 0.9.0 | 0.9.0 | 0.9.0 | 1.0 | 1.0 | 2.0 | 2.0 | 2.0 | 2.0 | 2.1 | 2.1 | 2.2 | 2.2 | 2.2 | 2.3 | 2.3 | 2.3 | 2.3 | 2.3 | 2.3 | 2.3 | 2.3 | 2.3 would require
      └─ r-base >=3.5.1,<3.5.2.0a0, for which no candidates were found.

I'm surprise with the fact that r-usethis requires r-base >=3.5.1,<3.5.2.0a0 as I cannot see this rule on conda-forge recipe for r-usethis and pixi is able to install r-base>=4.5 and r-usethis, i.e.

pixi add r-base>=4.5 r-usethis

outputs

✔ Added r-base >=4.5.2,<4.6
✔ Added r-usethis >=3.2.1,<4

@IsabelParedes do you have any suggestion?

[IsabelParedes]

This is a bit of an embedded dependency which is hard to spot. Basically you need to add yet another recipe for r-rappdirs which is not noarch. r-usethis depends on r-rappdirs which is why r-usethis is not installable.

I normally debug these issues by trying to create an environment with the problematic dependencies, in this case just r-base and r-usethis.

> micromamba create -n tst-quant2 --platform=emscripten-wasm32 -c https://repo.prefix.dev/emscripten-forge-4x r-base r-usethis --dry-run

error    libmamba Could not solve for environment specs
The following packages are incompatible
└─ r-usethis =* * is not installable because there are no viable options
├─ r-usethis [2.0.0|2.0.1|...|3.2.1] would require
│  └─ r-rappdirs =* *, which does not exist (perhaps a missing channel); ❌
├─ r-usethis [1.4.0|1.5.0|1.5.1] would require
│  └─ r-base >=3.5.1,<3.5.2.0a0 *, which does not exist (perhaps a missing channel);
├─ r-usethis [1.5.1|1.6.0|1.6.1] would require
│  └─ r-base >=3.5,<3.6.0a0 *, which does not exist (perhaps a missing channel);
├─ r-usethis [1.5.1|1.6.0|1.6.1|1.6.3] would require
│  └─ r-base >=3.6,<3.7.0a0 *, which does not exist (perhaps a missing channel);
└─ r-usethis [1.6.1|1.6.3] would require
└─ r-base >=4.0,<4.1.0a0 *, which does not exist (perhaps a missing channel).
critical libmamba Could not solve for environment specs

I'm surprise with the fact that r-usethis requires r-base >=3.5.1,<3.5.2.0a0 as I cannot see this rule on conda-forge recipe for r-usethis and pixi is able to install r-base>=4.5 and r-usethis, i.e.

Perhaps when you're testing with pixi, you are missing this important bit --platform=emscripten-wasm32

[rgaiacs]

Thanks @IsabelParedes for the explanation. I will incorporate r-rappdirs tomorrow / Wednesday and continue with this journey.

I'm learning so much with this experience that I'm planning to write a blog post covering the lessons learn that I can adapt to the documentation.

[rgaiacs]

I got some time at the end of today to work on the patch for r-usethis. f7e1750 includes the patches that replaces some code with stop(). Some features of usethis will not be available as they depend on curl.

A new missing dependence for r-usethis was reported:

Error:   × Failed to resolve dependencies: Cannot solve the request because of: No candidates were found for r-fs >=1.3.0.
  │ 
  ╰─▶ Cannot solve the request because of: No candidates were found for r-fs >=1.3.0.

A added a recipe for r-fs in 0cae3e7 but it is falling with

src/unix/linux-core.c:38:10: fatal error: 'sys/epoll.h' file not found
38 | #include <sys/epoll.h>
   |          ^~~~~~~~~~~~~
1 error generated.

@IsabelParedes do you have previous experience with sys/epoll.h? Thanks!

[IsabelParedes]

So Emscripten does not have epoll.h (see emscripten-core/emscripten#18671). But it does have poll.h, not sure if this is a suitable replacement but maybe worth a try. Otherwise it might be necessary to disable the epoll functionality.

[rgaiacs]

So Emscripten does not have epoll.h

Interesting. 😄 I saw that George Stagg wrote in a issue at webr that

The fs package needs some tricky modifications for Wasm so we maintain our own r-wasm fork

@IsabelParedes is it acceptable to use r-wasm fork?

[IsabelParedes]

@IsabelParedes is it acceptable to use r-wasm fork?

For testing is okay. But for merging it would be better to convert the changes in that r-wasm branch into patches and use the official released version of the package. That way we can track when new versions are released and when the patch no longer applies.
Otherwise it would require someone to regularly update the fork and that generally doesn't happen.

[rgaiacs]

I looked a bit on how WebR builds the fs package. Using the container provided by the WebR team

podman pull ghcr.io/r-wasm/webr:main
podman run -it ghcr.io/r-wasm/webr:main /bin/sh

I run in a R session

install.packages("pak")
pak::pak("r-wasm/rwasm")
library(rwasm)
build("github::r-wasm/fs@webr")

The cross compilation log was

Targeting Wasm packages for R 4.5.1
With `WEBR_ROOT` directory: /opt/webr
With `EMSCRIPTEN_ROOT` directory: /opt/emsdk/upstream/emscripten
> build("github::r-wasm/fs@webr")
! Using bundled GitHub PAT. Please add your own PAT using `gitcreds::gitcreds_set()`.
! Failed to update system requirement mappings, will use cached mappings.
trying URL 'https://api.github.com/repos/r-wasm/fs/zipball/992749c4b366e6c81340005ec73dcc0018a047b8'
downloaded 1.5 MB

gzip: stdin has more than one entry--rest ignored
/usr/bin/tar: Child returned status 2
/usr/bin/tar: Error is not recoverable: exiting now
! Failed to update system requirement mappings, will use cached mappings.                               
                                       
> Will download 1 package with unknown size.
v All system requirements are already installed.
  
i No downloads are needed
v :  [15.5s] 
* installing *source* package 'fs' ...
** this is package 'fs' version '1.6.6'
** using non-staged installation
** libs
using C++ compiler: 'emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.8 (70404efec4458b60b953bc8f1529f2fa112cdfd1)'
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c dir.cc -o dir.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c error.cc -o error.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c file.cc -o file.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c fs.cc -o fs.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c getmode.cc -o getmode.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c id.cc -o id.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c init.cc -o init.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c link.cc -o link.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c path.cc -o path.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c utils.cc -o utils.o
em++ -std=gnu++17 -DNDEBUG -I./libuv-1.44.2/include -I.  -I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1  -fpic  -Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -DRCPP_DEMANGLER_ENABLED=0 -D__STRICT_ANSI__  -c unix/getmode.cc -o unix/getmode.o
touch libuv-1.44.2/aclocal.m4 && touch libuv-1.44.2/configure && touch libuv-1.44.2/Makefile.in
(cd libuv-1.44.2 \
&& CC="emcc" CPPFLAGS="-I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1" CFLAGS="-Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -std=gnu11 -fpic -fvisibility=hidden " AR="emar" RANLIB="emranlib" LDFLAGS="-s SIDE_MODULE=1 -s WASM_BIGINT -s ASSERTIONS=1 -L/opt/webr/wasm/lib -L/opt/webr/wasm/R-4.5.1/lib/R/lib -s USE_BZIP2=1 -s USE_ZLIB=1 -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -Oz" emconfigure ./configure --build=x86_64-pc-linux-gnu --host=wasm32-unknown-emscripten  --quiet)
configure: ./configure --build=x86_64-pc-linux-gnu --host=wasm32-unknown-emscripten --quiet
configure: WARNING: using cross tools not prefixed with host triplet
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.8 (70404efec4458b60b953bc8f1529f2fa112cdfd1)
clang version 21.0.0git (https:/github.com/llvm/llvm-project 23e3cbb2e82b62586266116c8ab77ce68e412cf8)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /opt/emsdk/upstream/bin
AR="emar" RANLIB="emranlib" make --directory=libuv-1.44.2 \
        HAVE_DTRACE=0
make[1]: Entering directory '/tmp/Rtmp84WjsQ/file26669a21d/fs/src/libuv-1.44.2'
  CC       src/libuv_la-fs-poll.lo
  CC       src/libuv_la-idna.lo
  CC       src/libuv_la-inet.lo
  CC       src/libuv_la-random.lo
  CC       src/libuv_la-strscpy.lo
  CC       src/libuv_la-threadpool.lo
  CC       src/libuv_la-timer.lo
  CC       src/libuv_la-uv-data-getter-setters.lo
  CC       src/libuv_la-uv-common.lo
  CC       src/libuv_la-version.lo
  CC       src/libuv_la-strtok.lo
  CC       src/unix/libuv_la-async.lo
  CC       src/unix/libuv_la-core.lo
src/unix/core.c:697:56: warning: comparison of integers of different signs: 'unsigned long' and 'long' [-Wsign-compare]
  697 |   for (cmsg = CMSG_FIRSTHDR(msg); cmsg != NULL; cmsg = CMSG_NXTHDR(msg, cmsg))
      |                                                        ^~~~~~~~~~~~~~~~~~~~~~
/opt/emsdk/upstream/emscripten/cache/sysroot/include/sys/socket.h:358:44: note: expanded from macro 'CMSG_NXTHDR'
  358 |         __CMSG_LEN(cmsg) + sizeof(struct cmsghdr) >= __MHDR_END(mhdr) - (unsigned char *)(cmsg) \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
  CC       src/unix/libuv_la-dl.lo
  CC       src/unix/libuv_la-fs.lo
  CC       src/unix/libuv_la-getaddrinfo.lo
  CC       src/unix/libuv_la-getnameinfo.lo
  CC       src/unix/libuv_la-loop-watcher.lo
  CC       src/unix/libuv_la-loop.lo
  CC       src/unix/libuv_la-pipe.lo
  CC       src/unix/libuv_la-poll.lo
  CC       src/unix/libuv_la-process.lo
  CC       src/unix/libuv_la-random-devurandom.lo
  CC       src/unix/libuv_la-signal.lo
  CC       src/unix/libuv_la-stream.lo
src/unix/stream.c:1025:56: warning: comparison of integers of different signs: 'unsigned long' and 'long' [-Wsign-compare]
 1025 |   for (cmsg = CMSG_FIRSTHDR(msg); cmsg != NULL; cmsg = CMSG_NXTHDR(msg, cmsg)) {
      |                                                        ^~~~~~~~~~~~~~~~~~~~~~
/opt/emsdk/upstream/emscripten/cache/sysroot/include/sys/socket.h:358:44: note: expanded from macro 'CMSG_NXTHDR'
  358 |         __CMSG_LEN(cmsg) + sizeof(struct cmsghdr) >= __MHDR_END(mhdr) - (unsigned char *)(cmsg) \
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
  CC       src/unix/libuv_la-tcp.lo
  CC       src/unix/libuv_la-thread.lo
  CC       src/unix/libuv_la-tty.lo
  CC       src/unix/libuv_la-udp.lo
  CC       src/unix/libuv_la-no-fsevents.lo
  CC       src/unix/libuv_la-no-proctitle.lo
  CC       src/unix/libuv_la-posix-hrtime.lo
  CC       src/unix/libuv_la-emscripten-poll.lo
  CC       src/unix/bsd/libuv_la-setmode.lo
  CC       src/unix/bsd/libuv_la-strmode.lo
  CC       src/unix/bsd/libuv_la-reallocarray.lo
  CCLD     libuv.la
make[1]: Leaving directory '/tmp/Rtmp84WjsQ/file26669a21d/fs/src/libuv-1.44.2'
em++ -std=gnu++17 -s SIDE_MODULE=1 -s WASM_BIGINT -s ASSERTIONS=1 -L/opt/webr/wasm/lib -L/opt/webr/wasm/R-4.5.1/lib/R/lib -s USE_BZIP2=1 -s USE_ZLIB=1 -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -Oz -o fs.so dir.o error.o file.o fs.o getmode.o id.o init.o link.o path.o utils.o unix/getmode.o ./libuv-1.44.2/.libs/libuv.pa
installing to /tmp/Rtmp84WjsQ/file27a2c8d88/fs/libs
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
*** copying figures
** building package indices
** installing vignettes
* creating tarball
packaged installation of 'fs' as 'fs_1.6.6_R_x86_64-pc-linux-gnu.tar.gz'
* DONE (fs)
Appending virtual filesystem metadata for: fs_1.6.6.tgz

I noticed that the parameters used by the WebR team to cross-compile libuv-1.44.2 is a little different. We are using

(cd libuv-1.44.2 \
&& CC="emcc" CPPFLAGS="-Oz -fwasm-exceptions -sSUPPORT_LONGJMP=wasm -I$PREFIX/include" CFLAGS="-Oz -fPIC -fwasm-exceptions -sSUPPORT_LONGJMP=wasm  -fPIC -fvisibility=hidden -std=c99" AR="emar" RANLIB="emranlib" LDFLAGS="-Oz -L$PREFIX/lib" ./configure  --quiet)

when the WebR team is using

(cd libuv-1.44.2 \
&& CC="emcc" CPPFLAGS="-I/opt/webr/wasm/include -I/opt/webr/R/build/R-4.5.1/build/include -I/opt/webr/R/build/R-4.5.1/src/include -s USE_BZIP2=1 -s USE_ZLIB=1" CFLAGS="-Oz -fPIC -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -std=gnu11 -fpic -fvisibility=hidden " AR="emar" RANLIB="emranlib" LDFLAGS="-s SIDE_MODULE=1 -s WASM_BIGINT -s ASSERTIONS=1 -L/opt/webr/wasm/lib -L/opt/webr/wasm/R-4.5.1/lib/R/lib -s USE_BZIP2=1 -s USE_ZLIB=1 -fwasm-exceptions -s SUPPORT_LONGJMP=wasm -Oz" emconfigure ./configure --build=x86_64-pc-linux-gnu --host=wasm32-unknown-emscripten  --quiet)

@IsabelParedes do you know how rattler-build creates the options passed to emconfigure?

[rgaiacs]

I new dependence is missing. 😢

Failed to resolve dependencies: Cannot solve the request because of: No candidates were found for r-gert >=1.4.1.