[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfGGh0DdGKqQ5g4x1sENHr0EYGuDD4xhamoqjja2jPtp-82tg@mail.gmail.com>
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.
