Compile core against GLIBC < 2.18

[naraesk]

I used this version on Arch Linux: https://github.com/turtl/desktop/releases/download/v0.7.0-rc3/turtl-linux64.tar.bz2

$ sudo ./install.sh 
Copying Turtl to install directory (/opt/turtl)...
find: paths must precede expression: chmod
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]
find: paths must precede expression: chmod
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]
chmod: cannot access 'turtl-bin': No such file or directory
chmod: cannot access 'lib/*': No such file or directory
chmod: cannot access 'chromedriver': No such file or directory
chmod: cannot access 'nw': No such file or directory
chmod: cannot access 'payload': No such file or directory
chmod: cannot access 'nacl*': No such file or directory
chmod: cannot access 'pnacl/*nexe': No such file or directory
All done! Turtl has been installed in /opt/turtl/. To run:
  /opt/turtl/turtl

To uninstall, run:
  ./install.sh uninstall

Well, script says installation has been successful and /opt/turtl has been created and has files in it. But was it really successful? When running /opt/turtl/turtl I just get a white screen, the same as posted by Marrie on twitter: https://twitter.com/turtlapp/status/1025839719706284032

[matthewn]

I have the exact same results on Ubuntu 18.04.

[orthecreedence]

Thanks for reporting, I will take a look at this!

[peakgeek]

Same issue on Elementary OS 5.0 Beta

Also tried the msi installer on a Windows 10 Pro 64-bit machine and it installs, but then opens to an empty window with a broken image in the top left corner.

[orthecreedence]

Note that this should be working now, but I'm going to try and fix #129 before releasing another RC.

[orthecreedence]

The new RC4 is out, would love if anybody wanted to give it another try: https://github.com/turtl/desktop/releases/tag/v0.7.0-rc4. @peakgeek I believe the windows issue is fixed in RC4 as well (confirmed and tested on one of my windows machines).

[aptmiguk]

The RC4 build installs without error. However, I'm getting a blank screen on startup now. Did dependencies change or anything? I'm on CentOS 7; no issues on stable build.

[naraesk]

For me it works now, thanks!

[orthecreedence]

@aptmiguk do you have openssl installed? The fix for #129 was to bundle the ssl shared libs with the install, now I'm wondering if I should do the same on the linux builds.

[aptmiguk]

@orthecreedence , here is what's installed:

yum list installed *ssl*
openssl openssl-devel openssl-libs perl-Crypt-SSLeay perl-IO-Socket-SSL perl-Net-SSLeay pyOpenSSL python-backports-ssl_match_hostname xmlsec1-openssl

[orthecreedence]

@aptmiguk Odd, you have everything I'd expect would make it work. The problem with that "no turtl logo" issue is that it doesn't give a clear message as to what failed. Bundling the ssl libs took me a while to figure out.

Can you open it up again and do ctrl+shift+k and let me know if it is giving a useful error?

[aptmiguk]

@orthecreedence , Good call. See attached. I guess it's a version issue?

rpm -qf /lib64/libc.so.6 glibc-2.17-222.el7.x86_64

[orthecreedence]

https://stackoverflow.com/questions/39744926/how-can-i-compile-a-rust-program-so-it-doesnt-use-cxa-thread-atexit-impl

^ Looks like a good starting point, and I've confirmed the only GLIBC 2.18 symbol is __cxa_thread_atexit_impl. I can try to take a look at this tonight. Do you know what version of glibc you have?

[aptmiguk]

In this thread: https://github.com/turtl/tracker/issues/128#event-1778274961

rpm -qf /lib64/libc.so.6 glibc-2.17-222.el7.x86_64

Thanks!!

[orthecreedence]

Hey @aptmiguk , can you put the attached libturtl_core.linux64.so file into your local install (/path/to/turtl/resources/app/build/libturtl_core.so) and test it out? I rebuilt my build machine on an older version of debian (I actually wanted to move the build system to docker anyway, so you gave me a good excuse) which has an older glibc (2.13 i think). Hopefully it works. If so, I'll use the new build system for the RC5 build.

libturtl_core.linux64.zip

SHA256: f242e8be58171d41fda1e1c4a5ee17b6e9f1e6e77c12031e12f59c8fa0c4347a

Thanks!

[aptmiguk]

@orthecreedence , I did put the file where you said to... however, now I'm plagued with this: https://github.com/turtl/tracker/issues/134

Sorry that was tested with Fedora. I'll post back with specifics on CentOS.

[aptmiguk]

@orthecreedence , Fedora works with all the fixes. However, with CentOS 7 I'm still getting the same error (in the screenshot) as before. I used rc4, added the zip's file from your post, added the cacert.pem to apps/turtl/resources/app/scripts/resources/, and put in the new _functions.js and core.js.

Did I miss anything or put something in the wrong spot?

[orthecreedence]

No you put it in the right spot. I guess I should have read more about this before stampeding forward. My understanding was that if I recompile Turtl core with rust on a system that has an older glibc, that library will work when running on the older system. My understanding was incorrect, and apparently I have to compile rustc itself against the older glibc, then use that rust to compile Turtl core.

Given that I'd have to set up and automate this process on two separate architectures (x86_64, i386) I think this is out of scope for the v0.7.0 release. I'm going to keep this issue open and depending on how many linux users are on < GLIBC=2.18 and have problems running, I'll consider updating the build process to include a custom rustc.

[orthecreedence]

Also, I'm adding the help-wanted tag...if anyone wants to get me a Dockerfile that automates this for me, I'll gladly include that into the build system.