Linux bin execution error

[amsXYZ]

When calling your package from a JS script, I get the following error on linux (Ubuntu 16.04.6):

Error: Command failed: /mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/msdf-bmfont-xml/bin/linux/msdfgen.linux msdf -format text -stdout -size 11 16 -translate 2 26 -pxrange 8 -defineshape "{2.4, -13.664; 1.92, -22.048; 5.088, -22.048; 4.608, -13.664; 2.4, -13.664; }"
/mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/msdf-bmfont-xml/bin/linux/msdfgen.linux: 9: /mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/msdf-bmfont-xml/bin/linux/msdfgen.linux: Syntax error: ")" unexpected

(node:61) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'slice' of undefined
    at MaxRectsPacker.sort (/mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/maxrects-packer/src/maxrects_packer.ts:125:22)
    at MaxRectsPacker.addArray (/mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/maxrects-packer/src/maxrects_packer.ts:70:14)
    at mapLimit (/mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/msdf-bmfont-xml/index.js:174:12)
    at f (/mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/map-limit/node_modules/once/once.js:17:25)
    at abort (/mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/map-limit/index.js:38:12)
    at /mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/map-limit/index.js:47:23
    at generateImage (/mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/msdf-bmfont-xml/index.js:166:23)
    at exec (/mnt/c/Users/ext_valencia.and/Dev/harp-font-resources/node_modules/msdf-bmfont-xml/index.js:329:21)
    at ChildProcess.exithandler (child_process.js:296:5)
    at ChildProcess.emit (events.js:182:13)

Any idea of why this might be happening? Only happens locally, and runs fine on a xenial docker image.

[soimy]

Sorry, no way to reproduce this currently.
Take a look at cli.js for example usage.
@amsgames94 Can you try

msdfgen.linux msdf -format text -stdout -size 11 16 -translate 2 26 -pxrange 8 -defineshape "{2.4, -13.664; 1.92, -22.048; 5.088, -22.048; 4.608, -13.664; 2.4, -13.664; }"

in terminal and get some feedback?

[amsXYZ]

I actually cannot run it from terminal... Getting exec format error, even though arch of my VM and the program is the same (x86-64):

$ arch
x86_64
$ file msdfgen.linux
msdfgen.linux: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.6.32, BuildID[sha1]=48e0bf17683cfabd5614f52eaa28ff79d61c7a29, not stripped
$ ./msdfgen.linux msdf -format text -stdout -size 11 16 -translate 2 26 -pxrange 8 -defineshape "{2.4, -13.664; 1.92, -22.048; 5.088, -22.048; 4.608, -13.664; 2.4, -13.664; }"
-bash: ./msdfgen.linux: cannot execute binary file: Exec format error

Could it be because it's been compiled as a shared object? Both the OSX and Win32 version of the same file are executables:

$ file darwin/msdfgen.osx
darwin/msdfgen.osx: Mach-O 64-bit x86_64 executable
$ file win32/msdfgen.exe
win32/msdfgen.exe: PE32 executable (console) Intel 80386, for MS Windows

[soimy]

All shared objects are localized with edited ELFs.
I think a quick way to solve your problem is to compile msdfgen.linux yourself. See #17 (comment)

[zellm]

I see the same issue (cannot execute binary file: Exec format error) on WSL/Ubuntu 18.04. But there is something odd but I am not sure whether this is related to the problem. Since

file msdfgen.linux
msdfgen.linux: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.6.32, BuildID[sha1]=48e0bf17683cfabd5614f52eaa28ff79d61c7a29, not stripped

showed binary is "not stripped", I run strip just to see what happens and I got an error:

strip msdfgen.linux
strip: stGyGj8o: Not enough room for program headers, try linking with -N
strip:stGyGj8o[.interp]: Bad value

Strip is failing with exactly the same error message on a native Ubuntu although the binary itself is running there without a problem. Could it be that the ELF structure of msdfgen.linux is broken? I did a quick check with readelf but did not spot anything unusual yet.

[soimy]

@zellm Might related to this NixOS/patchelf/issues/10
Will dig.

[ninok]

@amsgames94, @zellm, @soimy I had the same issue and build msdfgen from latest mainline and it works. (also strip is working).
Should I create a PR with the updated binary I build?

[soimy]

PR really welcomed!
@ninok Can you try to use patchelf to localize the following shared libraries:

• libfreetype.so.6
• libpng16.so.16
• libstsdc++.so.6
• libz.so.1

I've tried to build them in my new linux vm but having hard time get the binary working with TravisCI.

[ninok]

PR is here: #37 but Travis is also failing for me: https://travis-ci.org/soimy/msdf-bmfont-xml/builds/534678791?utm_source=github_status&utm_medium=notification

Can you point me to how I have to patch the binary with patchelf. I tried the following but the libraries did not change:

$ patchelf --replace-needed /usr/lib/x86_64-linux-gnu/libfreetype.so.6 ./lib/libfreetype.so.6 msdfgen.linux
$ ldd msdfgen.linux
        linux-vdso.so.1 (0x00007ffff0d05000)
        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fdc088d0000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdc08540000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdc081a0000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdc07f80000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdc07b80000)
        libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007fdc07940000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fdc07710000)
        lib/libfreetype.so.6 => /lib64/ld-linux-x86-64.so.2 (0x00007fdc09000000)

Could we not just take the libraries from the system and update the ones used in Travis?

[soimy]

Thanks for the effort!
I used patchelf --set-rpath '$ORIGIN\lib' msdfgen.linux and put all shared libraries in the lib folder to make them locally.
But gcc toolchain is a bit hard to make right. Let's try.

[ninok]

Sorry for the delayed answer. I tried to set the rpath but I also get a corrupted binary file.
Might be the same issue as described here: NixOS/patchelf#146
My Ubuntu 18.04 WSL comes with patchelf 0.9. l will try with a newer version and post results soon.

[ninok]

Unfortunately building latest patchelf from source did not help. So we have to wait until NixOS/patchelf#146 is fixed or upgrade CI to use Ubuntu 18.04.

[soimy]

@ninok Thanks for the effort! Let's follow the progress of patchelf fix that problem. For now I think I should update the README for an FAQ on compiling msdfgen.