gcc-libgcc installation fails on x86_64

[ojab]

....
=> Preparing gcc subpackage: gcc-libgcc
mv: cannot stat `/home/ojab/xbps/destdir/gcc-4.4.1/usr/lib/libgcc_s.so*': No such file or directory
=> ERROR: gcc-libgcc do_install stage failed!
$ find /home/ojab/xbps/destdir/ -iname libgcc_s.so*
/home/ojab/xbps/destdir/gcc-4.4.1/usr/lib64/libgcc_s.so
/home/ojab/xbps/destdir/gcc-4.4.1/usr/lib64/libgcc_s.so.1

xbps should somehow get rid of lib64 or correctly use lib/lib64 on x86_32/x86_64.

[Juan RP (xtraeme)]

True, I knew about this problem and in the past I had changed all build templates to use $LIBDIR that had "lib64" value on x86_64.
I'm still not sure how to handle /lib /lib64 on x86_64.

From what I read it seems the correct way is to always use /lib64 and make /lib a symlink of it. Could you try to add in
$(prefix)/share/xbps/shutils/{configure,build,install}_funcs.sh code to use that? you'll also need to use $LIBDIR in build templates
that hardcode /lib, something like:

if [ "$xbps_machine" = "x86_64" ]; then
    LIBDIR="/lib64"
else
   LIBDIR="/lib"
fi

LIBDIR must be set in tmpl_func.sh:set_tmpl_common_vars() much like FILESDIR and PATCHESDIR are set.

For package using build_style=gnu_configure, you'll also need to use maybe "--libdir=$LIBDIR".

I know it's a hard task, but can't really test on x86_64 right now.

[Juan RP (xtraeme)]

Another solution that maybe works and that should save some work is to use always /lib and make /lib64 a symlink of it.
That way the build templates do no need to be modified.

Comments?

[ojab (ojab)]

It's not system issue, but template issue. For example, binutils-devel template:
    mv ${SRCPKGDESTDIR}/usr/lib/${f}.*a ${DESTDIR}/usr/lib
but libiberty.a is located in ${SRCPKGDESTDIR}/usr/lib64/. Fix is attached.

Also xbps doesn't break after 'No such file or directory' error (i think it's also should be fixed).

[Juan RP (xtraeme)]

Thanks for the patch. To break after such errors the function must return a non zero value, not all build
templates have been modified, but they should sooner or later.

BTW, I see in your patch that you used sed and mv while you can do both with " sed -i ".

[ojab (ojab)]

The most appropriate solution, I think.

[ojab (ojab)]

Instead of many sed -i (for example at least six in gcc case) it's possible to create /usr/lib64 -> /usr/lib symlink in ${SRCPKGDESTDIR}.

Please also commit glibc patchadopted from http://sourceware.org/git/?p=glibc.git;a=commit;h=4c14c8c348ee3e9a5fea3608cabcabdb275b6141.

[Juan RP (xtraeme)]

I applied the patch for glibc with binutils-2.20.

Also I committed a modified patch for gcc/binutils, but conditionalized for x86_64. Try "git pull" and let me know if
the bug is fixed and I'll close it.

Thanks for the patches!

[ojab (ojab)]

/usr/lib symlink should be in ${SRCPKGDESTDIR}, not in ${DESTDIR}

[Juan RP (xtraeme)]

Committed, thanks!

BTW, didn't you have problems with ncurses-libs on x86_64?
I remember that I had to add CFLAGS="-fPIC -DPIC" in the past...