[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKfGGh0CpAOSc=36myaeJ8y+8Ps9G7E1Oq11aFNiOb2-qkCg5w@mail.gmail.com>
Date: Sun, 28 Jun 2015 20:21:27 +0200
From: "piranna@...il.com" <piranna@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Fwd: Link problems with static node-canvas
Ok, as you can see at
https://github.com/NodeOS/NodeOS/issues/39#issuecomment-116304688...
it works! :-D After adding the missing files the last remaining
undefined symbol was a virtual destructor, that musl requested it on
load time (other systems like glibc-based ones would crash when
calling the destructor, and probably get unnoticed since it happens
just about to exit the app). After that, there were no more undefined
symbols and got it to run on NodeOS :-) Thank you so much to both of
you although it was not a musl directly related question, but
definitely it and your advices has help to find the source of the
problem :-D
By the way: NodeOS is not only a hobby project but also my degree
thesis, so if you want, you can send me your GitHub account or a
personal website and I can put a reference to it on the thesis :-)
2015-06-28 15:06 GMT+02:00 piranna@...il.com <piranna@...il.com>:
>> That's normal, for example I've taken one symbol from `nm -u` and
>> checked it just with `nm` and this symbol is properly defined:
>>
>> % nm /local/lib/libjpeg.a | fgrep jpeg_alloc_huff_table
>> U jpeg_alloc_huff_table
>> 000000b0 T jpeg_alloc_huff_table
>> U jpeg_alloc_huff_table
>> U jpeg_alloc_huff_table
>>
>> Just other object files inside library are referencing this symbol and
>> have source object file with this symbol as dependency and ld inserts
>> it into final executable/shared object. That's why `nm` reports them as
>> undefined.
>
> Yeah, this makes sense since .a is just an archive file like zip, so
> there's no info regarding available symbols and this is delegated to
> the link process...
>
> This gave an idea and searching for "nm symbol is undefined" I got to
> https://blog.flameeyes.eu/2010/09/your-worst-enemy-undefined-symbols#gsc.tab=0
> that talks about the '-Wl,--no-undefined' option, that allows to show
> an error when there are undefined symbols also in dynamic libraries.
> This gave me a lot of entries regarding some harm-less virtual
> destructors on node-canvas and some entries for node and v8 namespaces
> (that should be filled by Node.js binary after doing dlopen()) and
> some other entries for FreeType and libJpeg. After searching for the
> files that had them... I found that gyp was not compiling them, so
> they were not available on link stage (Doh! :-( ). I supposed this
> kind of things would show a better warning, so I didn't though about
> it, and also the tests of node-canvas didn't gave any problem... After
> adding them, these entries dissappeared leaving only the virtual
> destructors, node and v8 ones, and some of the examples that were
> failing due to FreeType dependencies now work when compiled with glibc
> :-)
>
> After that I compiled it with musl and got another symbol not found
> (_ZN2v87Isolate17CollectAllGarbageEPKc) that's strange because it
> should be provided by Node.js, but maybe I'm having a version conflict
> here, I'm going to investigate it.
>
>
> --
> "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
--
"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
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.
