[Xenomai-core] Buildbot: Errors building rtnet since at least r1834

[Xenomai-core] Buildbot: Errors building rtnet since at least r1834

[Niklaus Giger]

Hi

Unfortunately I cannot say since when this build is broken, as I had to 
reinstall the buildbot on my main server. But this particular build target 
should not have been affected. (Same compiler, same build slave, same 
scripts)

But since at November 12 I get the following errors in my builds:
See http://ngiger.dyndns.org/buildbot-full/tqm_f/builds/0/step-mk_RTnet/1
libtool: link: warning: library 
`/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was 
moved.
libtool: link: warning: library 
`/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved.
libtool: link: warning: library 
`/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was 
moved.
libtool: link: warning: library 
`/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved.

Has anybody a hint, what the reason could be?

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Buildbot: Errors building rtnet since at least r1834

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

Niklaus Giger wrote:
> Hi
> 
> Unfortunately I cannot say since when this build is broken, as I had to 
> reinstall the buildbot on my main server. But this particular build target 
> should not have been affected. (Same compiler, same build slave, same 
> scripts)
> 
> But since at November 12 I get the following errors in my builds:
> See http://ngiger.dyndns.org/buildbot-full/tqm_f/builds/0/step-mk_RTnet/1
> libtool: link: warning: library 
> `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was 
> moved.
> libtool: link: warning: library 
> `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved.
> libtool: link: warning: library 
> `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was 
> moved.
> libtool: link: warning: library 
> `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved.
> 
> Has anybody a hint, what the reason could be?

DESTDIR issue? Are you compiling both Xenomai and RTnet with the same
DESTDIR?

Check what's stated in those .la files and compare with the RTnet build
parameters.

Jan

PS: This is a *warning*, not a fatal *error*. Or did you just want to
receive more attention? ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Buildbot: Errors building rtnet since at least r1834

[Niklaus Giger]

[-- Attachment #1: Type: text/plain, Size: 4206 bytes --]

Am Samstag, 18. November 2006 19:00 schrieb Jan Kiszka:
> Niklaus Giger wrote:
> > Hi
> >
> > Unfortunately I cannot say since when this build is broken, as I had to
> > reinstall the buildbot on my main server. But this particular build
> > target should not have been affected. (Same compiler, same build slave,
> > same scripts)
> >
> > But since at November 12 I get the following errors in my builds:
> > See http://ngiger.dyndns.org/buildbot-full/tqm_f/builds/0/step-mk_RTnet/1
> > libtool: link: warning: library
> > `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was
> > moved.
> > libtool: link: warning: library
> > `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved.
> > libtool: link: warning: library
> > `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was
> > moved.
> > libtool: link: warning: library
> > `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved.
> >
> > Has anybody a hint, what the reason could be?
>
> DESTDIR issue? Are you compiling both Xenomai and RTnet with the same
> DESTDIR?
Calling manuall make install like the following line did not change the 
result:
DESTDIR=/var/buildbot/install/tqm_q make prefix=/var/buildbot/install/tqm_q 
install 

My steps to compile the xenomai kernel were:
cd /var/buildbot/slave/tqm_q/linux
export CROSS_COMPILE=powerpc-860-linux-gnu- 
make oldconfig
make --jobs=4 uImage modules
make INSTALL_MOD_PATH=/var/buildbot/install/tqm_q modules_install
make DESTDIR=/var/buildbot/install/tqm_q install
cd /var/buildbot/slave/tqm_q/build
../xenomai/configure --host=ppc-linux --enable-debug
make 
cd /var/buildbot/slave/tqm_q/rtnet
./configure --host=powerpc-860-linux-gnu --enable-rtwlan --enable-route-src --enable-net-routing --enable-router --enable-rtcfg-dbg --enable-nomac --enable-rtcap --enable-proxy --enable-examples --enable-checks --enable-fec-enet --enable-scc-enet --with-rtext-config=/var/buildbot/install/tqm_q/usr/xenomai/bin/xeno-config --with-linux=../linux --prefix=/var/buildbot/install/tqm_q 
DESTDIR=/var/buildbot/install/tqm_q
make prefix=/var/buildbot/install/tqm_q install

Is this okay? Or do I have an error here?

Isn't it more the problem that xeno-config since a few weeks ago outputs wrong 
paths (forgets about its DESTDIR when installed). E.g. look at this output of
/var/buildbot/install/tqm_q/usr/xenomai/bin/xeno-config
xeno-config --verbose
    --version="2.2.91"
    --cc="gcc"
    --arch="powerpc"
    --prefix="/usr/xenomai"
    --xeno-cflags="-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT"
    --xeno-ldflags="-L/usr/xenomai/lib -lpthread "
    --posix-cflags="-I/usr/xenomai/include -I/usr/xenomai/include/posix -D_GNU_SOURCE -D_REENTRANT -D__XENO__"
    --posix-ldflags="-L/usr/xenomai/lib -lpthread_rt -lpthread -lrt "
    --library-dir="/usr/xenomai/lib"

I think --xeno-ldflags="-L/usr/xenomai/lib -lpthread " should return
--xeno-ldflags="-L/var/buildbot/install/usr/xenomai/lib -lpthread "


> Check what's stated in those .la files and compare with the RTnet build
> parameters.
*.la files are attached
>
> Jan
>
> PS: This is a *warning*, not a fatal *error*. Or did you just want to
> receive more attention? ;)
Sorry. I forgot to include the line with the real error.

powerpc-860-linux-gnu-gcc -I/var/buildbot/install/tqm_q/usr/xenomai/include -I/var/buildbot/install/tqm_q/usr/xenomai/include/posix -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -O2 -fstrict-aliasing -I../../../stack/include -g -Wl,@/var/buildbot/install/tqm_q/usr/xenomai/lib/posix.wrappers -o 
rtt-sender 
rtt-sender.o  -L/var/buildbot/install/tqm_q/usr/xenomai/lib /var/buildbot/install/tqm_q/usr/xenomai/lib/libpthread_rt.so -lrt -lpthread /var/buildbot/install/tqm_q/usr/xenomai/lib/librtdm.so -Wl,--rpath -Wl,/var/buildbot/install/tqm_q/usr/xenomai/lib -Wl,--rpath -Wl,/var/buildbot/install/tqm_q/usr/xenomai/lib
/opt/crosstool/gcc-3.4.1-glibc-2.3.3/powerpc-860-linux-gnu/lib/gcc/powerpc-860-linux-gnu/3.4.1/../../../../powerpc-860-linux-gnu/bin/ld: 
@/var/buildbot/install/tqm_q/usr/xenomai/lib/posix.wrappers: No such file: No 
such file or directory
collect2: ld returned 1 exit status

Best regards

-- 
Niklaus Giger

[-- Attachment #2: libpthread_rt.la --]
[-- Type: text/plain, Size: 858 bytes --]

# libpthread_rt.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 224 $
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libpthread_rt.so.0'

# Names of this library.
library_names='libpthread_rt.so.0.0.0 libpthread_rt.so.0 libpthread_rt.so'

# The name of the static archive.
old_library='libpthread_rt.a'

# Libraries that this one depends upon.
dependency_libs=' -lpthread'

# Version information for libpthread_rt.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/usr/xenomai/lib'

[-- Attachment #3: librtdm.la --]
[-- Type: text/plain, Size: 806 bytes --]

# librtdm.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 224 $
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='librtdm.so.0'

# Names of this library.
library_names='librtdm.so.0.0.0 librtdm.so.0 librtdm.so'

# The name of the static archive.
old_library='librtdm.a'

# Libraries that this one depends upon.
dependency_libs=''

# Version information for librtdm.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/usr/xenomai/lib'

Re: [Xenomai-core] Buildbot: Errors building rtnet since at least r1834

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 5741 bytes --]

Niklaus Giger wrote:
> Am Samstag, 18. November 2006 19:00 schrieb Jan Kiszka:
>> Niklaus Giger wrote:
>>> Hi
>>>
>>> Unfortunately I cannot say since when this build is broken, as I had to
>>> reinstall the buildbot on my main server. But this particular build
>>> target should not have been affected. (Same compiler, same build slave,
>>> same scripts)
>>>
>>> But since at November 12 I get the following errors in my builds:
>>> See http://ngiger.dyndns.org/buildbot-full/tqm_f/builds/0/step-mk_RTnet/1
>>> libtool: link: warning: library
>>> `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was
>>> moved.
>>> libtool: link: warning: library
>>> `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved.
>>> libtool: link: warning: library
>>> `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/libpthread_rt.la' was
>>> moved.
>>> libtool: link: warning: library
>>> `/var/buildbot/install/tqm_f-r1834/usr/xenomai/lib/librtdm.la' was moved.
>>>
>>> Has anybody a hint, what the reason could be?
>> DESTDIR issue? Are you compiling both Xenomai and RTnet with the same
>> DESTDIR?
> Calling manuall make install like the following line did not change the 
> result:
> DESTDIR=/var/buildbot/install/tqm_q make prefix=/var/buildbot/install/tqm_q 
> install 

make install of ...? Also, the prefix is not needed unless you modify
the layout *on the target*.

> 
> My steps to compile the xenomai kernel were:
> cd /var/buildbot/slave/tqm_q/linux
> export CROSS_COMPILE=powerpc-860-linux-gnu- 
> make oldconfig
> make --jobs=4 uImage modules
> make INSTALL_MOD_PATH=/var/buildbot/install/tqm_q modules_install
> make DESTDIR=/var/buildbot/install/tqm_q install

[has no influence here]

> cd /var/buildbot/slave/tqm_q/build
> ../xenomai/configure --host=ppc-linux --enable-debug
> make 

No install? I'll assume there is one with DESTDIR passed appropriately,
right?

> cd /var/buildbot/slave/tqm_q/rtnet
> ./configure --host=powerpc-860-linux-gnu --enable-rtwlan --enable-route-src --enable-net-routing --enable-router --enable-rtcfg-dbg --enable-nomac --enable-rtcap --enable-proxy --enable-examples --enable-checks --enable-fec-enet --enable-scc-enet --with-rtext-config=/var/buildbot/install/tqm_q/usr/xenomai/bin/xeno-config --with-linux=../linux --prefix=/var/buildbot/install/tqm_q 
> DESTDIR=/var/buildbot/install/tqm_q
> make prefix=/var/buildbot/install/tqm_q install
> 
> Is this okay? Or do I have an error here?

DESTDIR belongs to which command?

In any case, ./configure needs it in order to get the correct paths from
xeno-config, and make install requires it, as usual, too. So it's likely
best to simply export DESTDIR before starting the whole batch.

> 
> Isn't it more the problem that xeno-config since a few weeks ago outputs wrong 
> paths (forgets about its DESTDIR when installed). E.g. look at this output of
> /var/buildbot/install/tqm_q/usr/xenomai/bin/xeno-config
> xeno-config --verbose
>     --version="2.2.91"
>     --cc="gcc"
>     --arch="powerpc"
>     --prefix="/usr/xenomai"
>     --xeno-cflags="-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT"
>     --xeno-ldflags="-L/usr/xenomai/lib -lpthread "
>     --posix-cflags="-I/usr/xenomai/include -I/usr/xenomai/include/posix -D_GNU_SOURCE -D_REENTRANT -D__XENO__"
>     --posix-ldflags="-L/usr/xenomai/lib -lpthread_rt -lpthread -lrt "
>     --library-dir="/usr/xenomai/lib"
> 
> I think --xeno-ldflags="-L/usr/xenomai/lib -lpthread " should return
> --xeno-ldflags="-L/var/buildbot/install/usr/xenomai/lib -lpthread "

That's correct. Note that xeno-config is first of all intended to run on
the *target* and provide correct paths there. To use it also on the
build host, you have to invoke it with DESTDIR set appropriately (see
above).

> 
> 
>> Check what's stated in those .la files and compare with the RTnet build
>> parameters.
> *.la files are attached
>> Jan
>>
>> PS: This is a *warning*, not a fatal *error*. Or did you just want to
>> receive more attention? ;)
> Sorry. I forgot to include the line with the real error.
> 
> powerpc-860-linux-gnu-gcc -I/var/buildbot/install/tqm_q/usr/xenomai/include -I/var/buildbot/install/tqm_q/usr/xenomai/include/posix -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -O2 -fstrict-aliasing -I../../../stack/include -g -Wl,@/var/buildbot/install/tqm_q/usr/xenomai/lib/posix.wrappers -o 
> rtt-sender 
> rtt-sender.o  -L/var/buildbot/install/tqm_q/usr/xenomai/lib /var/buildbot/install/tqm_q/usr/xenomai/lib/libpthread_rt.so -lrt -lpthread /var/buildbot/install/tqm_q/usr/xenomai/lib/librtdm.so -Wl,--rpath -Wl,/var/buildbot/install/tqm_q/usr/xenomai/lib -Wl,--rpath -Wl,/var/buildbot/install/tqm_q/usr/xenomai/lib
> /opt/crosstool/gcc-3.4.1-glibc-2.3.3/powerpc-860-linux-gnu/lib/gcc/powerpc-860-linux-gnu/3.4.1/../../../../powerpc-860-linux-gnu/bin/ld: 
> @/var/buildbot/install/tqm_q/usr/xenomai/lib/posix.wrappers: No such file: No 
> such file or directory
> collect2: ld returned 1 exit status

Is /var/buildbot/install/tqm_q/usr/xenomai/lib/posix.wrappers the
correct path? Does the file exist?

...
> 
> # Directory that this library needs to be installed in:
> libdir='/usr/xenomai/lib'

That's ok from the target's POV. Unfortunately, we then see those "was
moved" warnings. I don't know if one can avoid them via some magic, but
they are harmless.

@All: Does anyone know how to pass a prefix (DESTDIR) to an
automake-based linking step - and how to code this into .am files? The
scenario is linking against libs (represented via .la files) that were
installed for the target, i.e. without the DESTDIR part the host needs.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Buildbot: Errors building rtnet since at least r1834

[Paul]

Hi Jan & Niklaus

On Saturday 18 November 2006 20:16, Niklaus Giger wrote:
> > DESTDIR issue? Are you compiling both Xenomai and RTnet with the same
> > DESTDIR?
>
> Calling manuall make install like the following line did not change the
> result:
> DESTDIR=/var/buildbot/install/tqm_q make prefix=/var/buildbot/install/tqm_q
> install

Just completed a test build here on the only box currently set up with 
Xenomai, and no install errors were reported. What I would expect from the 
quoted line above is everything installed in 
 /var/buildbot/install/tqm_q/var/buildbot/install/tqm_q (in other words, 
$DESTDIR/$prefix). The DESTDIR variable should only be used to specify a 
temporary staging area, for example, when building an RPM or Debian package 
where the binaries/libaries will be installed in /usr/xenomai but the package 
it's self is being generated in /tmp/build/.


Regards, Paul.

Re: [Xenomai-core] Buildbot: Errors building rtnet since at least r1834

[Niklaus Giger]

Am Montag, 20. November 2006 21:02 schrieb Paul:
> Hi Jan & Niklaus
>
> On Saturday 18 November 2006 20:16, Niklaus Giger wrote:
> > > DESTDIR issue? Are you compiling both Xenomai and RTnet with the same
> > > DESTDIR?
> >
> > Calling manuall make install like the following line did not change the
> > result:
> > DESTDIR=/var/buildbot/install/tqm_q make
> > prefix=/var/buildbot/install/tqm_q install
>
> Just completed a test build here on the only box currently set up with
> Xenomai, and no install errors were reported. What I would expect from the
> quoted line above is everything installed in
>  /var/buildbot/install/tqm_q/var/buildbot/install/tqm_q (in other words,
> $DESTDIR/$prefix). The DESTDIR variable should only be used to specify a
> temporary staging area, for example, when building an RPM or Debian package
> where the binaries/libaries will be installed in /usr/xenomai but the
> package it's self is being generated in /tmp/build/.
Thanks everybody for their hints. I could correct now my errors (not yet 
propagated to the buildbot because of lack of time).

I however use the DESTDIR quite often to install the output of my different 
build (cross-compiling) slaves into different directories to be able to 
switch between them easily. Also I use the DESTDIR to specify the nfs root 
directory which the test boards will use to boot from. I know of nothing more 
appropriate for this purpose or did I miss something?

To be able to test more easily regressions between different version I wanted 
now to make my install directories to include the revision.

A part of my confusion stemmed from the fact that something which is very easy 
in a script proved to be quite complicated in my buildbot. My idea was that 
after the first build step (the svn checkout) I wanted to evaluats 
`svnversion` to help me point DESTDIR to something 
like "/home/hcu/rootfs/revision-1986". Unfortunately I did not yet found out 
how  buildbot step can propagate this property easily to all of it 
successors. I have to dig further there.

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Buildbot: Errors building rtnet since at least r1834

[Paul]

Hi Niklaus

On Tuesday 21 November 2006 07:25, Niklaus Giger wrote:
> I however use the DESTDIR quite often to install the output of my different
> build (cross-compiling) slaves into different directories to be able to
> switch between them easily. Also I use the DESTDIR to specify the nfs root
> directory which the test boards will use to boot from. I know of nothing
> more appropriate for this purpose or did I miss something?

Using DESTDIR to install to an NFS root partition is just the sort of thing it 
was intended for.

> To be able to test more easily regressions between different version I
> wanted now to make my install directories to include the revision.

I suspect you would be better off appending the revision number to the prefix 
variable - This would allow you to install and run without hitting any 
missing path problems.

> A part of my confusion stemmed from the fact that something which is very
> easy in a script proved to be quite complicated in my buildbot. My idea was
> that after the first build step (the svn checkout) I wanted to evaluats
> `svnversion` to help me point DESTDIR to something
> like "/home/hcu/rootfs/revision-1986". Unfortunately I did not yet found
> out how  buildbot step can propagate this property easily to all of it
> successors. I have to dig further there.

If you wanted to post the scripts (or email them over), perhaps I could take a 
look and maybe suggest a solution.


Regards, Paul.