Symlink 7z when USE_SYSTEM_P7ZIP

[haampie]

It seems like a symlink to 7z was missing from <julia prefix>/libexec/ upon install with system p7zip. Normally it's installed from build_bindir, so this PR creates a symlink to system 7z in that build dir.

In any case, it seems convenient to have a symlinked 7z like we symlink system libs, so that 7z doesn't have to be in the PATH when running julia.

I'm pretty sure this PR needs some improvement, I have no clue if $(shell which 7z...) is OK (in particular with $(EXE) :D).

I did not add code to follow symlinks like is done for shared libs (it seems resolve_path is intended for libraries)

[ViralBShah]

This one may need @staticfloat to look at it.

[staticfloat]

What's the usecase for this? When you run USE_SYSTEM_XYZ=1, you're basically declaring that you don't want your Julia to be redistributable, so you shouldn't need to care about the environment changing. Are there tools that try to directly open libexec/7z and fail?

[haampie]

Hi Elliot, I do care about keeping a fixed environment, as I'm building Julia with Spack, meaning there is a very specific install of p7zip for Julia, in its own prefix dir, and this prefix is not in the PATH at runtime by default.

Of course I can symlink 7z after make install in the Spack recipe, but it looks to me the missing symlink for 7z was an oversight / exception, given that Julia symlinks all system libraries by default. If Julia fixes system libs by symlinking them so that they aren't influenced by LD_LIBRARY_PATH, then why not fix executables by symlinking them so that they aren't influenced by PATH.

Also for troubleshooting builds or development, it would not hurt to have the symlink already in the in-tree build

[staticfloat]

Yeah, that totally makes sense. Thanks for giving the motivation so clearly!

[haampie]

Thanks for the review! Should this be backported like #43000? It could be seen as a fix for a build issue

[staticfloat]

@haampie have you tried this branch with your usecase to ensure that it works? If so, as long as CI is green, I think this is good to merge and to backport.

[haampie]

I'll verify it works for me tomorrow!

[haampie]

Works well for me!

[nalimilan]

I had missed this change, but it seems problematic to me. Julia shouldn't install a file called 7z in /usr/libexec, as it's going to pollute that directory. If several programs do that they are going to conflict. If we really want this, I think it should rather be in a libexec/julia subdirectory, just like we do for libraries under lib/julia.

In practical terms, I have to manually remove this link to build the Fedora package to avoid this.

(BTW, I don't think it should have been backported at this stage as it's really a new feature, not a fix.)

[haampie]

I missed this comment. You mean you're running make install with prefix=/ and it clashes with /usr/libexec/7z? (who installs 7z there apart from julia?) My issue was that when prefix is anything other than /, p7zip_jll may not find the 7z executable. I requested a backport, since it looked like an oversight: we have symlinks for system libs, but not for libexec/7z)

[staticfloat]

Placing it in libexec/julia would be a reasonable fix.

[nalimilan]

You mean you're running make install with prefix=/ and it clashes with /usr/libexec/7z? (who installs 7z there apart from julia?)

My concern is more theoretical: as a packager, I'm not supposed to install to system directories files whose name may conflict with other apps. Given that 7z is a popular app, it's totally possible that another package would have the same needs as Julia, and if both install a file to /usr/libexec we will have conflicts.