[Buildroot] xfsprogs 3.0.3 without libxfs in rootfs

[Buildroot] xfsprogs 3.0.3 without libxfs in rootfs

[Ossy]

Hi mailinglist,

Since xfsprogs 3.0.3 doesn't build the required xfslib in the current 
tree. I tried to bump to the newer version.
I figured out, that that br uses the old util-linux and not 
util-linux-ng. According to the debian package info, xfsprogs 3.1.2 
needs at least util-linux-ng 2.16. So I ran a green try with the 
util-linux-ng patch I've found in the mailinglist archives:
http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/16587/match=util+linux+ng

Unfortunatly the build fails, because make claims about an unknown 
option "--sysroot":
/usr/bin/make -j2 \
                 -C 
/home/ossy/buildroot/buildroot-dev/output/build/util-linux-ng-2.16 \
                 ARCH=arm \
 
CC=/home/ossy/buildroot/buildroot-dev/output/staging/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc 
--sysroot=/home/ossy/buildr
oot/buildroot-dev/output/staging \
                 OPT="-Os -pipe -Os  -mtune=arm926ej-s -march=armv5te 
-mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURC
E -D_FILE_OFFSET_BITS=64 
-I/home/ossy/buildroot/buildroot-dev/output/staging/usr/include 
-I/home/ossy/buildroot/buildroot-dev/output/staging
/include" \
                 HAVE_SLANG="NO"
/usr/bin/make: Unbekannte Option 
?--sysroot=/home/ossy/buildroot/buildroot-dev/output/staging?

It is the same make, used for all the other packages....

Further output complains about x64 compilation in addition:
This program built for x86_64-pc-linux-gnu
make: *** 
[/home/ossy/buildroot/buildroot-dev/output/build/util-linux-ng-2.16/misc-utils/chkdupexe] 
Fehler 2

I hardly see any differences in config.log compared to other 
successfully compiled packages.

I'm building on debian squeeze amd64 for target armv5TE.

Thanks for any hint.

Regards,
Marcus

[Buildroot] xfsprogs 3.0.3 without libxfs in rootfs

[Thomas Petazzoni]

Hello,

On Tue, 20 Jul 2010 23:22:42 +0200
Ossy <ossy1980@gmx.net> wrote:

> Since xfsprogs 3.0.3 doesn't build the required xfslib in the current 
> tree. I tried to bump to the newer version.
> I figured out, that that br uses the old util-linux and not 
> util-linux-ng. According to the debian package info, xfsprogs 3.1.2 
> needs at least util-linux-ng 2.16.

Good. We really need to upgrade to util-linux-ng. It has been on my
TODO-list for a while, but I haven't managed to find the time for this.

> So I ran a green try with the 
> util-linux-ng patch I've found in the mailinglist archives:
> http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/16587/match=util+linux+ng

This patch doesn't use the AUTOTARGETS infrastructure to build
util-linux-ng, which is bad.

> Unfortunatly the build fails, because make claims about an unknown 
> option "--sysroot":
> /usr/bin/make -j2 \
>                  -C 
> /home/ossy/buildroot/buildroot-dev/output/build/util-linux-ng-2.16 \
>                  ARCH=arm \
>  
> CC=/home/ossy/buildroot/buildroot-dev/output/staging/usr/bin/arm-unknown-linux-uclibcgnueabi-gcc 
> --sysroot=/home/ossy/buildr
> oot/buildroot-dev/output/staging \
>                  OPT="-Os -pipe -Os  -mtune=arm926ej-s -march=armv5te 
> -mabi=aapcs-linux -msoft-float -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURC E -D_FILE_OFFSET_BITS=64 
> -I/home/ossy/buildroot/buildroot-dev/output/staging/usr/include 
> -I/home/ossy/buildroot/buildroot-dev/output/staging
> /include" \
>                  HAVE_SLANG="NO"
> /usr/bin/make: Unbekannte Option 
> ?--sysroot=/home/ossy/buildroot/buildroot-dev/output/staging?
> 
> It is the same make, used for all the other packages....

For a quick fix, replace:

	CC=$(TARGET_CC)

by

	CC="$(TARGET_CC)"

This should solve the "unknown --sysroot option" problem that you're
having.

But clearly the correct fix is to switch to AUTOTARGETS.

Cheers,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] xfsprogs 3.0.3 without libxfs in rootfs

[Ossy]

Am 21.07.2010 08:58, schrieb Thomas Petazzoni:
> But clearly the correct fix is to switch to AUTOTARGETS.
>
>

I searched some autotargets patch mails in the mailinglist. Nearly all 
of them just modified the package/<pkg-name>/<pkg-name>.mk file.
I was wondering, that there were no other modifications in the other 
converted packages like some global pkg index file which marks the new 
package as "use autotargets now and not the old infrastructure anymore".

I tried the same and converted the util-linux-ng into this:
#############################################################
UTIL-LINUX-NG_VERSION:=2.17
UTIL-LINUX-NG_PATCHLEVEL:=2
UTIL-LINUX-NG_SITE:=$(BR2_KERNEL_MIRROR)/linux/utils/util-linux-ng/v$(UTIL-LINUX-NG_VERSION)
ifneq ($(UTIL-LINUX-NG_PATCHLEVEL),'')
 
UTIL-LINUX-NG_SOURCE:=util-linux-ng-$(UTIL-LINUX-NG_VERSION).$(UTIL-LINUX-NG_PATCHLEVEL).tar.bz2
else
   UTIL-LINUX-NG_SOURCE:=util-linux-ng-$(UTIL-LINUX-NG_VERSION).tar.bz2
endif
UTIL-LINUX-NG_DIR:=$(BUILD_DIR)/util-linux-ng-$(UTIL-LINUX-NG_VERSION)
UTIL-LINUX-NG_CAT:=$(BZCAT)
UTIL-LINUX-NG_BINARY:=$(UTIL-LINUX-NG_DIR)/misc-utils/chkdupexe
UTIL-LINUX-NG_TARGET_BINARY:=$(TARGET_DIR)/usr/bin/chkdupexe
UTIL-LINUX-NG_CONF_OPT:=--disable-use-tty-group
UTIL-LINUX-NG_DEPENDENCIES:=

ifeq ($(BR2_PACKAGE_NCURSES),y)
   ifeq ($(BR2_USE_WCHAR),n)
     UTIL-LINUX-NG_CONF_OPT+=--with-ncurses
   endif # BR2_USE_WCHAR
else
   UTIL-LINUX-NG_CONF_OPT+=--without-ncurses
endif # BR2_PACKAGE_NCURSES

ifeq ($(BR2_PACKAGE_ZLIB),n)
   UTIL-LINUX-NG_CONF_OPT:=--disable-cramfs
endif

$(eval $(call AUTOTARGETS,package,util-linux-ng))

I took the original mk file and tried to save the options and 
dependencies. I was able to activate the util-linux-ng box in the 
menuconfig and ran make. Unfortunatly the util-linux-ng package isn't 
touched in any way.
Do I have to remove more declarations in the new mk file?
Do I need to run some "make ulng known to be autotargetted now by 
removing old config caches" ?

Regards,
Marcus

[Buildroot] xfsprogs 3.0.3 without libxfs in rootfs

[Thomas Petazzoni]

Hello,

On Sat, 24 Jul 2010 19:02:22 +0200
Ossy <ossy1980@gmx.net> wrote:

> I searched some autotargets patch mails in the mailinglist. Nearly
> all of them just modified the package/<pkg-name>/<pkg-name>.mk file.
> I was wondering, that there were no other modifications in the other 
> converted packages like some global pkg index file which marks the
> new package as "use autotargets now and not the old infrastructure
> anymore".

In terms of Makefile, nothing else needs to be done than just the final:

$(eval $(call AUTOTARGETS,package,util-linux-ng))

in the util-linux-ng.mk file.

> UTIL-LINUX-NG_VERSION:=2.17

This needs to be

UTIL_LINUX_NG_VERSION=2.17

> UTIL-LINUX-NG_PATCHLEVEL:=2
> UTIL-LINUX-NG_SITE:=$(BR2_KERNEL_MIRROR)/linux/utils/util-linux-ng/v$(UTIL-LINUX-NG_VERSION)
> ifneq ($(UTIL-LINUX-NG_PATCHLEVEL),'')

I'm not sure this test is going to work. It should probably be

ifneq ($(UTIL_LINUX_NG_PATCHLEVEL),)

> UTIL-LINUX-NG_SOURCE:=util-linux-ng-$(UTIL-LINUX-NG_VERSION).$(UTIL-LINUX-NG_PATCHLEVEL).tar.bz2
> else
>    UTIL-LINUX-NG_SOURCE:=util-linux-ng-$(UTIL-LINUX-NG_VERSION).tar.bz2
> endif

> UTIL-LINUX-NG_DIR:=$(BUILD_DIR)/util-linux-ng-$(UTIL-LINUX-NG_VERSION)
> UTIL-LINUX-NG_CAT:=$(BZCAT)
> UTIL-LINUX-NG_BINARY:=$(UTIL-LINUX-NG_DIR)/misc-utils/chkdupexe
> UTIL-LINUX-NG_TARGET_BINARY:=$(TARGET_DIR)/usr/bin/chkdupexe

Get rid of thse four variables.

> UTIL-LINUX-NG_CONF_OPT:=--disable-use-tty-group
> UTIL-LINUX-NG_DEPENDENCIES:=

This empty variable is not needed.

> ifeq ($(BR2_PACKAGE_NCURSES),y)
>    ifeq ($(BR2_USE_WCHAR),n)
>      UTIL-LINUX-NG_CONF_OPT+=--with-ncurses

here you should add
       UTIL_LINUX_NG_DEPENDENCIES += ncurses

to make sure ncurses gets compiled before util-linux-ng, when both are
enabled in the config.

The test ifeq ($(BR2_USE_WCHAR),n) is not going to work. When options
are not enabled, their value is empty, not "n". So this test should be :

	ifneq ($(BR2_USE_WCHAR),y))

Moreover, I haven't thought about it, but I don't see why WCHAR is
playing a role here.

>    endif # BR2_USE_WCHAR
> else
>    UTIL-LINUX-NG_CONF_OPT+=--without-ncurses
> endif # BR2_PACKAGE_NCURSES

Last thing: in the rest of the Buildroot code, we don't do much this
kind of indentation and marking of endif with the initial condition.
Maybe we should, but we don't at the moment.

> ifeq ($(BR2_PACKAGE_ZLIB),n)
>    UTIL-LINUX-NG_CONF_OPT:=--disable-cramfs
> endif

Same thing as above, should be :

 ifeq ($(BR2_PACKAGE_ZLIB),y)
   UTIL_LINUX_NG_DEPENDENCIES += zlib
 else
   UTIL_LINUX_NG_CONF_OPT+=--disable-cramfs
 endif

> I took the original mk file and tried to save the options and 
> dependencies. I was able to activate the util-linux-ng box in the 
> menuconfig and ran make. Unfortunatly the util-linux-ng package isn't 
> touched in any way.

Quite probably because of your variables being named
UTIL-LINUX-NG_something instead of UTIL_LINUX_NG_something.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] xfsprogs 3.0.3 without libxfs in rootfs

[Ossy]

Am 30.07.2010 10:43, schrieb Thomas Petazzoni:
> In terms of Makefile, nothing else needs to be done than just the final:
>
> $(eval $(call AUTOTARGETS,package,util-linux-ng))
>
> in the util-linux-ng.mk file.
>
I wasn't aware, that an answer would follow after so much mails ;-)
Sorry, for not posting an update. I figured this out already. I took the 
openwrt version as template.

I have a working version now, but I need to clean up the make file.
I wasn't able to build just single components of util-linux-ng. Ideally 
I wanted to switch them on and off by the menuconfig. But I had to run 
into every subdirectoy of each componentn bundled in util-linux-ng.

So if some one has to use util-linux-ng (e.g. libuuid of busybox is not 
compatible with recent xfsprogs), he has to choose ALL utils or NONE.

Currently it compiles well with recent git tree and gcc 4.3.5 for armv5te.

Kind regards,
Marcus

[Buildroot] xfsprogs 3.0.3 without libxfs in rootfs

[Ossy]

Am 30.07.2010 21:48, schrieb Ossy:
> Am 30.07.2010 10:43, schrieb Thomas Petazzoni:
>> In terms of Makefile, nothing else needs to be done than just the final:
>>
>> $(eval $(call AUTOTARGETS,package,util-linux-ng))
>>
>> in the util-linux-ng.mk file.
>>
>
> Currently it compiles well with recent git tree and gcc 4.3.5 for armv5te.

Since util-linux-ng compiles and succesfully installs, I gave 
xfsprogs-3.1.2 a try. Surprisingly it compiles well for armv5te with gcc 
4.3.5. The binaries found in output/build/xfsprogs-3.1.2 are 32bit 
binaries for ARM. But here comes the problem ->
"No rule to make install-strip":
 >>> xfsprogs 3.1.2 Installing to target
/usr/bin/make -j2 
DESTDIR=/home/ossy/buildroot/buildroot-dev/output/target  install-strip 
-C /home/ossy/buildroot/buildroot-dev/output/build/xfsprogs-3.1.2/
make[1]: Entering directory 
`/home/ossy/buildroot/buildroot-dev/output/build/xfsprogs-3.1.2'
make[1]: *** Keine Regel, um ?install-strip? zu erstellen.  Schluss.
make[1]: Leaving directory 
`/home/ossy/buildroot/buildroot-dev/output/build/xfsprogs-3.1.2'
make: *** 
[/home/ossy/buildroot/buildroot-dev/output/build/xfsprogs-3.1.2/.stamp_target_installed] 
Fehler 2

In fact I can't find a target install-strip in the makefile of 
output/build/xfsprogs-3.1.2.
Should autotargets have generated such a target?

My xfsprogs.mk looks very simple an does not include a install-strip 
commando:
#############################################################
XFSPROGS_VERSION = 3.1.2
XFSPROGS_SOURCE  = xfsprogs-$(XFSPROGS_VERSION).tar.gz
XFSPROGS_SITE    = ftp://oss.sgi.com/projects/xfs/cmd_tars
XFSPROGS_DEPENDENCIES = util-linux-ng
XFSPROGS_LIBTOOL_PATCH = NO
XFSPROGS_CONF_OPT     = --enable-shared \
                         --enable-gettext=no \
                         ac_cv_header_aio_h=yes ac_cv_lib_rt_lio_listio=yes
$(eval $(call AUTOTARGETS,package,xfsprogs))

The deflated xfsprogs in output/build/xfsprogs-3.1.2 does not contain a 
file with content "install-strip".

Where did I misconfigure the new xfsprogs.mk for using autotargets?

Regards,
Marcus

[Buildroot] xfsprogs 3.0.3 without libxfs in rootfs

[Ossy]

Am 31.07.2010 15:03, schrieb Ossy:
> Since util-linux-ng compiles and succesfully installs, I gave
> xfsprogs-3.1.2 a try. Surprisingly it compiles well for armv5te with gcc
> 4.3.5. The binaries found in output/build/xfsprogs-3.1.2 are 32bit
> binaries for ARM. But here comes the problem ->
> "No rule to make install-strip":
>
> In fact I can't find a target install-strip in the makefile of
> output/build/xfsprogs-3.1.2.
> Should autotargets have generated such a target?
>
> Where did I misconfigure the new xfsprogs.mk for using autotargets?
>
I added the following option in xfsprogs.mk - I assume it says "use 
install and not install-strip".
XFSPROGS_INSTALL_TARGET_OPT = DESTDIR=$(TARGET_DIR) install

The target "install" is correctly triggered, but I get another error now:
 >>> xfsprogs 3.1.2 Installing to target
/usr/bin/make -j2 
DESTDIR=/home/ossy/buildroot/buildroot-dev/output/target install -C 
/home/ossy/buildroot/buildroot-dev/output/build/xfsprogs-3.1.2/
make[1]: Entering directory 
`/home/ossy/buildroot/buildroot-dev/output/build/xfsprogs-3.1.2'
Installing include-install
Installing libxfs-install
make[2]: F?r das Ziel ?install? ist nichts zu tun.
Installing libxlog-install
     [DEP]
     [DEP]
Installing libxcmd-install
     [DEP]
Installing libhandle-install
     [DEP]
cd ../libhandle/.libs; ../../install-sh -o ossy -g ossy -m 755 -d /lib; 
../../install-sh -o ossy -g ossy -m 644 -T so_dot_version libhandle.lai 
/lib; ../../install-sh -o ossy -g ossy -T so_dot_current libhandle.lai /lib
chmod: Beim Setzen der Zugriffsrechte f?r ?//lib?: Die Operation ist 
nicht erlaubt
cp: regul?re Datei ?//lib/libhandle.so.1.0.3? kann nicht angelegt 
werden: Permission denied.
ln: Entfernen von ?//lib/libhandle.so.1? nicht m?glich: Permission denied.
make[2]: *** [install] Fehler 1
make[1]: *** [libhandle-install] Fehler 2
make[1]: *** Warte auf noch nicht beendete Prozesse...
make[1]: Leaving directory 
`/home/ossy/buildroot/buildroot-dev/output/build/xfsprogs-3.1.2'
make: *** 
[/home/ossy/buildroot/buildroot-dev/output/build/xfsprogs-3.1.2/.stamp_target_installed] 
Fehler 2

So the library path configuration wasn't correct. Which option in 
xfsprogs.mk would inform the make-process to use the target directory 
and not some "//lib"?

Regards,
Marcus

Sorry for commenting everything. I think this would help others who 
search the mailinglist archives, since we are short with other 
documentation.