[OpenAFS-devel] Re: Building OpenAFS on SmartOS

[Coy Hile]

I=92m making a bit more progress here; I=92ve gotten everything to build =
on a 64bit SmartOS image without issue, but I am running into issues =
building on the particular VM image that SmartOS requires for building =
its kernel/platform.  That image, as documented =
http://wiki.smartos.org/display/DOC/Building+SmartOS+on+SmartOS , is a =
multi-arch image

No matter what I do, on that particular image, I get down through the =
build to this area, and everything goes south:

set -x; \
case sunx86_511 in \
sun4x_5[789] | sun4x_510 | hp_ux11* | sunx86_5[789] | sunx86_510 )  \
        make kdump64.o ; \
        gcc -m64 -o kdump64 kdump64.o /home/hile/openafs/lib/libcmd64.a =
-lelf -lkvm -lresolv  -lsocket -lnsl -lintl -ldl ;; \
esac
make[4]: Leaving directory `/home/hile/openafs/src/venus'
touch kdump-build
gcc -m64  -O -m64  -I/home/hile/openafs/src/config =
-I/home/hile/openafs/include -I. -I.       -o cacheout.o -c cacheout.c
gcc  -L/home/hile/openafs/lib -L/home/hile/openafs/lib  -O  -m64  -m64  =
-O -m64  -I/home/hile/openafs/src/config -I/home/hile/openafs/include =
-I. -I.       -o cacheout cacheout.o /home/hile/openafs/lib/libsys.a =
/home/hile/openafs/lib/libvldb.a /home/hile/openafs/lib/libubik.a =
/home/hile/openafs/lib/vlib.a /home/hile/openafs/lib/libauth.a =
/home/hile/openafs/lib/librxkad.a /home/hile/openafs/lib/libafscom_err.a =
/home/hile/openafs/lib/libcmd.a /home/hile/openafs/lib/libkauth.a =
/home/hile/openafs/lib/librx.a /home/hile/openafs/lib/libsys.a =
/home/hile/openafs/lib/liblwp.a /home/hile/openafs/lib/libaudit.a =
/home/hile/openafs/lib/libafsutil.a /home/hile/openafs/lib/libopr.a =
/home/hile/openafs/lib/libafsrfc3961.a =
/home/hile/openafs/lib/libafshcrypto_lwp.a  -lrokenafs -lresolv  =
-lsocket -lnsl -lintl -ldl /home/hile/openafs/lib/libsys.a =
/home/hile/openafs/lib/libafsint.a /home/hile/openafs/lib/librxkad.a =
/home/hile/openafs/lib/libauth.a /home/hile/openafs/lib/libafscom_err.a =
/home/hile/openafs/lib/libcmd.a /home/hile/openafs/lib/librx.a =
/home/hile/openafs/lib/libsys.a /home/hile/openafs/lib/liblwp.a =
/home/hile/openafs/lib/libopr.a /home/hile/openafs/lib/libafsutil.a
gcc -m64  -O -m64  -I/home/hile/openafs/src/config =
-I/home/hile/openafs/include -I. -I.      -pthread -DAFS_PTHREAD_ENV  -o =
afsio.o -c ./afsio.c
gcc -m64  -O -m64  -I/home/hile/openafs/src/config =
-I/home/hile/openafs/include -I. -I.      -pthread -DAFS_PTHREAD_ENV  -o =
afscbint.ss.o -c ../fsint/afscbint.ss.c
/bin/sh ../../libtool --quiet --mode=3Dlink --tag=3DCC gcc -static  =
-L/home/hile/openafs/lib -L/home/hile/openafs/lib  -O   -m64  -O -m64  =
-I/home/hile/openafs/src/config -I/home/hile/openafs/include -I. -I.     =
 -pthread -DAFS_PTHREAD_ENV  -o afsio afsio.o afscbint.ss.o \
        /home/hile/openafs/lib/libafscp.a =
../../src/rxkad/liboafs_rxkad.la ../../src/fsint/liboafs_fsint.la =
../../src/vlserver/liboafs_vldb.la ../../src/cmd/liboafs_cmd.la =
../../src/util/liboafs_util.la ../../src/opr/liboafs_opr.la \
        -lafshcrypto -lrokenafs -lpthread -lresolv  -lsocket -lnsl =
-lintl -ldl -lresolv  -lsocket -lnsl -lintl -ldl \
         -L/opt/local/lib -R/opt/local/lib =
-L/opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3 =
-Wl,-R/opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3 =
-L/opt/local/gcc47/lib -Wl,-R/opt/local/gcc47/lib -L/opt/local/lib =
-Wl,-R/opt/local/lib -lkrb5 -lk5crypto -lcom_err
ld: fatal: file /opt/local/lib/libintl.so: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to afsio
collect2: error: ld returned 1 exit status
make[3]: *** [afsio] Error 1
make[3]: Leaving directory `/home/hile/openafs/src/venus'
make[2]: *** [venus] Error 2
make[2]: Leaving directory `/home/hile/openafs'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/home/hile/openafs'
make: *** [all] Error 2

(notwithstanding the fact that lib tool picks the right 64-bit libintl =
everywhere else in the build.)

It certainly makes more sense to build the user land parts of this on a =
64bit system (lest I have to worry about the multi arch fun, making sure =
$ORIGIN/../lib and $ORIGIN/../lib/amd64 are in the rpaths).

Is there any way that one can short-circuit and build only the kernel =
modules (libafs64.o and libafs64.nonfs.o)?  It seems a waste when I =
eventually submodule the right bits into my own SmartOS platform build =
to build the entirety of the user land, just to throw it all away since =
it won=92t ship in the image anyhow.

Most of my woes are SmartOS-specific; I know that for certain.

-c=