[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150628101706.38f1631d@r2lynx>
Date: Sun, 28 Jun 2015 10:17:06 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Fwd: Link problems with static node-canvas
On Sun, 28 Jun 2015 00:20:06 +0200
"piranna@...il.com" <piranna@...il.com> wrote:
> > 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...
>
You sent complete readelf for your faulty shared library and I verified
FT ones with:
fgrep \ UND\ canvas_node.txt | egrep '(NOTYPE|FUNC)' | fgrep FT_
>
> > 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).
Something is still referencing missing symbols even after already
processed libraries. If you can, then try to add jpeg and freetype deps
again but before cairo. (but without build environment and object file
contents it's hard to judge for me, it requires proper library juggle)
>
>
> > 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.
>
>
Sorry, but the file is zero bytes in length as reported by Dropbox.
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.
