Hi Peter,
I don't necessarily think seeing the rebuild during the install phase is
a problem in itself. I think this is done by libtool to re-link the
shared libraries to the final install destination.
What it look like to me is there is a problem with cross compiling and
libtool. The fatal part is:
"""
arm-none-linux-gnueabi-gcc -shared .libs/pthres.o -L/usr/lib
-L/home/peter/work/logic/svn/trunk/ltib/tmp/tslib//opt/freescale/rootfs/arm/usr/lib
-lts -Wl,-soname -Wl,pthres.so -o .libs/pthres.so
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/../../../../arm-none-linux-gnueabi/bin/ld:
skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib/libc.a: could not read symbols: File format not recognized
"""
The -L/usr/lib is pulling in the build machine's libraries for the
target (which is of course incorrect). Sometimes you need to put an
inline edit into spec files to take care of this libtool problem.
I just unpacked and did an scbuild of tslib and it's okay on my host,
but maybe not on yours (?). Can you look at rpm/BUILD/tslib-1.0/libtool
and check to see if there are any absolute references to /usr/lib in the
entry for sys_lib_search_path_spec (and elsewhere). If so you'll need
something like this just after the configure command in the spec file:
"""
# Avoid libtool searching in /usr/lib
perl -pi -e 's,^sys_lib_search_path_spec=.*,sys_lib_search_path_spec=,'
libtool
"""
Let me know what you find.
I tried that, but it didn't have any visible effect as /usr/lib was being pulled in from the .la files. After googling around, I found:
Regards, Stuart
Peter Barada wrote:
>
> I've finally gotten LTIB tobuild on my Ubuntu 9.04 x64 QuadCore machine.
>
> Unfortunately tslib doesn't properly build. I'd expect after "./ltib -p
> tslib -m scdeploy" to find in rootfs/usr/lib/ts the plugins pthres.so,
> variance.so, dejitter.so and linear.so as well as input.so, but I don't.
>
> Attached are the log of a "./ltib -p tslib -m prep && ./ltib -p tslib -m
> scbuild && ./ltib -p tslib -m scdeploy". I'm wondering if there's a
> latent multi-process build problem in tslib, so I added "-j1" to the
> spec file to limit make to one job at a time, but no joy.
>
> What is scary is in the scbuild phase at line 461 of the log, I see
> pthres.so being built:
>
> if /bin/sh ../libtool --mode=compile arm-none-linux-gnueabi-gcc
> -DHAVE_CONFIG_H -I. -I. -I.. -I../src -DTSLIB_INTERNAL
> -fvisibility=hidden -DGCC_HASCLASSVISIBILITY -O2 -Wall -W -MT pthres.lo
> -MD -MP -MF ".deps/pthres.Tpo" \
> -c -o pthres.lo `test -f 'pthres.c' || echo './'`pthres.c; \
> then mv -f ".deps/pthres.Tpo" ".deps/pthres.Plo"; \
> else rm -f ".deps/pthres.Tpo"; exit 1; \
> fi
> arm-none-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../src
> -DTSLIB_INTERNAL -fvisibility=hidden -DGCC_HASCLASSVISIBILITY -O2 -Wall
> -W -MT pthres.lo -MD -MP -MF .deps/pthres.Tpo -c pthres.c -fPIC -DPIC
> -o .libs/pthres.o
> pthres.c: In function 'mod_init':
> pthres.c:134: warning: unused parameter 'dev'
> /bin/sh ../libtool --mode=link arm-none-linux-gnueabi-gcc
> -DTSLIB_INTERNAL -fvisibility=hidden -DGCC_HASCLASSVISIBILITY -O2 -Wall
> -W -o pthres.la -rpath /usr/lib/ts/ -module -avoid-version pthres.lo
> ../src/libts.la
> arm-none-linux-gnueabi-gcc -shared .libs/pthres.o -Wl,--rpath
> -Wl,/home/peter/work/logic/svn/trunk/ltib/rpm/BUILD/tslib-1.0/src/.libs
> ../src/.libs/libts.so -Wl,-soname -Wl,pthres.so -o .libs/pthres.so
> creating pthres.la
> (cd .libs && rm -f pthres.la && ln -s ../pthres.la pthres.la)
>
> but in the deployment phase at line 735, its being built again(which fails):
>
> /bin/sh ../libtool --mode=install /usr/bin/install -c pthres.la
> /home/peter/work/logic/svn/trunk/ltib/tmp/tslib//opt/freescale/rootfs/arm/usr/lib/ts//pthres.la
> libtool: install: warning: relinking `pthres.la'
> (cd /home/peter/work/logic/svn/trunk/ltib/rpm/BUILD/tslib-1.0/plugins;
> /bin/sh ../libtool --mode=relink arm-none-linux-gnueabi-gcc
> -DTSLIB_INTERNAL -fvisibility=hidden -DGCC_HASCLASSVISIBILITY -O2 -Wall
> -W -o pthres.la -rpath /usr/lib/ts/ -module -avoid-version pthres.lo
> ../src/libts.la -inst-prefix-dir
> /home/peter/work/logic/svn/trunk/ltib/tmp/tslib//opt/freescale/rootfs/arm)
> arm-none-linux-gnueabi-gcc -shared .libs/pthres.o -L/usr/lib
> -L/home/peter/work/logic/svn/trunk/ltib/tmp/tslib//opt/freescale/rootfs/arm/usr/lib
> -lts -Wl,-soname -Wl,pthres.so -o .libs/pthres.so
> /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.1.2/../../../../arm-none-linux-gnueabi/bin/ld:
> skipping incompatible /usr/lib/libc.so when searching for -lc
> /usr/lib/libc.a: could not read symbols: File format not recognized
> collect2: ld returned 1 exit status
> libtool: install: error: relink `pthres.la' with the above command
> before installing it
>
>
> 1) Does anyone have an idea what causes this (as in why some plugins
> build, but others don't)?
> 2) Is it a case of timestamps of files being equal(as the quadcore can
> create them really quickly) which causes make to rebuild things?
> 3) Any suggestions on how to fix this?
>
>
> --
> Peter Barada <address@hidden <mailto:address@hidden>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LTIB home page: http://bitshrine.org
>
> Ltib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/ltib
tslib-1.0-1241539566.patch