[Buildroot] oprofile "requires" gmp???

[Buildroot] oprofile "requires" gmp???

[ANDY KENNEDY]

buildroot v2011.02-git Configuration:

MIPS-32r2 using native toolchain, uclibc-0.9.31.x, gcc-4.5.x, binutils
2.20.1.

When I select oprofile from packages -> debug utils, gmp is selected,
though the .config file reports # BR2_PACKAGE_LIBGMP is not set, though
buildroot attempts to build it.

There are no dependencies for gmp listed in the oprofile help section.

What gives?

Should I file this as a bug report?

Thanks,
Andy

[Buildroot] oprofile "requires" gmp???

[Thomas Petazzoni]

Hello,

On Wed, 22 Dec 2010 22:47:17 -0600
ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:

> buildroot v2011.02-git Configuration:
> 
> MIPS-32r2 using native toolchain, uclibc-0.9.31.x, gcc-4.5.x, binutils
> 2.20.1.
> 
> When I select oprofile from packages -> debug utils, gmp is selected,
> though the .config file reports # BR2_PACKAGE_LIBGMP is not set,
> though buildroot attempts to build it.
> 
> There are no dependencies for gmp listed in the oprofile help section.
> 
> What gives?

oprofile needs binutils on target, which in turns requires gmp on
target. So the fact that gmp gets compiled is normal.

However, the fact that BR2_PACKAGE_LIBGMP is not set is indeed
incorrect. But Gustavo has a patch series that rewrites how binutils,
gmp, mpfr are handled, so presumably he could fix that particular
problem as part of this patch set.

Regards,

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

[Buildroot] oprofile "requires" gmp???

[ANDY KENNEDY]

Okay, I've done some tracking and have found the issue, but I don't know
Mips asm that great (only 2 months into mips).

The code that it pukes at for building gmp for the native toolchain is:

#define umul_ppmm(w1, w0, u, v) \
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))

(defined in longlong.h under the root of gmp-4.2.4)

The error given is:
dive_1.c:114:4: error: impossible constraint in 'asm'

dive_1.c:114 is: umul_ppmm (h, dummy, l, divisor);

Also, for my edification and learning, how does that asm line read?

Thanks in advance for your help!
Andy 


-----Original Message-----
From: buildroot-bounces@busybox.net
[mailto:buildroot-bounces at busybox.net] On Behalf Of Thomas Petazzoni
Sent: Thursday, December 23, 2010 1:28 AM
To: buildroot at busybox.net
Subject: Re: [Buildroot] oprofile "requires" gmp???

Hello,

On Wed, 22 Dec 2010 22:47:17 -0600
ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:

> buildroot v2011.02-git Configuration:
> 
> MIPS-32r2 using native toolchain, uclibc-0.9.31.x, gcc-4.5.x, binutils
> 2.20.1.
> 
> When I select oprofile from packages -> debug utils, gmp is selected,
> though the .config file reports # BR2_PACKAGE_LIBGMP is not set,
> though buildroot attempts to build it.
> 
> There are no dependencies for gmp listed in the oprofile help section.
> 
> What gives?

oprofile needs binutils on target, which in turns requires gmp on
target. So the fact that gmp gets compiled is normal.

However, the fact that BR2_PACKAGE_LIBGMP is not set is indeed
incorrect. But Gustavo has a patch series that rewrites how binutils,
gmp, mpfr are handled, so presumably he could fix that particular
problem as part of this patch set.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] oprofile "requires" gmp???

[Thomas Petazzoni]

Andy,

(Could you please avoid top-posting ? Thanks!)

On Thu, 23 Dec 2010 13:03:15 -0600
ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:

> Okay, I've done some tracking and have found the issue, but I don't know
> Mips asm that great (only 2 months into mips).
> 
> The code that it pukes at for building gmp for the native toolchain is:
> 
> #define umul_ppmm(w1, w0, u, v) \
> __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
> 
> (defined in longlong.h under the root of gmp-4.2.4)
> 
> The error given is:
> dive_1.c:114:4: error: impossible constraint in 'asm'
> dive_1.c:114 is: umul_ppmm (h, dummy, l, divisor);

Hum, maybe this has been fixed in more recent versions of gmp. Could
you try Gustavoz's toolchain-rework branch ? It bumps gmp to version
5.0.1, it's really the first thing to test before trying to fix an old
gmp version.

Gustavo's repository is at git://repo.or.cz/buildroot-gz.git, the
branch is toolchain-rework. Or you can get the individual patches at
http://lists.busybox.net/pipermail/buildroot/2010-December/039804.html.

> Also, for my edification and learning, how does that asm line read?

Well:

 * multu is the instruction

 * %2 says "the third argument in the argument list", so in our case,
   it's "d" (u)

 * %3 says "the fourth argument in the argument list", so in our case,
   it's "d" (v)

 * the part after the first colon is the list of output registers.
   See
   http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#s5
   for the syntax of what Gcc calls "extended assembly".

 * The "=l" (w0) tells gcc to put the contents of the LO register into
   the w0 variable. Presumably, the LO register contains a part of the
   result of the multiplication. The "l" is called a constraint, and is
   described at
   http://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints
   (section on MIPS).

 * Similarly, the "=h" (w1) tells gcc to put the contents of the HI
   register into the w1 variable. The gcc documentation say that this
   constraint is no longer supported, so probably the problem is here.

 * the part after the second colon is the list of input registers.

 * the "d" (u) and "d" (v) tell gcc to store the values of variables u
   and v into two "address registers", and use those registers instead
   of %2 and %3 in the instruction.

Regards,

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

[Buildroot] oprofile "requires" gmp???

[ANDY KENNEDY]

> Andy,
> 
> (Could you please avoid top-posting ? Thanks!)

I could try, though, if the brain is in the wrong mode, probably not ;).

> On Thu, 23 Dec 2010 13:03:15 -0600
> ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
> 
> > Okay, I've done some tracking and have found the issue, but I don't
> know
> > Mips asm that great (only 2 months into mips).
> >
> > The code that it pukes at for building gmp for the native toolchain
> is:
> >
> > #define umul_ppmm(w1, w0, u, v) \
> > __asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
> >
> > (defined in longlong.h under the root of gmp-4.2.4)
> >
> > The error given is:
> > dive_1.c:114:4: error: impossible constraint in 'asm'
> > dive_1.c:114 is: umul_ppmm (h, dummy, l, divisor);
> 
> Hum, maybe this has been fixed in more recent versions of gmp. Could
> you try Gustavoz's toolchain-rework branch ? It bumps gmp to version
> 5.0.1, it's really the first thing to test before trying to fix an old
> gmp version.
> 
> Gustavo's repository is at git://repo.or.cz/buildroot-gz.git, the
> branch is toolchain-rework. Or you can get the individual patches at
>
http://lists.busybox.net/pipermail/buildroot/2010-December/039804.html.

After doing a:
git clone git://repo.or.cz/buildroot-gz.git

I get worse results.  There are no dependencies for gmp now in the
toolchain for the target (IIRC, the previous version does select gmp
when target tool chain is selected -- though, that was last Thursday and
minus christmas eve, I've slept since then).  The toolchain is still not
required for building oprofile, though it does attempt to build it.

Did I perhaps use git incorrectly to not get the correct changes you
mentioned?  The gmp version was still 4.2.4 and I could find no place in
the config to change it to 5.0.1.

Thanks,
Andy

[Buildroot] oprofile "requires" gmp???

[Gustavo Zacarias]

On 12/27/10 15:15, ANDY KENNEDY wrote:

> After doing a:
> git clone git://repo.or.cz/buildroot-gz.git
> 
> I get worse results.  There are no dependencies for gmp now in the
> toolchain for the target (IIRC, the previous version does select gmp
> when target tool chain is selected -- though, that was last Thursday and
> minus christmas eve, I've slept since then).  The toolchain is still not
> required for building oprofile, though it does attempt to build it.
> 
> Did I perhaps use git incorrectly to not get the correct changes you
> mentioned?  The gmp version was still 4.2.4 and I could find no place in
> the config to change it to 5.0.1.
> 
> Thanks,
> Andy

git clone git://repo.or.cz/buildroot-gz.git toolchain-rework
is the correct syntax, otherwise you're just cloning my master repo
which is basically buildroot master, hence the same as cloning from
buildroot or getting a snapshot :)
Regards.

[Buildroot] oprofile "requires" gmp???

[Gustavo Zacarias]

On 12/27/10 15:15, Gustavo Zacarias wrote:

> On 12/27/10 15:15, ANDY KENNEDY wrote:
> 
>> After doing a:
>> git clone git://repo.or.cz/buildroot-gz.git
>>
>> I get worse results.  There are no dependencies for gmp now in the
>> toolchain for the target (IIRC, the previous version does select gmp
>> when target tool chain is selected -- though, that was last Thursday and
>> minus christmas eve, I've slept since then).  The toolchain is still not
>> required for building oprofile, though it does attempt to build it.
>>
>> Did I perhaps use git incorrectly to not get the correct changes you
>> mentioned?  The gmp version was still 4.2.4 and I could find no place in
>> the config to change it to 5.0.1.
>>
>> Thanks,
>> Andy
> 
> git clone git://repo.or.cz/buildroot-gz.git toolchain-rework
> is the correct syntax, otherwise you're just cloning my master repo
> which is basically buildroot master, hence the same as cloning from
> buildroot or getting a snapshot :)
> Regards.

Oh my bad, summer temperatures are killer today and i'm still sleepy
from a very festive weekend...
git clone git://repo.or.cz/buildroot-gz.git -b toolchain-rework
:)

[Buildroot] oprofile "requires" gmp???

[Gustavo Zacarias]

On 12/27/10 20:12, ANDY KENNEDY wrote:

> Gustavo,
> 
> Where did BR2_STAGING_DIR go?  I'm used to it being under Build Options,
> but I cannot find it.
> 
> In fact, when I put this in and did a make oldconfig it deleted my entry
> in the .config file.

Staging lives now in output/host/usr/tuple/sysroot, it's no longer an
option. We can keep

> Also, the gmp builds now -- they ifdef'ed out the asm code and replaced
> it with a do while (0) C code -- which makes more sense, I think.
> Though, I cannot get oprofile to build still.  The error message is:
> 
> /root/src/PRODUCTION/newbuildroo/buildroot-gz/output/host/usr/mips-unkno
> wn-linux-uclibc/sysroot/usr/lib/libbfd.a(archures.o): relocation
> R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a
> shared object; recompile with -fPIC
> /root/src/PRODUCTION/newbuildroo/buildroot-gz/output/host/usr/mips-unkno
> wn-linux-uclibc/sysroot/usr/lib/libbfd.a: could not read symbols: Bad
> value

Oh, bad mips.
Ok, we need a shared libbfd, i was hoping to get away with a static one
but it seems not.
Fixed in git, pull again and retry.

> . . . and before you say anything, yes I build as root ;).

Please don't, things should work and are far less risky without root.

> You want me to work these issues with you off-list until we (ur, you)
> get it fixed, or shall I trim just reply to the list (removing the
> /root/src etc and making it look like it is in a user's dir).
> 
> I don't mind either way.
> 
> I'm gone for the evening.  I'll catch up with you in the morning.  Enjoy
> the long hours of sunlight and warm temperatures!!!
> 
> Andy 

Keep copying the list, maybe someone else is interested in this or can
chime in with an idea.

[Buildroot] oprofile "requires" gmp??? Slight fork: BR2_STAGING_DIR

[ANDY KENNEDY]

> > Where did BR2_STAGING_DIR go?  I'm used to it being under Build
> Options,
> > but I cannot find it.
> >
> > In fact, when I put this in and did a make oldconfig it deleted my
> entry
> > in the .config file.
> 
> Staging lives now in output/host/usr/tuple/sysroot, it's no longer an
> option. We can keep


You have a period there after "option" with "We can keep" as a partial
sentence.  So, what does that mean exactly?  Do you mean "it's no longer
an option we can keep." or do you mean "it's no longer an option.  We
can keep [this if enough people want that option]."

If it is the latter, please keep this as an option as I use this option
extensively with our code management system.  

Andy

[Buildroot] oprofile "requires" gmp??? Slight fork: BR2_STAGING_DIR

[Gustavo Zacarias]

On 12/28/2010 01:19 PM, ANDY KENNEDY wrote:

>>> Where did BR2_STAGING_DIR go?  I'm used to it being under Build
>> Options,
>>> but I cannot find it.
>>>
>>> In fact, when I put this in and did a make oldconfig it deleted my
>> entry
>>> in the .config file.
>>
>> Staging lives now in output/host/usr/tuple/sysroot, it's no longer an
>> option. We can keep
> 
> 
> You have a period there after "option" with "We can keep" as a partial
> sentence.  So, what does that mean exactly?  Do you mean "it's no longer
> an option we can keep." or do you mean "it's no longer an option.  We
> can keep [this if enough people want that option]."
> 
> If it is the latter, please keep this as an option as I use this option
> extensively with our code management system.  
> 
> Andy

My failure for hitting send before finishing.
I was about to say that we can keep a symlink from staging->sysroot but
i'd rather watch it die because i can't think of any useful purpose
where people can't use the computed $(STAGING_DIR) directly.

[Buildroot] oprofile "requires" gmp??? Slight fork: BR2_STAGING_DIR

[ANDY KENNEDY]

> My failure for hitting send before finishing.
> I was about to say that we can keep a symlink from staging->sysroot
but
> i'd rather watch it die because i can't think of any useful purpose
> where people can't use the computed $(STAGING_DIR) directly.

Okay, perhaps I'm (mis)using/abusing what the toolchain directory option
was meant for.  I point the toolchain dir to something like
/opt/mips/gcc-<some identifier> because I'll do something like have a
small kernel with an initrd (usually statically compiled BusyBox with
MINIMAL tools, and one or two IP type utils), then the real RFS will
have all the libs associated with it.  The purpose for specifying the
toolchain dir in my case is so that I can set CROSS_COMPILE to
/opt/mips/gcc-small/usr/bin/mips-linux- or
/opt/mips/gcc-large/usr/bin/mips-linux- when I'm compiling against the
nano type system or the micro system respectively.  Usually, I'll make a
tar ball of these toolchains and throw them up onto the CMS so that
others don't have to compile the system just to get the toolchain for
that system.

Now, another e-mail I saw today from Peter Korsgaard titled "[Buildroot]
[git commit master 1/1] package: avoid copying .m4files from host to
staging" (to me) implies that I will be able to [easily] create a
toolchain "package" which will allow me to install it to wherever I
choose.

Now, am I wrong?  If I shouldn't be using the toolchain from the build
for making user-space apps for the system, what should I be doing?

Thanks again,
Andy

[Buildroot] oprofile "requires" gmp??? Slight fork: BR2_STAGING_DIR

[Thomas Petazzoni]

Hello,

On Tue, 28 Dec 2010 18:21:26 -0300
Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:

> I was about to say that we can keep a symlink from staging->sysroot
> but i'd rather watch it die because i can't think of any useful
> purpose where people can't use the computed $(STAGING_DIR) directly.

I think we should keep such a symbolic link, at least at the beginning.
It'll allow users to notice that staging/ still exists, but has moved
to another place.

Regards,

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

[Buildroot] oprofile "requires" gmp??? Slight fork: BR2_STAGING_DIR

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Hello,
 Thomas> On Tue, 28 Dec 2010 18:21:26 -0300
 Thomas> Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:

 >> I was about to say that we can keep a symlink from staging->sysroot
 >> but i'd rather watch it die because i can't think of any useful
 >> purpose where people can't use the computed $(STAGING_DIR) directly.

 Thomas> I think we should keep such a symbolic link, at least at the beginning.
 Thomas> It'll allow users to notice that staging/ still exists, but has moved
 Thomas> to another place.

Yes, I think that was also what we concluded at the last BR dev day.

-- 
Bye, Peter Korsgaard

[Buildroot] oprofile "requires" gmp???

[ANDY KENNEDY]

> Oh, bad mips.
> Ok, we need a shared libbfd, i was hoping to get away with a static
one
> but it seems not.
> Fixed in git, pull again and retry.

Okay, that fixed all the toolchain deps.  Everything looks  good in the
new toolchain when compiling with Linux Stable threads, however, it will
not build with Native Posix threads.  I'll work with that later to give
you more information as to what is broken and maybe a way to fix.


As far as oprofile goes, it doesn't build cleanly.  There are several
files that #include "limits.h".  Unfortunately, there are 5 versions of
this file in the include path.  The one that it actually needs is
#include <linux/limits.h>, and changing to this file works.  This seems
to be a common theme with the toolchain -- kexec needs the linux kernel
regdef.h, oprofile needs <linux/limits.h>.

Still poking around, will post more when I have it.

Andy

[Buildroot] oprofile "requires" gmp???

[Peter Korsgaard]

>>>>> "ANDY" == ANDY KENNEDY <ANDY.KENNEDY@adtran.com> writes:

Hi,

 ANDY> Okay, that fixed all the toolchain deps.  Everything looks  good in the
 ANDY> new toolchain when compiling with Linux Stable threads, however, it will
 ANDY> not build with Native Posix threads.  I'll work with that later to give
 ANDY> you more information as to what is broken and maybe a way to fix.

Does it break in libc/inet/netlinkaccess.h? Then it might be the same
issue as I recently reported on the uclibc list:

http://lists.uclibc.org/pipermail/uclibc/2010-December/044558.html

-- 
Bye, Peter Korsgaard

[Buildroot] oprofile "requires" gmp???

[ANDY KENNEDY]

> Does it break in libc/inet/netlinkaccess.h? Then it might be the same
> issue as I recently reported on the uclibc list:
> 
> http://lists.uclibc.org/pipermail/uclibc/2010-December/044558.html

I've got two issues with the build, neither appears to be the above.
One is that I'm hanging on a 'make oldconfig' on for uClibC:

Enable ... LD_PRELOAD... -- I accept the default of Y
use /etc/localtime ... -- I accept the default of Y
utmpx ... based ... -- I accept the default of N

I don't know whether this is only when selecting the option Native Posix
threads, but I believe it to be without regard of this choice.

The other almost looks like the same bfd problem as with oprofile, but
I'm not familiar with the errors I'm reading. - Time to talk to my ole
buddy Google.  Below is the a snippet of the output so that maybe you
can spot it.


In file included from libpthread/nptl/pthreadP.h:23:0,
                 from libpthread/nptl/pthread_testcancel.c:21:
./include/pthread.h:585:1: warning: no previous prototype for
'__pthread_cleanup_routine'
  CC libpthread/nptl/pthread_timedjoin.oS
In file included from libpthread/nptl/pthreadP.h:23:0,
                 from libpthread/nptl/pthread_timedjoin.c:23:
./include/pthread.h:585:1: warning: no previous prototype for
'__pthread_cleanup_routine'
libpthread/nptl/pthread_timedjoin.c: In function 'pthread_timedjoin_np':
libpthread/nptl/pthread_timedjoin.c:67:1: warning: assignment makes
pointer from integer without a cast
libpthread/nptl/pthread_timedjoin.c:67:1: warning: assignment makes
pointer from integer without a cast
libpthread/nptl/pthread_timedjoin.c:67:1: warning: assignment makes
pointer from integer without a cast
  CC libpthread/nptl/pthread_tryjoin.oS
libpthread/nptl/pthread_tryjoin.c: In function 'pthread_tryjoin_np':
libpthread/nptl/pthread_tryjoin.c:62:1: warning: assignment makes
pointer from integer without a cast
libpthread/nptl/pthread_tryjoin.c:62:1: warning: assignment makes
pointer from integer without a cast
libpthread/nptl/pthread_tryjoin.c:62:1: warning: assignment makes
pointer from integer without a cast
  CC libpthread/nptl/res.oS
  CC libpthread/nptl/sem_close.oS
  CC libpthread/nptl/sem_destroy.oS
  CC libpthread/nptl/sem_getvalue.oS
  CC libpthread/nptl/sem_init.oS
  CC libpthread/nptl/sem_open.oS
  CC libpthread/nptl/sem_unlink.oS
  CC libpthread/nptl/unwind.oS
In file included from libpthread/nptl/pthreadP.h:23:0,
                 from libpthread/nptl/unwind.c:25:
./include/pthread.h:585:1: warning: no previous prototype for
'__pthread_cleanup_routine'
libpthread/nptl/unwind.c:33:7: warning: "_STACK_GROWS_UP" is not defined
libpthread/nptl/unwind.c:120:1: warning: redeclaration of
'__pthread_unwind' with different visibility (old visibility preserved)
libpthread/nptl/pthreadP.h:244:1: note: previous declaration of
'__pthread_unwind' was here
libpthread/nptl/unwind.c: In function 'unwind_cleanup':
libpthread/nptl/unwind.c:103:1: warning: function might be possible
candidate for attribute 'noreturn'
  CC libpthread/nptl/vars.oS
  AR cr libpthread/nptl/libpthread_so.a
  STRIP -X --strip-debug -R .note -R .comment
libpthread/nptl/libpthread_so.a
  CC libpthread/nptl/pthread_atfork.oS
  AR cr lib/libpthread_nonshared.a
  STRIP -x -R .note -R .comment lib/libpthread_nonshared.a
  LD libpthread-0.9.32-rc1.so
/root/src/PRODUCTION/newbuildroo/buildroot-gz/output/host/usr/lib/gcc/mi
ps-unknown-linux-uclibc/4.5.2/../../../../mips-unknown-linux-uclibc/bin/
ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3157
/root/src/PRODUCTION/newbuildroo/buildroot-gz/output/host/usr/lib/gcc/mi
ps-unknown-linux-uclibc/4.5.2/../../../../mips-unknown-linux-uclibc/bin/
ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3161
libpthread/nptl/libpthread_so.a(sem_open.oS): In function `sem_open':
(.text+0x544): relocation truncated to fit: R_MIPS_CALL16 against
`__pthread_once'
/root/src/PRODUCTION/newbuildroo/buildroot-gz/output/host/usr/lib/gcc/mi
ps-unknown-linux-uclibc/4.5.2/../../../../mips-unknown-linux-uclibc/bin/
ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3157
/root/src/PRODUCTION/newbuildroo/buildroot-gz/output/host/usr/lib/gcc/mi
ps-unknown-linux-uclibc/4.5.2/../../../../mips-unknown-linux-uclibc/bin/
ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3161
libpthread/nptl/libpthread_so.a(sem_unlink.oS): In function
`sem_unlink':
(.text+0x10): relocation truncated to fit: R_MIPS_CALL16 against
`__pthread_once'
collect2: ld returned 1 exit status
make[1]: *** [lib/libpthread.so] Error 1
make[1]: Leaving directory
`/root/src/PRODUCTION/newbuildroo/buildroot-gz/output/toolchain/uClibc-0
.9.32-rc1'
make: ***
[/root/src/PRODUCTION/newbuildroo/buildroot-gz/output/toolchain/uClibc-0
.9.32-rc1/lib/libc.a] Error 2

[Buildroot] oprofile "requires" gmp???

[Gustavo Zacarias]

On 12/29/2010 06:54 PM, ANDY KENNEDY wrote:

> /root/src/PRODUCTION/newbuildroo/buildroot-gz/output/host/usr/lib/gcc/mi
> ps-unknown-linux-uclibc/4.5.2/../../../../mips-unknown-linux-uclibc/bin/
> ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3157
> /root/src/PRODUCTION/newbuildroo/buildroot-gz/output/host/usr/lib/gcc/mi
> ps-unknown-linux-uclibc/4.5.2/../../../../mips-unknown-linux-uclibc/bin/
> ld: BFD (GNU Binutils) 2.21 assertion fail elfxx-mips.c:3161
> libpthread/nptl/libpthread_so.a(sem_unlink.oS): In function
> `sem_unlink':
> (.text+0x10): relocation truncated to fit: R_MIPS_CALL16 against
> `__pthread_once'
> collect2: ld returned 1 exit status
> make[1]: *** [lib/libpthread.so] Error 1
> make[1]: Leaving directory
> `/root/src/PRODUCTION/newbuildroo/buildroot-gz/output/toolchain/uClibc-0
> .9.32-rc1'
> make: ***
> [/root/src/PRODUCTION/newbuildroo/buildroot-gz/output/toolchain/uClibc-0
> .9.32-rc1/lib/libc.a] Error 2

Tweak your uclibc config file and do UCLIBC_EXTRA_CFLAGS="-mxgot" and
watch the problem dissapear :-)
I'm still pondering if we should provide an option to tweak uclibc build
cflags, on one side it's nice to debug this issues, on the other it's a
sharp knife - it all boils down on usage.

[Buildroot] oprofile "requires" gmp???

[ANDY KENNEDY]

> Okay, that fixed all the toolchain deps.  Everything looks  good in
the
> new toolchain when compiling with Linux Stable threads, however, it
> will not build with Native Posix threads.  I'll work with that later
to
> give you more information as to what is broken and maybe a way to fix.

<snip>
 
> Still poking around, will post more when I have it.
> 
> Andy

Strange.  I built earlier today and I get an error on every file that
includes limits.  I did a make clean, make menuconfig and select linux
threads stable, change the build options to 50 simultaneous jobs and I
don't get the errors on the limits not having the PATH_MAX and PIPE_BUF.

Now, I must attempt this again with 2 jobs as I was doing earlier when I
got this.  Is there something that oprofile depends on that is being
built out-of-order with 2 jobs vs. 50?

Whether it breaks again, I'll let you know.

Andy

[Buildroot] oprofile "requires" gmp???

[ANDY KENNEDY]

> -----Original Message-----
> From: ANDY KENNEDY
> Sent: Wednesday, December 29, 2010 4:42 PM
> To: 'buildroot at busybox.net'
> Subject: RE: [Buildroot] oprofile "requires" gmp???
> 
> > Okay, that fixed all the toolchain deps.  Everything looks  good in
> the
> > new toolchain when compiling with Linux Stable threads, however, it
> > will not build with Native Posix threads.  I'll work with that later
> to
> > give you more information as to what is broken and maybe a way to
> fix.
> 
> <snip>
> 
> > Still poking around, will post more when I have it.
> >
> > Andy
> 
> Strange.  I built earlier today and I get an error on every file that
> includes limits.  I did a make clean, make menuconfig and select linux
> threads stable, change the build options to 50 simultaneous jobs and I
> don't get the errors on the limits not having the PATH_MAX and
> PIPE_BUF.
> 
> Now, I must attempt this again with 2 jobs as I was doing earlier when
> I got this.  Is there something that oprofile depends on that is being
> built out-of-order with 2 jobs vs. 50?
> 
> Whether it breaks again, I'll let you know.
> 
> Andy


oprofile builds just fine -- no errors with the limits include this time
either.  Guess the other was a fluke?