[th] acl & multilib

[Tomasz Mateja]

Jakub Bogusz wrote:
> On Fri, Jan 26, 2007 at 06:27:39PM +0100, Tomasz Mateja wrote:
> [...]
>> ../libme-archive  /usr/lib64/libattr.so  -m32 -mtune=ultrasparc 
>                    ^^^^^^^^^^^^^^^^^^^^^^
>> -Wl,--version-script -Wl,../exports -Wl,-soname -Wl,libacl.so.1 -o 
>> ./usr/lib64/libattr.so: could not read symbols: File in wrong format
>> collect2: ld returned 1 exit status
>>
>> Nie mam pojecia juz gdzie szukac.
> 
> Zobacz makro AC_MULTILIB (m4/multilib.m4).
> Bierze ścieżki z $CC wywołanego bez opcji.
> 

No właśnie -lattr przekazane do libtoola zmienia się na 
/usr/lib64/libattr.so w wywołaniu gcc

AC_MULTILIB to chyba zły strzał.
w configure.in:

AC_ARG_ENABLE(lib64,
[ --enable-lib64=[yes/no] Enable lib64 support [default=no]],,
         enable_lib64=no)
AC_SUBST(enable_lib64)

i dalej:
AC_MULTILIB($enable_lib64)

a w samym makro jest warunek:
if test "$enable_lib64" = "yes" -a -n "$searchpath"

Więc nie zachodzi by default niezależnie od parametrów gcc, jakkolwiek 
te parametry nie są potrzebne, makro sprawdza czy istnieją ścieźki 
kończące sie na lib64 - w obu przypadkach (-m32 i -m64) istnieją - ale 
to tylko jeden z warunków if-a.

configure tworzy plik include/builddefs w którym jak pisałem ścieżki 
wyglądają poprawnie. Plik ten includowany jest w Makefile'ach i zawiera 
takie wpisy jak:
OPTIMIZER = -O2 -m32 -mtune=ultrasparc  -DENABLE_GETTEXT
LIBATTR = /usr/lib/libattr.la
PKG_LIB_DIR     = /lib
PKG_DEVLIB_DIR  = /usr/lib

wiec wyglada na ok zwlaszcza ze w builddefs.in jest:
LIBATTR = @libattr@
PKG_LIB_DIR     = @libdir@@libdirsuffix@
PKG_DEVLIB_DIR  = @libexecdir@@libdirsuffix@

a w package_attrdev.m4 jest:
     test -f ${libexecdir}${libdirsuffix}/libattr.la && \
         libattr="${libexecdir}${libdirsuffix}/libattr.la"
     AC_SUBST(libattr)

Na moj obecny stan wiedzy wyglada good ale nie działa - nie wiem czemu a 
o magii nie wiem za wiele ;)

-- 
T.