mailing list of musl libc
 help / color / mirror / code / Atom feed
* Link problems with static node-canvas
@ 2015-06-26 23:06 piranna
  2015-06-27  6:18 ` Рысь
  0 siblings, 1 reply; 14+ messages in thread
From: piranna @ 2015-06-26 23:06 UTC (permalink / raw)
  To: musl

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?

-- 
"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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Link problems with static node-canvas
  2015-06-26 23:06 Link problems with static node-canvas piranna
@ 2015-06-27  6:18 ` Рысь
  2015-06-27  9:41   ` piranna
  0 siblings, 1 reply; 14+ messages in thread
From: Рысь @ 2015-06-27  6:18 UTC (permalink / raw)
  To: musl

On Sat, 27 Jun 2015 01:06:04 +0200
"piranna@gmail.com" <piranna@gmail.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.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Link problems with static node-canvas
  2015-06-27  6:18 ` Рысь
@ 2015-06-27  9:41   ` piranna
  2015-06-27 10:07     ` Рысь
  0 siblings, 1 reply; 14+ messages in thread
From: piranna @ 2015-06-27  9:41 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 4307 bytes --]

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@sibserver.ru>:
> On Sat, 27 Jun 2015 01:06:04 +0200
> "piranna@gmail.com" <piranna@gmail.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.



-- 
"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

[-- Attachment #2: canvas_node.txt.tar.gz --]
[-- Type: application/x-gzip, Size: 146897 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Link problems with static node-canvas
  2015-06-27  9:41   ` piranna
@ 2015-06-27 10:07     ` Рысь
  2015-06-27 11:18       ` Szabolcs Nagy
       [not found]       ` <CAKfGGh1DvxCjHWYpCENH3mcxDRa9LimHMCPhteoeb+4S0R5Uvg@mail.gmail.com>
  0 siblings, 2 replies; 14+ messages in thread
From: Рысь @ 2015-06-27 10:07 UTC (permalink / raw)
  To: musl

On Sat, 27 Jun 2015 11:41:43 +0200
"piranna@gmail.com" <piranna@gmail.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@sibserver.ru>:
> > On Sat, 27 Jun 2015 01:06:04 +0200
> > "piranna@gmail.com" <piranna@gmail.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.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Link problems with static node-canvas
  2015-06-27 10:07     ` Рысь
@ 2015-06-27 11:18       ` Szabolcs Nagy
  2015-06-27 22:05         ` piranna
       [not found]       ` <CAKfGGh1DvxCjHWYpCENH3mcxDRa9LimHMCPhteoeb+4S0R5Uvg@mail.gmail.com>
  1 sibling, 1 reply; 14+ messages in thread
From: Szabolcs Nagy @ 2015-06-27 11:18 UTC (permalink / raw)
  To: musl

* ???????? <lynx@sibserver.ru> [2015-06-27 17:07:28 +0700]:
> 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.
> 

what's worse is that it most likely broken with glibc too

just seems to work because the symbols weren't used, but as
soon as they are, the code will crash.. (because lazy binding)

> 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?
> 

this is most likely the issue

whatever the link command was add -ljpeg and -lwhateverwasmissing
to the end


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Link problems with static node-canvas
  2015-06-27 11:18       ` Szabolcs Nagy
@ 2015-06-27 22:05         ` piranna
  0 siblings, 0 replies; 14+ messages in thread
From: piranna @ 2015-06-27 22:05 UTC (permalink / raw)
  To: musl

> just seems to work because the symbols weren't used, but as
> soon as they are, the code will crash.. (because lazy binding)

Didn't though about it...

[piranna@Mabuk:~/Proyectos/node-canvas]
 (master) > node examples/font.js
node: symbol lookup error:
/home/piranna/Proyectos/node-canvas/build/Release/canvas.node:
undefined symbol: FT_Init_FreeType

...but seems you are right, the Ubuntu-glibc compilation have the same
problem, only that lazy binding didn't showed it before.


> whatever the link command was add -ljpeg and -lwhateverwasmissing
> to the end

I've tried this with no result, also by adding the -L argument and
using directly the filename and path to the .a files. Also, the
generated linker command makes use of --start-group and --end-group,
that according to the docs iterates over the object files instead of
doing only one pass until all the undefined entries are resolved...
other thing is that if this is a no-op while building a dynamic
library since some of the entries would be always undefined and
resolved in other place... Anyway, by adding the libraries at the end
as you suggested it should have work... :-/


-- 
"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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Fwd: Link problems with static node-canvas
       [not found]       ` <CAKfGGh1DvxCjHWYpCENH3mcxDRa9LimHMCPhteoeb+4S0R5Uvg@mail.gmail.com>
@ 2015-06-27 22:20         ` piranna
  2015-06-27 22:41           ` Szabolcs Nagy
  2015-06-28  3:17           ` Рысь
  0 siblings, 2 replies; 14+ messages in thread
From: piranna @ 2015-06-27 22:20 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 3597 bytes --]

> 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

[-- Attachment #2: node-canvas_rebuild.txt.tar.gz --]
[-- Type: application/x-gzip, Size: 8829 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Fwd: Link problems with static node-canvas
  2015-06-27 22:20         ` Fwd: " piranna
@ 2015-06-27 22:41           ` Szabolcs Nagy
  2015-06-27 23:10             ` piranna
  2015-06-28  3:17           ` Рысь
  1 sibling, 1 reply; 14+ messages in thread
From: Szabolcs Nagy @ 2015-06-27 22:41 UTC (permalink / raw)
  To: musl

* piranna@gmail.com <piranna@gmail.com> [2015-06-28 00:20:06 +0200]:
> 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).
> 

have you verified that
Release/obj.target/static/jpeg.a
Release/obj.target/static/freetype.a
have the missing symbols?
(eg using nm)


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Fwd: Link problems with static node-canvas
  2015-06-27 22:41           ` Szabolcs Nagy
@ 2015-06-27 23:10             ` piranna
  2015-06-28  3:23               ` Рысь
  0 siblings, 1 reply; 14+ messages in thread
From: piranna @ 2015-06-27 23:10 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

> have you verified that
> Release/obj.target/static/jpeg.a
> Release/obj.target/static/freetype.a
> have the missing symbols?
> (eg using nm)

I have checked them with nm -u and they are defined, although as
"undefined"... What does this means? The output tell they are
"undefined" in the .o file that is defining them... :-/

P.D.: sorry for so much questions, this things are totally new to me... :-(


-- 
"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

[-- Attachment #2: freetype_nm.txt --]
[-- Type: text/plain, Size: 19196 bytes --]


autofit.o:
                 U ft_corner_is_flat
                 U FT_DivFix
                 U FT_Get_Advance
                 U FT_Get_Char_Index
                 U FT_Get_Next_Char
                 U FT_Load_Glyph
                 U FT_Matrix_Invert
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_MulDiv
                 U FT_Outline_Get_CBox
                 U FT_Outline_Get_Orientation
                 U FT_Outline_Transform
                 U FT_Outline_Translate
                 U FT_Select_Charmap
                 U ft_service_list_lookup
                 U FT_Set_Charmap
                 U FT_Vector_Transform
                 U _GLOBAL_OFFSET_TABLE_
                 U memset

ftbase.o:
                 U FT_Stream_Open
                 U _GLOBAL_OFFSET_TABLE_
                 U longjmp
                 U memcmp
                 U memcpy
                 U memmove
                 U memset
                 U qsort
                 U strcmp
                 U strcpy
                 U strlen
                 U strncpy
                 U strrchr

bdf.o:
                 U FT_CMap_New
                 U ft_glyphslot_set_bitmap
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U ft_mem_strdup
                 U FT_MulDiv
                 U FT_Select_Metrics
                 U ft_service_list_lookup
                 U FT_Stream_Seek
                 U FT_Stream_TryRead
                 U ft_synthesize_vertical_metrics
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy
                 U memmove
                 U qsort
                 U sprintf
                 U strcmp
                 U strlen

ftbzip2.o:

ftcache.o:
                 U FT_Activate_Size
                 U FT_Done_Face
                 U FT_Done_Glyph
                 U FT_Done_Size
                 U FT_Get_Char_Index
                 U FT_Get_Glyph
                 U FT_Load_Glyph
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_New_Size
                 U FT_Set_Charmap
                 U FT_Set_Char_Size
                 U FT_Set_Pixel_Sizes
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy

cff.o:
                 U FT_CMap_New
                 U FT_DivFix
                 U FT_Get_Module
                 U FT_Get_Module_Interface
                 U FT_GlyphLoader_Add
                 U FT_GlyphLoader_CheckPoints
                 U FT_GlyphLoader_Rewind
                 U FT_Matrix_Multiply_Scaled
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_qalloc
                 U ft_mem_realloc
                 U ft_mem_strcpyn
                 U ft_mem_strdup
                 U ft_module_get_service
                 U FT_MulDiv
                 U FT_Outline_Get_CBox
                 U FT_Outline_Transform
                 U FT_Outline_Translate
                 U FT_Request_Metrics
                 U FT_RoundFix
                 U FT_Select_Metrics
                 U ft_service_list_lookup
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_ExtractFrame
                 U FT_Stream_GetUShort
                 U FT_Stream_Pos
                 U FT_Stream_Read
                 U FT_Stream_ReadChar
                 U FT_Stream_ReadFields
                 U FT_Stream_ReadUShort
                 U FT_Stream_ReleaseFrame
                 U FT_Stream_Seek
                 U FT_Stream_Skip
                 U ft_synthesize_vertical_metrics
                 U FT_Vector_Transform
                 U FT_Vector_Transform_Scaled
                 U _GLOBAL_OFFSET_TABLE_
                 U memcmp
                 U memcpy
                 U memset
                 U strcmp
                 U strlen
                 U strncmp

type1cid.o:
                 U atol
                 U FT_DivFix
                 U FT_Get_Module
                 U FT_Get_Module_Interface
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_Outline_Get_CBox
                 U FT_Outline_Transform
                 U FT_Outline_Translate
                 U FT_Request_Metrics
                 U FT_RoundFix
                 U ft_service_list_lookup
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_ExtractFrame
                 U FT_Stream_OpenMemory
                 U FT_Stream_Pos
                 U FT_Stream_Read
                 U FT_Stream_ReadAt
                 U FT_Stream_ReleaseFrame
                 U FT_Stream_Seek
                 U ft_synthesize_vertical_metrics
                 U FT_Vector_Transform
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy
                 U memmove
                 U strlen

gxvalid.o:
                 U FT_Get_Sfnt_Name
                 U FT_Get_Sfnt_Name_Count
                 U FT_Load_Glyph
                 U FT_Load_Sfnt_Table
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_service_list_lookup
                 U ft_validator_error
                 U ft_validator_init
                 U _GLOBAL_OFFSET_TABLE_
                 U qsort
                 U setjmp

ftgzip.o:
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_qalloc
                 U FT_Stream_Pos
                 U FT_Stream_Read
                 U FT_Stream_ReadChar
                 U FT_Stream_ReadULong
                 U FT_Stream_ReadUShortLE
                 U FT_Stream_Seek
                 U FT_Stream_Skip
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy

ftlzw.o:
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_Stream_Read
                 U FT_Stream_Seek
                 U FT_Stream_TryRead
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy
                 U memmove

otvalid.o:
                 U FT_Load_Sfnt_Table
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_service_list_lookup
                 U ft_validator_error
                 U ft_validator_init
                 U _GLOBAL_OFFSET_TABLE_
                 U setjmp

pcf.o:
                 U FT_CMap_New
                 U ft_glyphslot_alloc_bitmap
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U ft_mem_strdup
                 U FT_Select_Metrics
                 U ft_service_list_lookup
                 U FT_Stream_Close
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_GetULong
                 U FT_Stream_GetULongLE
                 U FT_Stream_GetUShort
                 U FT_Stream_GetUShortLE
                 U FT_Stream_OpenGzip
                 U FT_Stream_OpenLZW
                 U FT_Stream_Read
                 U FT_Stream_ReadFields
                 U FT_Stream_ReadULong
                 U FT_Stream_ReadULongLE
                 U FT_Stream_ReadUShort
                 U FT_Stream_ReadUShortLE
                 U FT_Stream_Seek
                 U FT_Stream_Skip
                 U ft_synthesize_vertical_metrics
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy
                 U strcmp
                 U strlen

pfr.o:
                 U FT_CMap_New
                 U FT_DivFix
                 U FT_GlyphLoader_Add
                 U FT_GlyphLoader_CheckPoints
                 U FT_GlyphLoader_Rewind
                 U ft_glyphslot_alloc_bitmap
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_MulDiv
                 U FT_MulFix
                 U FT_Outline_Get_CBox
                 U ft_service_list_lookup
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_Pos
                 U FT_Stream_ReadFields
                 U FT_Stream_ReadUOffset
                 U FT_Stream_ReadUShort
                 U FT_Stream_Seek
                 U FT_Stream_Skip
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy

psaux.o:
                 U FT_DivFix
                 U FT_GlyphLoader_Add
                 U FT_GlyphLoader_CheckPoints
                 U FT_GlyphLoader_CheckSubGlyphs
                 U FT_GlyphLoader_Prepare
                 U FT_GlyphLoader_Rewind
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_qalloc
                 U ft_mem_realloc
                 U ft_module_get_service
                 U FT_RoundFix
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy
                 U memset
                 U qsort
                 U strcmp
                 U strncmp

pshinter.o:
                 U ft_corner_is_flat
                 U ft_corner_orientation
                 U FT_DivFix
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_MulDiv
                 U FT_RoundFix
                 U _GLOBAL_OFFSET_TABLE_
                 U memmove

psnames.o:
                 U ft_mem_free
                 U ft_mem_realloc
                 U ft_service_list_lookup
                 U _GLOBAL_OFFSET_TABLE_
                 U qsort
                 U strcmp

raster.o:
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_MulDiv
                 U FT_MulDiv_No_Round
                 U FT_Outline_Get_CBox
                 U FT_Outline_Transform
                 U FT_Outline_Translate
                 U _GLOBAL_OFFSET_TABLE_

sfnt.o:
                 U FT_Bitmap_Convert
                 U FT_Bitmap_Done
                 U FT_Bitmap_Init
                 U FT_CMap_New
                 U FT_Get_Module_Interface
                 U ft_glyphslot_alloc_bitmap
                 U ft_glyphslot_set_bitmap
                 U FT_Gzip_Uncompress
                 U FT_Match_Size
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U ft_mem_strcpyn
                 U ft_module_get_service
                 U ft_service_list_lookup
                 U FT_Stream_Close
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_ExtractFrame
                 U FT_Stream_Free
                 U FT_Stream_GetULong
                 U FT_Stream_GetUShort
                 U FT_Stream_OpenMemory
                 U FT_Stream_Pos
                 U FT_Stream_Read
                 U FT_Stream_ReadAt
                 U FT_Stream_ReadChar
                 U FT_Stream_ReadFields
                 U FT_Stream_ReadULong
                 U FT_Stream_ReadUShort
                 U FT_Stream_ReleaseFrame
                 U FT_Stream_Seek
                 U FT_Stream_Skip
                 U ft_validator_error
                 U ft_validator_init
                 U _GLOBAL_OFFSET_TABLE_
                 U memchr
                 U memcpy
                 U qsort
                 U setjmp
                 U strcmp
                 U strlen
                 U strncmp

smooth.o:
                 U ft_mem_alloc
                 U ft_mem_free
                 U FT_Outline_Decompose
                 U FT_Outline_Get_CBox
                 U FT_Outline_Transform
                 U FT_Outline_Translate
                 U _GLOBAL_OFFSET_TABLE_
                 U longjmp
                 U memcpy
                 U memset
                 U setjmp

apinames.o:
                 U exit
                 U fclose
                 U feof
                 U fgets
                 U fopen
                 U fprintf
                 U fwrite
                 U _GLOBAL_OFFSET_TABLE_
                 U isalnum
                 U malloc
                 U memcmp
                 U memcpy
                 U qsort
                 U realloc
                 U stderr
                 U stdin
                 U stdout
                 U strchr
                 U strcmp

ftrandom.o:
                 U alarm
                 U calloc
                 U ceil
                 U closedir
                 U exit
                 U fclose
                 U ferror
                 U fopen
                 U fork
                 U fprintf
                 U fread
                 U free
                 U fseek
                 U FT_Done_Face
                 U FT_Init_FreeType
                 U FT_Load_Glyph
                 U FT_New_Face
                 U FT_Outline_Decompose
                 U FT_Render_Glyph
                 U FT_Set_Char_Size
                 U fwrite
                 U getc
                 U _GLOBAL_OFFSET_TABLE_
                 U kill
                 U mkdir
                 U opendir
                 U printf
                 U putc
                 U random
                 U readdir
                 U realloc
                 U signal
                 U snprintf
                 U sprintf
                 U srandom
                 U stat
                 U stderr
                 U stdout
                 U strcasecmp
                 U strcmp
                 U strdup
                 U strrchr
                 U strstr
                 U strtod
                 U strtol
                 U time
                 U unlink
                 U waitpid
                 U write

test_afm.o:
                 U FT_Done_FreeType
                 U FT_Get_Module_Interface
                 U FT_Init_FreeType
                 U ft_mem_free
                 U FT_Stream_Close
                 U FT_Stream_EnterFrame
                 U FT_Stream_Open
                 U _GLOBAL_OFFSET_TABLE_
                 U printf
                 U putchar
                 U puts

test_bbox.o:
                 U clock
                 U FT_Outline_Get_BBox
                 U FT_Outline_Get_CBox
                 U _GLOBAL_OFFSET_TABLE_
                 U printf
                 U puts

test_trig.o:
                 U cexp
                 U cos
                 U FT_Atan2
                 U FT_Cos
                 U FT_Sin
                 U FT_Vector_Length
                 U FT_Vector_Rotate
                 U FT_Vector_Unit
                 U _GLOBAL_OFFSET_TABLE_
                 U printf
                 U puts
                 U sin

truetype.o:
                 U FT_DivFix
                 U FT_Get_Glyph_Name
                 U FT_Get_Module
                 U FT_Get_Module_Interface
                 U FT_GlyphLoader_Add
                 U FT_GlyphLoader_CheckPoints
                 U FT_GlyphLoader_CheckSubGlyphs
                 U FT_GlyphLoader_CreateExtra
                 U FT_GlyphLoader_Rewind
                 U FT_Hypot
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_MulDiv
                 U FT_MulDiv_No_Round
                 U FT_Outline_Get_CBox
                 U FT_Outline_Translate
                 U FT_Request_Metrics
                 U FT_Select_Metrics
                 U ft_service_list_lookup
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_ExtractFrame
                 U FT_Stream_GetChar
                 U FT_Stream_GetULong
                 U FT_Stream_GetUShort
                 U FT_Stream_OpenMemory
                 U FT_Stream_Pos
                 U FT_Stream_Read
                 U FT_Stream_ReadFields
                 U FT_Stream_ReadUShort
                 U FT_Stream_ReleaseFrame
                 U FT_Stream_Seek
                 U FT_Vector_Transform
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy
                 U memmove
                 U strncmp
                 U strstr

type1.o:
                 U FT_CMap_New
                 U FT_DivFix
                 U FT_Get_Char_Index
                 U FT_Get_Module
                 U FT_Get_Module_Interface
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U ft_mem_strcpyn
                 U ft_module_get_service
                 U FT_MulDiv
                 U FT_Outline_Get_CBox
                 U FT_Outline_Transform
                 U FT_Outline_Translate
                 U FT_Request_Metrics
                 U FT_RoundFix
                 U ft_service_list_lookup
                 U FT_Set_Charmap
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_Pos
                 U FT_Stream_Read
                 U FT_Stream_ReadULongLE
                 U FT_Stream_ReadUShort
                 U FT_Stream_Seek
                 U FT_Stream_Skip
                 U ft_synthesize_vertical_metrics
                 U FT_Vector_Transform
                 U _GLOBAL_OFFSET_TABLE_
                 U memchr
                 U memcmp
                 U memcpy
                 U memmove
                 U memset
                 U qsort
                 U strcmp
                 U strlen
                 U strncmp

type42.o:
                 U atol
                 U FT_Activate_Size
                 U FT_CMap_New
                 U FT_DivFix
                 U FT_Done_Face
                 U FT_Done_GlyphSlot
                 U FT_Done_Size
                 U FT_Get_Module
                 U FT_Get_Module_Interface
                 U ft_glyphslot_free_bitmap
                 U FT_List_Find
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U ft_mem_strcpyn
                 U ft_module_get_service
                 U FT_New_GlyphSlot
                 U FT_New_Size
                 U FT_Open_Face
                 U FT_Request_Size
                 U FT_Select_Size
                 U ft_service_list_lookup
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_Read
                 U FT_Stream_Seek
                 U FT_Stream_Skip
                 U _GLOBAL_OFFSET_TABLE_
                 U memcmp
                 U strcmp
                 U strlen

winfnt.o:
                 U FT_CMap_New
                 U ft_mem_alloc
                 U ft_mem_free
                 U ft_mem_realloc
                 U FT_MulDiv
                 U FT_Select_Metrics
                 U ft_service_list_lookup
                 U FT_Stream_EnterFrame
                 U FT_Stream_ExitFrame
                 U FT_Stream_ExtractFrame
                 U FT_Stream_GetUShortLE
                 U FT_Stream_Pos
                 U FT_Stream_ReadFields
                 U FT_Stream_ReleaseFrame
                 U FT_Stream_Seek
                 U ft_synthesize_vertical_metrics
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy
                 U strlen

[-- Attachment #3: jpeg_nm.txt --]
[-- Type: text/plain, Size: 7556 bytes --]


jsimd_none.o:

jcapimin.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jinit_marker_writer
                 U jinit_memory_mgr
                 U jpeg_abort
                 U jpeg_destroy

jcapistd.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jinit_compress_master
                 U jpeg_suppress_tables

jccoefct.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jround_up
                 U jzero_far

jccolor.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jsimd_can_rgb_gray
                 U jsimd_can_rgb_ycc
                 U jsimd_rgb_gray_convert
                 U jsimd_rgb_ycc_convert

jcdctmgr.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_fdct_float
                 U jpeg_fdct_ifast
                 U jpeg_fdct_islow
                 U jsimd_can_convsamp
                 U jsimd_can_convsamp_float
                 U jsimd_can_fdct_float
                 U jsimd_can_fdct_ifast
                 U jsimd_can_fdct_islow
                 U jsimd_can_quantize
                 U jsimd_can_quantize_float
                 U jsimd_convsamp
                 U jsimd_convsamp_float
                 U jsimd_fdct_float
                 U jsimd_fdct_ifast
                 U jsimd_fdct_islow
                 U jsimd_quantize
                 U jsimd_quantize_float

jchuff.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_alloc_huff_table
                 U jpeg_natural_order
                 U memcpy

jcinit.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jinit_arith_encoder
                 U jinit_c_coef_controller
                 U jinit_c_main_controller
                 U jinit_c_master_control
                 U jinit_color_converter
                 U jinit_c_prep_controller
                 U jinit_downsampler
                 U jinit_forward_dct
                 U jinit_huff_encoder
                 U jinit_marker_writer
                 U jinit_phuff_encoder

jcmainct.o:

jcmarker.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_natural_order

jcmaster.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jdiv_round_up

jcomapi.o:

jcparam.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_alloc_huff_table
                 U jpeg_alloc_quant_table
                 U memcpy

jcphuff.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_alloc_huff_table
                 U jpeg_gen_optimal_table
                 U jpeg_make_c_derived_tbl
                 U jpeg_natural_order

jcprepct.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jcopy_sample_rows
                 U memcpy

jcsample.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jcopy_sample_rows
                 U jsimd_can_h2v1_downsample
                 U jsimd_can_h2v2_downsample
                 U jsimd_h2v1_downsample
                 U jsimd_h2v2_downsample

jdapimin.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jinit_input_controller
                 U jinit_marker_reader
                 U jinit_memory_mgr
                 U jpeg_abort
                 U jpeg_destroy

jdapistd.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jinit_master_decompress

jdatadst.o:
                 U ferror
                 U fflush
                 U fwrite
                 U _GLOBAL_OFFSET_TABLE_

jdatasrc.o:
                 U fread
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_resync_to_restart

jdcoefct.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jcopy_block_row
                 U jround_up
                 U jzero_far

jdcolor.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jcopy_sample_rows
                 U jsimd_can_ycc_rgb
                 U jsimd_ycc_rgb_convert

jddctmgr.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_idct_1x1
                 U jpeg_idct_2x2
                 U jpeg_idct_4x4
                 U jpeg_idct_float
                 U jpeg_idct_ifast
                 U jpeg_idct_islow
                 U jsimd_can_idct_2x2
                 U jsimd_can_idct_4x4
                 U jsimd_can_idct_float
                 U jsimd_can_idct_ifast
                 U jsimd_can_idct_islow
                 U jsimd_idct_2x2
                 U jsimd_idct_4x4
                 U jsimd_idct_float
                 U jsimd_idct_ifast
                 U jsimd_idct_islow

jdhuff.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_natural_order

jdinput.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jdiv_round_up

jdmainct.o:

jdmarker.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_alloc_huff_table
                 U jpeg_alloc_quant_table
                 U jpeg_natural_order

jdmaster.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jdiv_round_up
                 U jinit_1pass_quantizer
                 U jinit_2pass_quantizer
                 U jinit_arith_decoder
                 U jinit_color_deconverter
                 U jinit_d_coef_controller
                 U jinit_d_main_controller
                 U jinit_d_post_controller
                 U jinit_huff_decoder
                 U jinit_inverse_dct
                 U jinit_merged_upsampler
                 U jinit_phuff_decoder
                 U jinit_upsampler

jdmerge.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jcopy_sample_rows
                 U jsimd_can_h2v1_merged_upsample
                 U jsimd_can_h2v2_merged_upsample
                 U jsimd_h2v1_merged_upsample
                 U jsimd_h2v2_merged_upsample

jdphuff.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_fill_bit_buffer
                 U jpeg_huff_decode
                 U jpeg_make_d_derived_tbl
                 U jpeg_natural_order

jdpostct.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jround_up

jdsample.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jcopy_sample_rows
                 U jround_up
                 U jsimd_can_h2v1_fancy_upsample
                 U jsimd_can_h2v1_upsample
                 U jsimd_can_h2v2_fancy_upsample
                 U jsimd_can_h2v2_upsample
                 U jsimd_h2v1_fancy_upsample
                 U jsimd_h2v1_upsample
                 U jsimd_h2v2_fancy_upsample
                 U jsimd_h2v2_upsample

jerror.o:
                 U exit
                 U fprintf
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_destroy
                 U sprintf
                 U stderr

jfdctflt.o:

jfdctfst.o:

jfdctint.o:

jidctflt.o:

jidctfst.o:

jidctint.o:

jidctred.o:

jmemmgr.o:
                 U getenv
                 U _GLOBAL_OFFSET_TABLE_
                 U jpeg_free_large
                 U jpeg_free_small
                 U jpeg_get_large
                 U jpeg_get_small
                 U jpeg_mem_available
                 U jpeg_mem_init
                 U jpeg_mem_term
                 U jpeg_open_backing_store
                 U jzero_far
                 U sscanf

jmemnobs.o:
                 U free
                 U _GLOBAL_OFFSET_TABLE_
                 U malloc

jquant1.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jzero_far

jquant2.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U jzero_far

jutils.o:
                 U _GLOBAL_OFFSET_TABLE_
                 U memcpy
                 U memset

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Fwd: Link problems with static node-canvas
  2015-06-27 22:20         ` Fwd: " piranna
  2015-06-27 22:41           ` Szabolcs Nagy
@ 2015-06-28  3:17           ` Рысь
  2015-06-28 12:51             ` piranna
  1 sibling, 1 reply; 14+ messages in thread
From: Рысь @ 2015-06-28  3:17 UTC (permalink / raw)
  To: musl

On Sun, 28 Jun 2015 00:20:06 +0200
"piranna@gmail.com" <piranna@gmail.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.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Fwd: Link problems with static node-canvas
  2015-06-27 23:10             ` piranna
@ 2015-06-28  3:23               ` Рысь
  2015-06-28 13:06                 ` piranna
  0 siblings, 1 reply; 14+ messages in thread
From: Рысь @ 2015-06-28  3:23 UTC (permalink / raw)
  To: musl

On Sun, 28 Jun 2015 01:10:23 +0200
"piranna@gmail.com" <piranna@gmail.com> wrote:

> > have you verified that
> > Release/obj.target/static/jpeg.a
> > Release/obj.target/static/freetype.a
> > have the missing symbols?
> > (eg using nm)
> 
> I have checked them with nm -u and they are defined, although as
> "undefined"... What does this means? The output tell they are
> "undefined" in the .o file that is defining them... :-/
> 
> P.D.: sorry for so much questions, this things are totally new to
> me... :-(
> 
> 

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.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Fwd: Link problems with static node-canvas
  2015-06-28  3:17           ` Рысь
@ 2015-06-28 12:51             ` piranna
  0 siblings, 0 replies; 14+ messages in thread
From: piranna @ 2015-06-28 12:51 UTC (permalink / raw)
  To: musl

> 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_

Oh cool, thank you for the trick :-)


> Sorry, but the file is zero bytes in length as reported by Dropbox.

Seems Dropbox did something bad (6 hours uploading for nothing... :-(
). Since the problem is only related to linking and not the
cross-toolchain and also happens with gcc, you can use directly my
fork of node-canvas (https://github.com/NodeOS/node-canvas), just exec
'npm install --has_cairo=false' and it will download and compile
everything, so you can be able to check 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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Fwd: Link problems with static node-canvas
  2015-06-28  3:23               ` Рысь
@ 2015-06-28 13:06                 ` piranna
  2015-06-28 18:21                   ` piranna
  0 siblings, 1 reply; 14+ messages in thread
From: piranna @ 2015-06-28 13:06 UTC (permalink / raw)
  To: musl

> 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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Fwd: Link problems with static node-canvas
  2015-06-28 13:06                 ` piranna
@ 2015-06-28 18:21                   ` piranna
  0 siblings, 0 replies; 14+ messages in thread
From: piranna @ 2015-06-28 18:21 UTC (permalink / raw)
  To: musl

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@gmail.com <piranna@gmail.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


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2015-06-28 18:21 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-26 23:06 Link problems with static node-canvas piranna
2015-06-27  6:18 ` Рысь
2015-06-27  9:41   ` piranna
2015-06-27 10:07     ` Рысь
2015-06-27 11:18       ` Szabolcs Nagy
2015-06-27 22:05         ` piranna
     [not found]       ` <CAKfGGh1DvxCjHWYpCENH3mcxDRa9LimHMCPhteoeb+4S0R5Uvg@mail.gmail.com>
2015-06-27 22:20         ` Fwd: " piranna
2015-06-27 22:41           ` Szabolcs Nagy
2015-06-27 23:10             ` piranna
2015-06-28  3:23               ` Рысь
2015-06-28 13:06                 ` piranna
2015-06-28 18:21                   ` piranna
2015-06-28  3:17           ` Рысь
2015-06-28 12:51             ` piranna

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).