Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trouble cross-compiling #125

Closed
makew0rld opened this issue Apr 10, 2020 · 12 comments
Closed

Trouble cross-compiling #125

makew0rld opened this issue Apr 10, 2020 · 12 comments

Comments

@makew0rld
Copy link

makew0rld commented Apr 10, 2020

On this line, the compilation of this package is configured. If the --host parameter could be specified, then I would be able to cross compile the package.

For example, the line could read something like:

  spawn('./configure', ['--prefix=' + tmp, '--host=' + host], { cwd: __dirname, stdio: 'inherit' }, function (err) {

When I tried this with --host=arm-linux-gnueabihf, to compile for the armhf arch (with this debian pkg installed), the compiling of libsodium worked, but the overall installation failed on a make related step. Here's the log:

make[1]: Leaving directory '/root/sodium-native/libsodium'
make: Entering directory '/root/sodium-native/build'
  CC(target) Release/obj.target/sodium/binding.o
  SOLINK_MODULE(target) Release/obj.target/sodium.node
/usr/bin/ld: /root/sodium-native/lib/libsodium-x64.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make: *** [sodium.target.mk:149: Release/obj.target/sodium.node] Error 1
make: Leaving directory '/root/sodium-native/build'
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:310:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Linux 5.5.13-arch2-1
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /root/sodium-native
gyp ERR! node -v v12.16.2
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok 
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! sodium-native@3.0.1 install: `node-gyp-build "node preinstall.js" "node postinstall.js"`
npm ERR! Exit status 1

I believe this is happening because /usr/bin/ld is used, instead of arm-linux-gnueabihf-ld. I realize this may be out of scope for this repo, but I've seen other issues like #119 mention compiling for platforms like Android, and so I'm wondering if the maintainers here would know how to fix this issue.

How can I tell make to use the correct linker, and probably the correct version of other tools?

@emilbayes
Copy link
Collaborator

This is because the preinstall.js script first compiles libsodium as a shared library. We'd have to work out how to make libsodium cross compile also then :)

@emilbayes
Copy link
Collaborator

I guess you could probably try this already now: https://doc.libsodium.org/installation#cross-compiling

@emilbayes
Copy link
Collaborator

Ah sorry, rereading above, it's node-gyp that you'd need to mess around with. We've tried a couple of times without luck, which is why we manually build armv7l on each release

@makew0rld
Copy link
Author

Yeah, the cross compiling of libsodium works fine, it's the linking of this repo that causes issues.

How are you building those releases? Thanks for quick reply.

@emilbayes
Copy link
Collaborator

We build them on actual hardware

@makew0rld
Copy link
Author

makew0rld commented Apr 11, 2020

Do you think it'd be possible for you guys to build arm64, armel releases as well?

@emilbayes
Copy link
Collaborator

We don't have the hardware unfortunately. armv7l is only because we support a number of production systems running on RPis

@makew0rld
Copy link
Author

Alright, thanks anyway. I and some others have been looking into using qemu to emulate the arches we want, and compiling there.

@mafintosh
Copy link
Contributor

If you figure it out, let us know :)

@makew0rld
Copy link
Author

If you want to follow this issue that might be worthwhile. Also checkout some scripts that are linked there, we're testing them for Raspberry Pi compiling right now. I will try to update here as well once a general solution has been found.

@emilbayes
Copy link
Collaborator

We have had luck with qemu in the past, it was just prohibitively slow

@kasperisager
Copy link
Contributor

This should be solved by #174 and #175.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants