FS#39560 - [mkinitcpio] bug in the function add_binary
Attached to Project:
Arch Linux
Opened by jim945 (jim945) - Thursday, 20 March 2014, 21:16 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 April 2014, 17:59 GMT
Opened by jim945 (jim945) - Thursday, 20 March 2014, 21:16 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 April 2014, 17:59 GMT
|
Details
Not create recursive symlinks.
Example. /usr/lib/libEGL.so.1 -> libEGL.so.1.0.0 /usr/lib/libEGL.so.1.0.0 -> /usr/lib/mesa/libEGL.so.1.0.0 |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 05 April 2014, 17:59 GMT
Reason for closing: Fixed
Additional comments about closing: https://projects.archlinux.org/mkinitcpi o.git/commit/?id=d90c1fb02faa0a5aeca6410 a72d52d53ddf2455e
Saturday, 05 April 2014, 17:59 GMT
Reason for closing: Fixed
Additional comments about closing: https://projects.archlinux.org/mkinitcpi o.git/commit/?id=d90c1fb02faa0a5aeca6410 a72d52d53ddf2455e
You're right that the logic in add_binary surrounding symlinks is a little strange, though.
I'm surprised ldconfig is okay with this.
Shouldn't add_file simply resolve symlinks recursively until it hits the real file? Or, alternatively, shouldn't we just ignore symlinks entirely in add_binary or add_file and just dereference during the copy ('install' has no option for this, sadly)?
I'm opting out of this discussion -- it's not going to lead to anything useful.
> Shouldn't add_file simply resolve symlinks recursively until it hits the real file? Or, alternatively, shouldn't we just ignore symlinks entirely in add_binary or add_file and just dereference during the copy ('install' has no option for this, sadly)?
The latter. add_binary can probably be fixed as simply as:
- add_symlink "$sodep" "$(readlink "$sodep")"
+ add_symlink "$sodep" "$resolved"
add_file doesn't need to be fixed -- install already dereferences symlinks.
Then why bother with symlinks at all?
if [[ -f $sodep && ! -e $BUILDROOT$sodep ]]; then
add_file "$sodep" "$sodep" "$(stat -Lc %a "$sodep")"
fi
This should "just work". Is there a special reason why /usr/lib/$SONAME must be symlink to /usr/lib/$SONAME.a.b where a.b is some arbitrary magic version number?
You make an interesting observation though -- because we run ldconfig on the image, we can use that to generate the right symlinks and add_binary can just add the resolved lib.
edit: or not, since mesa decides to use some dir other than /usr/lib.