> There are more undefined symbols than listed on your screenshot, but
> musl reports only one (maybe that's related to dynlinker overhaul), in
> particular from Freetype there are 20 of them, and jinit_arith_encoder,
> also related to jpeg.

It seems so, since when I removed jpeg support it showed one from
FreeType, that's why I though it could be related to the linker :-)
How have you been able to see all of them? Are you talking about the
output of musl-ldd? I tried it instead of Ubuntu ldd and got a lot of
errors, but since Ubuntu ldd didn't gave anyone I though it could be
due to a bad usage of LD_LIBRARY_PATH...


> If you link in static libraries than you should, like with static
> programs, order your dependency list (the order of static libraries).

That makes sense.


> Since ld does not generate any link errors when making shared object
> and treat any undefined symbol like it will come later it's hard to do
> that right when you don't know your library internals well (and you're
> not with bigger ones such as jpeg, png and freetype). What's your final
> link command?

Build process is managed automatically by node-gyp and the makefile is
generated each time, so I don't think could hand too much here...
Anyway, I've executed 'npm install --verbose' and got the make output
in console. The linker string is:

  flock ./Release/linker.lock x86_64-nodeos-linux-musl-g++ -shared
-pthread -rdynamic -m64  -Wl,-soname=canvas.node -o
Release/obj.target/canvas.node -Wl,--start-group
Release/obj.target/canvas/src/backend/ImageBackend.o
Release/obj.target/canvas/src/backend/FBDevBackend.o
Release/obj.target/canvas/src/Canvas.o
Release/obj.target/canvas/src/CanvasGradient.o
Release/obj.target/canvas/src/CanvasPattern.o
Release/obj.target/canvas/src/CanvasRenderingContext2d.o
Release/obj.target/canvas/src/color.o
Release/obj.target/canvas/src/Image.o
Release/obj.target/canvas/src/ImageData.o
Release/obj.target/canvas/src/init.o
Release/obj.target/canvas/src/PixelArray.o
Release/obj.target/canvas/src/FontFace.o
Release/obj.target/static/cairo.a Release/obj.target/static/png.a
Release/obj.target/static/jpeg.a Release/obj.target/static/gif.a
Release/obj.target/static/pixman.a
Release/obj.target/static/freetype.a Release/obj.target/static/zlib.a
-Wl,--end-group -static

Also I've attached the full make output (the extra info is from
node-gyp, I think can be useful).


> If possible, upload a test VM somewhere with a faulty shared object
> and build environment which produced it, which can be run with QEMU or
> KVM and I could investigate what's wrong with it.

https://www.dropbox.com/s/ib7wy5wg6mnl16i/NodeOS.tar.gz?dl=0

Not exactly a virtual machine... but my full NodeOS project folder
with all its dependencies and the faulty build :-) You can test it
just by executing 'npm start', and it will start QEmu with an instance
of NodeOS. On the prompt, login with nodeos:nodeos and later cd to
node-canvas folder. Once there, you can exec 'node
examples/simple-fbdev.js' and you'll get the same error I had in the
screenshot. You have the faulty canvas.node file in the project folder
at node_modules/nodeos-usersfs/obj/nocona/nodeos/node-canvas/build/Release/canvas.node,
and the cross-toolchain is at
node_modules/nodeos-barebones/node_modules/nodeos-crosstoolchain/out.


-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux