Date: Sun, 28 Jun 2015 00:20:06 +0200 From: "piranna@...il.com" <piranna@...il.com> To: musl@...ts.openwall.com Subject: Fwd: Link problems with static node-canvas > 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 Download attachment "node-canvas_rebuild.txt.tar.gz" of type "application/x-gzip" (8829 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.