* 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
[parent not found: <CAKfGGh1DvxCjHWYpCENH3mcxDRa9LimHMCPhteoeb+4S0R5Uvg@mail.gmail.com>]
* 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 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: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
* 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-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
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).