[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150627170728.3f15c1da@r2lynx>
Date: Sat, 27 Jun 2015 17:07:28 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Link problems with static node-canvas
On Sat, 27 Jun 2015 11:41:43 +0200
"piranna@...il.com" <piranna@...il.com> wrote:
> Hi Lynx, thank you for your answer.
>
> Attached you can find the output of `readelf -Wa canvas.node`, as you
> can see the only NEEDED libraries are libstdc++.so.6 (the gcc c++
> runtime) and libc.so (musl, in this case). Also you can see that
> jinit_arith_decoder has entries in the .rela.plt, .dynsym and .symtab
> sections.
>
> I've compiled canvas.node with the -static argument to force all its
> dependencies are linked statically and "bundled" in the final shared
> object. GCC devs don't want -shared and -static being used at the same
> time and try to promote the usage of dynamic libraries everywhere
> (https://bugzilla.redhat.com/show_bug.cgi?id=214465#c1) although they
> are compatible and has some valid use cases (like generating Node.js
> modules, that's this case), and although both files are the same
> crtbeginT.o (used when the -static flag is enabled) is not compiled
> with -fPIL needed to be used in shared libraries, so I needed to write
> crtbeginS.o over crtbeginT.o
> (https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/640734/comments/6).
> LLVM don't have this problem, since it only have one version of
> crtbegin.o, in any case this seems not to be a problem since I have
> done the sabe "trick" both on my Ubuntu machine and the NodeOS
> toolchain and nothing more got broken...
>
> If you want to try it yourself, you can download the code of my fork
> of node-canvas (https://github.com/NodeOS/node-canvas) and compile it
> with 'npm install --has_cairo=false' (you'll need to have Node.js
> installed)
>
> 2015-06-27 8:18 GMT+02:00 Рысь <lynx@...server.ru>:
> > On Sat, 27 Jun 2015 01:06:04 +0200
> > "piranna@...il.com" <piranna@...il.com> wrote:
> >
> >> I have been trying in the last days to craft a statically linked
> >> version of node-canvas (https://github.com/Automattic/node-canvas)
> >> to use it in NodeOS (a musl-based Linux OS with no global
> >> libraries).
> >>
> >> In my fork I managed to convert it from needing cairo, libjpeg,
> >> freetype and giflib as dynamica libraries to create it as a
> >> statically linked shared object that contains all of them inside,
> >> making it autonomous (that's the way ideally Node.js addons are
> >> build, as .so files -with the extension changed to .node- with all
> >> their dependencies statically linked and not needing any dynamic
> >> library. This .node files later are loaded with dlopen() when
> >> someone requires them by calling the require() function from
> >> inside Node.js).
> >>
> >> When compiling it in Ubuntu using glibc it works correctly, but
> >> when compiling it for NodeOS using musl, I got an error about
> >> "Error relocating: jinit_arith_decode symbol not found"
> >> (https://github.com/Automattic/node-canvas/issues/551#issuecomment-114253760).
> >> That function is from libjpeg, and both the jpeg.a and the
> >> canvas.node files have references to it. I've trying to use the
> >> musl-compiled canvas.node file by using LD_LIBRARY_PATH and it
> >> shows the "Error relocating" string, but doesn't clarify where's
> >> the error. At first I though it would be a libjpeg-turbo problem,
> >> but after removing the support for JPEG in node-canvas, the same
> >> "Error relocating" problem showed, only that now regarding to a
> >> FreeType function, so since it works correctly with glibc that's
> >> why I thought it could be a linking problem related to musl. This
> >> is strange since other compiled modules works correctly under
> >> NodeOS, but it's true they don't link with other libraries (both
> >> startic or dynamic) beyond the C lib or the Linux kernel
> >> SysCalls... :-/
> >>
> >> Any idea or suggestiong about what could be the culprit or where to
> >> continue investigating?
> >>
> >
> > If canvas.node is a shared object then linker will not warn you
> > about any missing symbols when making it. So, your libjpeg.a was
> > not included during build or somehow broken. Do a `readelf -Wa
> > canvas.node` and make sure you still have no shared dependencies on
> > libraries you link statically (you have no NEEDED libraries in
> > Dynamic section). Alternatively gzip the output and attach with
> > your next message.
>
>
>
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.
If you link in static libraries than you should, like with static
programs, order your dependency list (the order of static libraries).
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?
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.
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.
