XInitThreads is not called in imagej-launcher for linux64

[kephale]

If you run the latest ImageJ-linux64 with --debug, then you will notice that
Running XInitThreads
Does not show up in the log.

Presumably there is an issue with the #define of __linux__ but it isn't super obvious where this is missing.

[kephale]

Ok, so it seems as though the ImageJ-linux64 that is being shipped in this package https://downloads.imagej.net/fiji/latest/fiji-linux64.zip was not built with __linux__ defined. Is there a chance someone built it with cygwin or something?

[kephale]

I will also point out that: https://maven.scijava.org/service/local/repositories/snapshots/content/net/imagej/imagej-launcher/6.0.3-SNAPSHOT/imagej-launcher-6.0.3-20201117.205912-15-linux64.exe (the latest linux64 launcher currently on maven.scijava.org) does run the XInitThreads call. So it looks like something is wrong with the launcher that is packaged with Fiji

[kephale]

We're resolving this on the sciview-buttercup update site by shipping the correct ImageJ-linux64 binary linked in the previous message.

[hinerm]

thanks for looking into this @kephale.

Does the deployed 6.0.2 linux64 exe correctly make the XInitThreads call? 0c39026 is the only commit after 6.0.2 and it seems like that would be odd to "fix" the problem. If it works, I would take the 6.0.2 release over the 6.0.3 snapshot.

@ctrueden I think if Maven's 6.0.2 linux64 launcher works we should just upload it to Java-8. I checked and it is different than what's currently uploaded, and I'm not sure why...

[ctrueden]

The version of the ImageJ-linux64 launcher shipped on the Java-8 update site (and thus bundled in the zip) is "ImageJ launcher 4.0.5 (build 1260)" (from ./ImageJ-linux64 --help output). This is very old. But every time we try to update it, we break someone's computer. There is an update site "Launcher-6-test" with newer launcher binaries. The first release of the launcher to include the XInitThreads fix is 5.0.1.

See also this Image.sc Forum thread.

I'm sorry we haven't been able to update the shipped version of the launcher in so long. We have other priorities at the moment (PyImageJ paper, SciJava 3/Ops release, Maven-aware update sites), but I expect we'll revisit the whole Java-11 can of worms (of which the launcher is a part) by mid-2022.

[ctrueden]

@hinerm wrote:

I think if Maven's 6.0.2 linux64 launcher works we should just upload it to Java-8.

That would be a huge upgrade from 4.0.5 to 6.0.2. Your aforementioned forum thread from a year ago had a lot of back and forth about problems with the new launcher. Do you feel the current launcher code has ironed out all the problems raised by the community (specifically @haesleinhuepf, @bogovicj, @phaub, @imagejan)? If so, we can go ahead and upload. Or if not, I guess we still have more work to do...

[ctrueden]

Another option would be to set up ImageJ-11 and Fiji-11 update sites on sites.imagej.net, intended for at least Java 11, and completely separate from the current Java-8-based site, and ship the 6.x launcher only on the ImageJ-11 site. This would allow us to start providing Java-11-based downloads. But we'd have to make decisions about how far to go with maintaining parallel versions of things.

[kephale]

@hinerm yes, the fix for us is to ship the 6.0.2 launcher for linux64 on sciview-buttercup. Otherwise sciview does not work in Fiji on linux64 at all.

[hinerm]

Do you feel the current launcher code has ironed out all the problems raised by the community

@ctrueden no I think if we didn't upload a 6.x before there was a good reason for it. I didn't realize it was shipping 4.x still - the idea of replacing the launcher with the latest was only if the problem was actually that I manually built an erroneous 6.x locally.

Edit: forum post for reference

[ctrueden]

I only skimmed the forum thread today, but it was not clear to me that there are still showstopping problems with the 6.x launcher builds. @hinerm Are you able to make that judgment? If you aren't sure of concrete reasons to hold off on updating it, we will need to evaluate it again. We can ask the same folks to test again if needed. Or if we do know the concrete reason(s), we should discuss how/whether those issues can be addressed technically.

[bogovicj]

@hinerm , @ctrueden

We can ask the same folks to test again if needed.

Yes, do it. I'm happy to test things.