Fix file permissions for shared library installation

[sebastiangrimberg]

TODO: Based on #1244.

In most cases, shared libraries have executable permissions so this updates the make install for this.

https://www.gnu.org/software/libc/manual/html_node/Running-make-install.html
https://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html

[jedbrown]

The shared library permissions convention depends on the distribution and while +x shared libraries are common, I find it hard to argue with the Debian rationale:

Shared libraries should not be installed executable, since the dynamic linker does not require this and trying to execute a shared library usually results in a core dump.

There are some libraries that are meant to be executed and only those libraries are installed with execute permissions on Debian.

$ ls -l /usr/lib/x86_64-linux-gnu/libc.so.6
-rwxr-xr-x 1 root root 1922136 Apr 10 02:35 /usr/lib/x86_64-linux-gnu/libc.so.6
$ /usr/lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Debian GLIBC 2.36-9) stable release version 2.36.
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 12.2.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
Minimum supported kernel: 3.2.0
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

Is our use of this convention causing a problem? Note that we could make an entry point so libceed.so can be executed to print some configuration details like above, but I think installing ceed.pc or even a $prefix/bin/ceed-config would be better (including working with static libraries).

[sebastiangrimberg]

Thanks for the background information on this convention, I was not aware and did not know if it was an intentional decision here or not.

No, it definitely doesn't cause any problems. On all the systems I've been building on, the library built by gcc -shared or equivalent for clang, etc. has +x permissions and so I found it odd to remove them when installing the library. Maybe another approach if it is system dependent would be to just not modify permissions on install, but I'm not an expert here. I fully realize this is a pedantic point as it is not causing any issues, so I am just glad to have an explanation!

[jedbrown]

So gcc -shared and clang -shared on Debian also produce +x, I assume for legacy reasons. I guess we could leave it to Debian to remove those, but I just don't see any point in having them be executable when it can't be executed. We need to specify the permissions (and install always does) because some people have umask 077 and you don't want that to yield an install that's broken for others.

[sebastiangrimberg]

Makes perfect sense! Thanks for the background info and I will just close this PR.