xfsprogs: .lai files not found

xfsprogs: .lai files not found

[Jan Engelhardt]

So I tried changing the xfsprogs package in openSUSE to build without 
static libraries, and what I got back from the build system was a 
warning about completely improper rpath settings.


	ERROR: RPATH "/home/abuild/rpmbuild/BUILD/xfsprogs-3.1.6/libxfs/.libs" 
	on 
	/home/abuild/rpmbuild/BUILDROOT/xfsprogs-3.1.6-0.x86_64/usr/sbin/mkfs.xfs 
	is not allowed
	[lots of these]

I therefore ripped out

	-LTLDFLAGS += -rpath $(PKG_ROOT_LIB_DIR)

from include/buildmacros, only to find that the install procedure then 
does not work at all anymore.

	cd ../libhandle/.libs; ../../install-sh -o abuild -g abuild -m 755 -d /lib64; ../../install-sh -o abuild -g abuild -m 644 -T so_dot_version libhandle.lai /lib64; ../../install-sh -o abuild -g abuild -T so_dot_current libhandle.lai /lib64
	install-sh: Unable to find libtool library file libhandle.lai
	install-sh: Unable to find libtool library file libhandle.lai
	gmake[1]: *** [install] Error 2
	make: *** [libhandle-install] Error 2
	error: Bad exit status from /var/tmp/rpm-tmp.JjlSJb (%install)

(I frown upon using libtool directly and seek to replace it with an
assisted version using automake. There is however __quite__ some
cruft in the src tree.)

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

Re: xfsprogs: .lai files not found

[Eric Sandeen]

On 5/24/12 8:45 AM, Jan Engelhardt wrote:
> 
> So I tried changing the xfsprogs package in openSUSE to build without 
> static libraries, and what I got back from the build system was a 
> warning about completely improper rpath settings.
> 
> 
> 	ERROR: RPATH "/home/abuild/rpmbuild/BUILD/xfsprogs-3.1.6/libxfs/.libs" 
> 	on 
> 	/home/abuild/rpmbuild/BUILDROOT/xfsprogs-3.1.6-0.x86_64/usr/sbin/mkfs.xfs 
> 	is not allowed
> 	[lots of these]
> 
> I therefore ripped out
> 
> 	-LTLDFLAGS += -rpath $(PKG_ROOT_LIB_DIR)
> 
> from include/buildmacros, only to find that the install procedure then 
> does not work at all anymore.
> 
> 	cd ../libhandle/.libs; ../../install-sh -o abuild -g abuild -m 755 -d /lib64; ../../install-sh -o abuild -g abuild -m 644 -T so_dot_version libhandle.lai /lib64; ../../install-sh -o abuild -g abuild -T so_dot_current libhandle.lai /lib64
> 	install-sh: Unable to find libtool library file libhandle.lai
> 	install-sh: Unable to find libtool library file libhandle.lai
> 	gmake[1]: *** [install] Error 2
> 	make: *** [libhandle-install] Error 2
> 	error: Bad exit status from /var/tmp/rpm-tmp.JjlSJb (%install)
> 
> (I frown upon using libtool directly and seek to replace it with an
> assisted version using automake. There is however __quite__ some
> cruft in the src tree.)

It's a little embarrassing to say so, but here's the hack I use in fedora for some of this stuff.

%configure \
        --enable-readline=yes   \
        --enable-blkid=yes

# Kill rpaths
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool

...

# nuke .la files, etc
rm -f $RPM_BUILD_ROOT/{%{_lib}/*.{la,a,so},%{_libdir}/*.{la,a}}

Agreed that the build system could use love, do we have a volunteer? :)

-Eric

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

Re: xfsprogs: .lai files not found

[Jan Engelhardt]

On Thursday 2012-05-24 18:25, Eric Sandeen wrote:
>> 
>> (I frown upon using libtool directly and seek to replace it with an
>> assisted version using automake. There is however __quite__ some
>> cruft in the src tree.)
>
>Agreed that the build system could use love, do we have a volunteer? :)

Certainly.
Perhaps confirm that the following oddballs indeed
mark code that can be replaced:

- __psint_t/__psunsigned_t looks very much like a pre-C-standard attempt at
  intptr_t/uintptr_t [and should be changed accordingly]

- many files in include/ should actually be in include/xfs/
  (which does not exist at clone time)

- 'struct stat64' smells really like an implementation detail
  of how -D_FILE_OFFSET_BITS=64 (or the absence thereof) is handled.
  If the -D is given, isn't "struct stat" enough for all supported OSes?

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