QuantamHD / LucyJS

An embeddable serverless search engine for Javascript
MIT License
4 stars 2 forks source link

compatibility in different linux systems #16

Open cancerberoSgx opened 7 years ago

cancerberoSgx commented 7 years ago

I can't install or execute tests in any debian system: https://github.com/cancerberoSgx/testing-native-node-package-docker-travis/blob/master/LucyJS-debian-report.md

I'm most worried about the case of debian jessie (LTS) in which it doesn't even install. I think it is because LucyJS has .a binaries compiled with a newer version of gcc/buildtools/libc and then it fails linking.

In other native libraries I saw, like node-sass, they compile the whole stuff. Can we do the same for lucy-js - I mean npm install should:

Generating lucy and lucy-clownfish .so files is pretty straightforward : https://github.com/cancerberoSgx/lucy.js/blob/master/scripts/build-lucy-c.sh . What I don't know is how to generate the .a files. Could you please tell me how to do it?

The other errors while executing npm test are not so serious - because in those systems I'm able to run standalone node js snippets - for some reason it fails if executing tests with jest of jasmine the same way (see the document)

QuantamHD commented 7 years ago

Sure,

The .a files aren't anything special they just take the object files generated from gcc, and then pack them into an archive file. To pack the object files run $ ar rcs lib.a $(LIST OF OBJECTS). The archive files that exist in the project right now are statically linked to the node addon for each platform. While this isn't a requirement I thought it was easier than dynamic linking for early versions of the library.

What you are proposing is fine, as long as it works on Windows and Mac. Lucy and clownfish were not made to be statically linked so it took some customization to get them to work that way. If dynamically linking the library to the node addon works for all three platforms then awesome I just couldn't figure it out which is why I created static versions.

It sounds like if we want it to work in the system I've created I would need to compile more static versions of the library.

cancerberoSgx commented 7 years ago

Thanks, I wonder if it is really necessary to work with static libraries ? I will investigate if we can instruct node-gyp to link to dynamic libraries (.so files) since those are generated by the default lucy build system.

About windows and mac - if this is not a big problem there I guess that for those we can still distribute the binaries, but in linux I guess is better to have the option of "full compilation". For example, there are systems with different libc - glibc like linux alpine for example...

QuantamHD commented 7 years ago

That makes sense as Linux systems are far more varied platforms than mac or windows. I personally compiled the Linux binary on Ubuntu 17.04

cancerberoSgx commented 7 years ago

I got stuck with this problem while trying to run tests in travis ci. There we have the possibility to do it with docker - testing several linux versions and also on macos... I think having that working for verifying commits / pullrequests will add lot of quality (and tranquility) :)

QuantamHD commented 7 years ago

Yeah, I agree. Thanks for doing that.