Re: symlink loop for /lib64/libhandle.so

["Jan Ťulák" <jan@tulak.me>]

On Thu, 2014-07-10 at 11:40 -0500, Eric Sandeen wrote:
> Here's what the current RPM build does; I don't claim that it's elegant or
> beautiful:
> 
> %install
> rm -rf $RPM_BUILD_ROOT
> make V=1 DIST_ROOT=$RPM_BUILD_ROOT install install-dev install-qa \
>         PKG_ROOT_SBIN_DIR=%{_sbindir} PKG_ROOT_LIB_DIR=%{_libdir}
> 
> so that sounds like what you're doing, too.

I think I found it. In short: On Fedora, /lib64 is a symlink
into /usr/lib64, but "install/buildmacros" script thinks it as two
different directories and mess it. Proposed solution: better condition
on line 79 to avoid symlink changes.


Long version:

I looked for the variables and maybe found something more in files
"include/buildmacros" and "install-sh". In the buildmacros file on line
around 80 is command:

../$(INSTALL) -S $(PKG_ROOT_LIB_DIR)/$(LIBNAME).so
$(PKG_LIB_DIR)/$(LIBNAME).so; 

It is invoked just once and its arguments are  [/lib64/libhandle.so] and
[/usr/lib64/libhandle.so] (in this order). This is at the end translated
into this call in "install-sh" on line 172:

ln -s -f /lib64/libhandle.so //usr/lib64/libhandle.so 


It seems to be OK, , but when I put a "ls -li" before and after this
command on line 172, this is what I got (I just added few echos):

 ---------------- 
before:
1668 lrwxrwxrwx. 1 root root 14 Jul 11 10:36 /lib64/libhandle.so ->
libhandle.so.1
1668 lrwxrwxrwx. 1 root root 14 Jul 11 10:36 //usr/lib64/libhandle.so ->
libhandle.so.1
......
ln -s -f /lib64/libhandle.so //usr/lib64/libhandle.so 
......
after:
1668 lrwxrwxrwx. 1 root root 19 Jul 11 10:36 /lib64/libhandle.so
-> /lib64/libhandle.so
1668 lrwxrwxrwx. 1 root root 19 Jul 11 10:36 //usr/lib64/libhandle.so
-> /lib64/libhandle.so
 -----------

Then I have done "ls -l /" and found the reason:
lrwxrwxrwx.   1 root root     9 Dec 12  2013 lib64 -> usr/lib64

So the loop is because on Fedora, /lib64 and /usr/lib64 are the same
directory. The "buildmacros" script does some check before doing the
symlinking, but it just checks the paths as strings. I think that a
better condition on line 80 of "include/buildmacros" file should fix it.
I tried to make a new condition and it works, but I'm not sure about
portability of using the "$(shell ...)" extension of GNU Make. Is there
some more portable way how to do it and keep the condition short?

Proposed condition:

if test "x$(PKG_LIB_DIR)" != "x$(PKG_ROOT_LIB_DIR)"\
-a "x$(shell readlink -f $(PKG_ROOT_LIB_DIR))" != "x$(PKG_LIB_DIR)"\
-a "x$(shell readlink -f $(PKG_LIB_DIR))" != "x$(PKG_ROOT_LIB_DIR)";\ 
then \

Instead of:

if test "x$(PKG_LIB_DIR)" != "x$(PKG_ROOT_LIB_DIR)"; then \


And by the way: It seems to me that the command on line 83 in
"buildmacros" has swapped arguments. In two other symlinks around,
PKG_LIB_DIR and PKG_ROOT_LIB_DIR for .a and .la files are in other
order. Is this all right?


Jan Tulak



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs