[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[ulf at uclibc.org]

Author: ulf
Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
New Revision: 20237

Log:
Allow library copy to fail

Modified:
   trunk/buildroot/toolchain/gcc/gcc-uclibc-3.x.mk
   trunk/buildroot/toolchain/gcc/gcc-uclibc-4.x.mk


Changeset:
Modified: trunk/buildroot/toolchain/gcc/gcc-uclibc-3.x.mk
===================================================================
--- trunk/buildroot/toolchain/gcc/gcc-uclibc-3.x.mk	2007-10-12 15:18:27 UTC (rev 20236)
+++ trunk/buildroot/toolchain/gcc/gcc-uclibc-3.x.mk	2007-10-12 21:01:41 UTC (rev 20237)
@@ -332,13 +332,13 @@
 ifeq ($(BR2_GCC_SHARED_LIBGCC),y)
 	# These are in /lib, so...
 	rm -rf $(TARGET_DIR)/usr/lib/libgcc_s*.so*
-	cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s* \
+	-cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s* \
 		$(TARGET_DIR)/lib/
 	-strip --strip-unneeded $(TARGET_DIR)/lib/libgcc_s*
 endif
 ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
 ifeq ($(BR2_GCC_SHARED_LIBGCC),y)
-	cp -dpf $(STAGING_DIR)/lib/libstdc++.so* $(TARGET_DIR)/usr/lib/
+	-cp -dpf $(STAGING_DIR)/lib/libstdc++.so* $(TARGET_DIR)/usr/lib/
 	-strip --strip-unneeded $(TARGET_DIR)/usr/lib/libstdc++.so*
 endif
 endif

Modified: trunk/buildroot/toolchain/gcc/gcc-uclibc-4.x.mk
===================================================================
--- trunk/buildroot/toolchain/gcc/gcc-uclibc-4.x.mk	2007-10-12 15:18:27 UTC (rev 20236)
+++ trunk/buildroot/toolchain/gcc/gcc-uclibc-4.x.mk	2007-10-12 21:01:41 UTC (rev 20237)
@@ -345,12 +345,12 @@
 ifeq ($(BR2_GCC_SHARED_LIBGCC),y)
 	# These are in /lib, so...
 	rm -rf $(TARGET_DIR)/usr/lib/libgcc_s*.so*
-	cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s* \
+	-cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libgcc_s* \
 		$(TARGET_DIR)/lib/
 endif
 ifeq ($(BR2_INSTALL_LIBSTDCPP),y)
 ifeq ($(BR2_GCC_SHARED_LIBGCC),y)
-	cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libstdc++.so* \
+	-cp -dpf $(STAGING_DIR)/usr/$(REAL_GNU_TARGET_NAME)/lib/libstdc++.so* \
 		$(TARGET_DIR)/usr/lib/
 endif
 endif

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Cristian Ionescu-Idbohrn]

On Fri, 12 Oct 2007, ulf at uclibc.org wrote:

> Author: ulf
> Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
> New Revision: 20237
>
> Log:
> Allow library copy to fail

As it's not obvious to me, may I ask why?
Why not making sure it doesn't fail, instead?


Cheers,

-- 
Cristian

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Ulf Samuelsson]

l?r 2007-10-13 klockan 10:49 +0200 skrev Cristian Ionescu-Idbohrn:
> On Fri, 12 Oct 2007, ulf at uclibc.org wrote:
> 
> > Author: ulf
> > Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
> > New Revision: 20237
> >
> > Log:
> > Allow library copy to fail
> 
> As it's not obvious to me, may I ask why?
> Why not making sure it doesn't fail, instead?

That is the long term approach, but I have no control over that part.

If copying fails, then libgcc.a is available,
and the end application can be linked with this instead
It is better than aborting the build.

> 
> Cheers,
> 
-- 
Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Cristian Ionescu-Idbohrn]

On Sat, 13 Oct 2007, Ulf Samuelsson wrote:

> l?r 2007-10-13 klockan 10:49 +0200 skrev Cristian Ionescu-Idbohrn:
> > On Fri, 12 Oct 2007, ulf at uclibc.org wrote:
> >
> > > Author: ulf
> > > Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
> > > New Revision: 20237
> > >
> > > Log:
> > > Allow library copy to fail
> >
> > As it's not obvious to me, may I ask why?
> > Why not making sure it doesn't fail, instead?
>
> That is the long term approach, but I have no control over that part.

Who has the "control over that part"?

> If copying fails,

Why should it?
Have you seen it failing?
Can you reproduce that?
Is there a use case you can share with us?

> then libgcc.a is available,
> and the end application can be linked with this instead

I see.

> It is better than aborting the build.

But doesn't cure the disease :(
In other words, you prefer aspirine :)


Cheers,

-- 
Cristian

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Bernhard Fischer]

On Sat, Oct 13, 2007 at 12:19:42PM +0200, Cristian Ionescu-Idbohrn wrote:
>On Sat, 13 Oct 2007, Ulf Samuelsson wrote:
>
>> l?r 2007-10-13 klockan 10:49 +0200 skrev Cristian Ionescu-Idbohrn:
>> > On Fri, 12 Oct 2007, ulf at uclibc.org wrote:
>> >
>> > > Author: ulf
>> > > Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
>> > > New Revision: 20237
>> > >
>> > > Log:
>> > > Allow library copy to fail
>> >
>> > As it's not obvious to me, may I ask why?
>> > Why not making sure it doesn't fail, instead?
>>
>> That is the long term approach, but I have no control over that part.
>
>Who has the "control over that part"?
>
>> If copying fails,
>
>Why should it?
>Have you seen it failing?
>Can you reproduce that?

It can be seen with x86_64 as target; see archives for my suggestion on
how to fix this properly instead of once again papering over a bug in an
inappropriate way.

>Is there a use case you can share with us?
>
>> then libgcc.a is available,
>> and the end application can be linked with this instead
>
>I see.
>
>> It is better than aborting the build.
>
>But doesn't cure the disease :(

It's plain wrong i would have said.

>In other words, you prefer aspirine :)

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Ulf Samuelsson]

l?r 2007-10-13 klockan 12:19 +0200 skrev Cristian Ionescu-Idbohrn:
> On Sat, 13 Oct 2007, Ulf Samuelsson wrote:
> 
> > l?r 2007-10-13 klockan 10:49 +0200 skrev Cristian Ionescu-Idbohrn:
> > > On Fri, 12 Oct 2007, ulf at uclibc.org wrote:
> > >
> > > > Author: ulf
> > > > Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
> > > > New Revision: 20237
> > > >
> > > > Log:
> > > > Allow library copy to fail
> > >
> > > As it's not obvious to me, may I ask why?
> > > Why not making sure it doesn't fail, instead?
> >
> > That is the long term approach, but I have no control over that part.
> 
> Who has the "control over that part"?
> 
The guys at Atmel responsible for supporting the AVR32 gcc port...
They have started to take an interest, but I have no clue
when a fix will appear.

I do not have the bandwidth to dig into this.

> > If copying fails,
> 
> Why should it?
> Have you seen it failing?
> Can you reproduce that?

Yes, this is the cause of the failure of the AVR32 tool build.
It built during the summer, and then suddenly stopped building.

> Is there a use case you can share with us?
> 

Take an older snapshot and try to build AVR32 toolchain.
The libgcc_s.so.1 does not get built.

> > then libgcc.a is available,
> > and the end application can be linked with this instead
> 
> I see.
> 
> > It is better than aborting the build.
> 
> But doesn't cure the disease :(
> In other words, you prefer aspirine :)

If this ensures that I can run the code on the AVR32
then it is good enough for me at this point.
Obviously it is better to ensure that the AVR32 toolchain
build generates a shared library, and anyone complaining
are open to develop a patch which fixes the real problem
instead of the symptom.


> 
> Cheers,
> 
-- 
Best Regards
Ulf Samuelsson
Atmel Nordic AB

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Cristian Ionescu-Idbohrn]

On Sat, 13 Oct 2007, Ulf Samuelsson wrote:

> l?r 2007-10-13 klockan 12:19 +0200 skrev Cristian Ionescu-Idbohrn:
> > On Sat, 13 Oct 2007, Ulf Samuelsson wrote:
> >
> > > l?r 2007-10-13 klockan 10:49 +0200 skrev Cristian Ionescu-Idbohrn:
> > > > On Fri, 12 Oct 2007, ulf at uclibc.org wrote:
> > > >
> > > > > Author: ulf
> > > > > Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
> > > > > New Revision: 20237
> > > > >
> > > > > Log:
> > > > > Allow library copy to fail
> > > >
> > > > As it's not obvious to me, may I ask why?
> > > > Why not making sure it doesn't fail, instead?
> > >
> > > That is the long term approach, but I have no control over that part.
> >
> > Who has the "control over that part"?
> >
> The guys at Atmel responsible for supporting the AVR32 gcc port...
> They have started to take an interest, but I have no clue
> when a fix will appear.

Sorry if I missed something, but what's the involvement the guys at Atmel
have in this project?  Do they have some sort of maintenance
responsabilities in this project?  Do they sponsor this project in some
way?  Are you working for the guys at Atmel?

> I do not have the bandwidth to dig into this.

I'm realy sorry for you (and for the rest of us using other archs), but
the way you treat the buildroot project is not really acceptable.
If you don't have the bandwidth to do things right, maybe the guys at
Atmel can buy you some more bandwidth so you can do dig and make proper
changes that don't break other archs.

> > > If copying fails,
> >
> > Why should it?
> > Have you seen it failing?
> > Can you reproduce that?
>
> Yes, this is the cause of the failure of the AVR32 tool build.

But doesn't that mean that the AVR32 tool is broken?
What am I missing here?

> It built during the summer, and then suddenly stopped building.

And that means that all other archs that _do build_ must be broken?
Sorry, doesn't make much sense to me :(

> > Is there a use case you can share with us?
> >
>
> Take an older snapshot and try to build AVR32 toolchain.
> The libgcc_s.so.1 does not get built.

Not interested to build any AVR32 toolchain myself.  I'm quite happy if
the other toolchains do build.

> > > then libgcc.a is available,
> > > and the end application can be linked with this instead
> >
> > I see.
> >
> > > It is better than aborting the build.
> >
> > But doesn't cure the disease :(
> > In other words, you prefer aspirine :)
>
> If this ensures that I can run the code on the AVR32
> then it is good enough for me at this point.

What about the rest of us?

> Obviously it is better to ensure that the AVR32 toolchain
> build generates a shared library,

Obviously it is better to ensure that _all_ toolchains build, I'd say.

> and anyone complaining
> are open to develop a patch which fixes the real problem
> instead of the symptom.

So, all other toolchains that occasionally build (until you you break
them) must be broken, and that's not your problem?

All you talk about is AVR32.
You seem to only care about AVR32.
You couldn't care less if you break all other archs with your patches?
Is this fare play?


Cheers,

-- 
Cristian

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Ulf Samuelsson]

l?r 2007-10-13 klockan 21:58 +0200 skrev Cristian Ionescu-Idbohrn:
> On Sat, 13 Oct 2007, Ulf Samuelsson wrote:
> 
> > l?r 2007-10-13 klockan 12:19 +0200 skrev Cristian Ionescu-Idbohrn:
> > > On Sat, 13 Oct 2007, Ulf Samuelsson wrote:
> > >
> > > > l?r 2007-10-13 klockan 10:49 +0200 skrev Cristian Ionescu-Idbohrn:
> > > > > On Fri, 12 Oct 2007, ulf at uclibc.org wrote:
> > > > >
> > > > > > Author: ulf
> > > > > > Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
> > > > > > New Revision: 20237
> > > > > >
> > > > > > Log:
> > > > > > Allow library copy to fail
> > > > >
> > > > > As it's not obvious to me, may I ask why?
> > > > > Why not making sure it doesn't fail, instead?
> > > >
> > > > That is the long term approach, but I have no control over that part.
> > >
> > > Who has the "control over that part"?
> > >
> > The guys at Atmel responsible for supporting the AVR32 gcc port...
> > They have started to take an interest, but I have no clue
> > when a fix will appear.
> 
> Sorry if I missed something, but what's the involvement the guys at Atmel
> have in this project?  Do they have some sort of maintenance
> responsabilities in this project?  Do they sponsor this project in some
> way?  Are you working for the guys at Atmel?

The guys at Atmel do the gcc ports for AVR32.
I am trying to make it easier for other people to build it.

> > I do not have the bandwidth to dig into this.
> 
> I'm realy sorry for you (and for the rest of us using other archs), but
> the way you treat the buildroot project is not really acceptable.

> If you don't have the bandwidth to do things right, maybe the guys at
> Atmel can buy you some more bandwidth so you can do dig and make proper
> changes that don't break other archs.

This change does not break any other arch.
It used to be "-cp", and the change to "cp" broke the AVR32 arch.

> > > > If copying fails,
> > >
> > > Why should it?
> > > Have you seen it failing?
> > > Can you reproduce that?
> >
> > Yes, this is the cause of the failure of the AVR32 tool build.
> 
> But doesn't that mean that the AVR32 tool is broken?
> What am I missing here?

Yes and No.
By reverting the patch, which broke the AVR32 build,
it is possible to create an AVR32 gcc compiler which
uses an non-shared libgcc.a to create a uClibc based root gfs.

> > It built during the summer, and then suddenly stopped building.
> 
> And that means that all other archs that _do build_ must be broken?
> Sorry, doesn't make much sense to me :(
> 

Can you explain why all other archs are broken?
If the build works for all other archs, then the cp will work.


> > > Is there a use case you can share with us?
> > >
> >
> > Take an older snapshot and try to build AVR32 toolchain.
> > The libgcc_s.so.1 does not get built.
> 
> Not interested to build any AVR32 toolchain myself.  I'm quite happy if
> the other toolchains do build.
> 

> > > > then libgcc.a is available,
> > > > and the end application can be linked with this instead
> > >
> > > I see.
> > >
> > > > It is better than aborting the build.
> > >
> > > But doesn't cure the disease :(
> > > In other words, you prefer aspirine :)
> >
> > If this ensures that I can run the code on the AVR32
> > then it is good enough for me at this point.
> 
> What about the rest of us?
> 

You have not explained in what way you suffer.

> > Obviously it is better to ensure that the AVR32 toolchain
> > build generates a shared library,
> 
> Obviously it is better to ensure that _all_ toolchains build, I'd say.
> 
> > and anyone complaining
> > are open to develop a patch which fixes the real problem
> > instead of the symptom.
> 
> So, all other toolchains that occasionally build (until you you break
> them) must be broken, and that's not your problem?
> 
> All you talk about is AVR32.
> You seem to only care about AVR32.
> You couldn't care less if you break all other archs with your patches?
> Is this fare play?

No, I care about other archs as well, but I do not belive that they
are broken by the patch.
I regularily build ARM and i386 as well.
Can you show why this breaks anything?
Remember: It used to be this way until this summer.

> 
> Cheers,
> 
-- 
Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Cristian Ionescu-Idbohrn]

On Sat, 13 Oct 2007, Ulf Samuelsson wrote:

> The guys at Atmel do the gcc ports for AVR32.

I see.

> I am trying to make it easier for other people to build it.

That's nice of you.

> This change does not break any other arch.

Fair enough.  You may be right.

> It used to be "-cp", and the change to "cp" broke the AVR32 arch.

Alright.  Why don't you then make that '-cp' conditional on AVR32 and
leave it 'cp' for all other?  In a way that would help identify oddities
with AVR32 everywhere.  One size fits all is quite hard to find.

> > But doesn't that mean that the AVR32 tool is broken?
> > What am I missing here?
>
> Yes and No.

I was expecting that ;)

> By reverting the patch, which broke the AVR32 build,
> it is possible to create an AVR32 gcc compiler which
> uses an non-shared libgcc.a to create a uClibc based root gfs.

Thanks for the explanation.

> Can you explain why all other archs are broken?

I'm afraid I can't.  And I won't bother trying to. It may be unfair to
blame all buildroot brokenness on you.  Still, buildroot is broken in
various places.  One thing gets fixed and two other break.  That's my
experience of the passed weeks :(

> If the build works for all other archs, then the cp will work.

Yes, I agree.  'cp' shouldn't be a problem in this context.  Still, if for
some misterious reason it doesn't get built, '-cp' doesn't break the build
making us aware of that and things break later in other places?  Trouble
shooting that scenario will be more painful, IMO.

> You have not explained in what way you suffer.

Thanks, I got better after getting out the previous post ;)

I'll try to explain.  Every time I check out a new tree, it takes one or
several days to get it to build.  And when I think I'm done (save some
patches not yet accepted upstream), check out a new tree, apply my
patches, I start seeing things breaking again in various ways and I have
to start all over again.  And that's _very_ frustrating!

Happened again today :(

> No, I care about other archs as well, but I do not belive that they are
> broken by the patch.

Good to know.

> I regularily build ARM and i386 as well.

Care to share your i386 .config with the rest of us?

> Can you show why this breaks anything?
> Remember: It used to be this way until this summer.

You mean the 'cp' thing?  See above.

Can we try getting some stability in this project?
Can we get a 'make allconfig' that just builds?
Sooner rather than later?

ATM, I see lockfile-progs (patch available in bugtrack) and microperl
won't build.

Please find attached some patches (various fixes).


Cheers,

-- 
Cristian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: br-2007-10-14.submit.patch
Type: text/x-diff
Size: 13136 bytes
Desc: 
Url : http://busybox.net/lists/buildroot/attachments/20071014/a3b62cd5/attachment.bin 

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Ivan Kuten]

> 
> Can we try getting some stability in this project?
> Can we get a 'make allconfig' that just builds?
> Sooner rather than later?
> 

[Buildroot] Some devices are not created in the ext2 filesystem.

[Leonid]

Hi:

I need some device nodes for my proprietary driver and I have added
appropriate lines to the end of
target/device/Atmel/root/device_table.txt table I'm using:

# AKA driver
/dev/mcfp-0    c    640    0       0      254      0       0       0
-
/dev/mcfp-1    c    640    0       0      254      1       0       0
-

I see that correspondent files are indeed created in the root filesystem
tree:

[leonid at jaipur buildroot]$ ls -al root/dev/mc*
-rw-r----- 1 root root 0 2007-10-13 21:56 root/dev/mcfp-0
-rw-r----- 1 root root 0 2007-10-13 21:56 root/dev/mcfp-1

However when I load my ext2 root filesystem, I don't see these device
nodes in /dev directory. What is wrong?

Thanks,

Leonid.

[Buildroot] Some devices are not created in the ext2 filesystem.

[Ivan Kuten]

> I see that correspondent files are indeed created in the root filesystem
> tree:
> 
> [leonid at jaipur buildroot]$ ls -al root/dev/mc*
> -rw-r----- 1 root root 0 2007-10-13 21:56 root/dev/mcfp-0
> -rw-r----- 1 root root 0 2007-10-13 21:56 root/dev/mcfp-1
> 
> However when I load my ext2 root filesystem, I don't see these device
> nodes in /dev directory. What is wrong?
> 

Check that you are not using udev, because udev is mounted over /dev
thus hiding your entries.

BR,
Ivan

--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------

[Buildroot] Some devices are not created in the ext2 filesystem.

[softa at ttechgroup.com]

----- Original Message ----- 
From: "Ivan Kuten" <ivan.kuten@promwad.com>
To: "Leonid" <Leonid@a-k-a.net>
Cc: <buildroot@uclibc.org>
Sent: Sunday, October 14, 2007 3:43 PM
Subject: Re: [Buildroot] Some devices are not created in the ext2 
filesystem.


>> I see that correspondent files are indeed created in the root filesystem
>> tree:
>>
>> [leonid at jaipur buildroot]$ ls -al root/dev/mc*
>> -rw-r----- 1 root root 0 2007-10-13 21:56 root/dev/mcfp-0
>> -rw-r----- 1 root root 0 2007-10-13 21:56 root/dev/mcfp-1
>>
>> However when I load my ext2 root filesystem, I don't see these device
>> nodes in /dev directory. What is wrong?
>>
>
> Check that you are not using udev, because udev is mounted over /dev
> thus hiding your entries.

Listed files are regular files, not device nodes! Use devicetable.txt for 
creating device nodes.

BR
Assen

>
> BR,
> Ivan
>
> --------------------------------
> Embedded Linux engineer,
> Promwad Company: http://www.promwad.com/
> Homepage : http://www.ivankuten.com/
> --------------------------------
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot 

[Buildroot] Some devices are not created in the ext2 filesystem.

[Ivan Kuten]

> 
> Listed files are regular files, not device nodes! Use devicetable.txt for 
> creating device nodes.
> 
> BR
> Assen
> 

Assen, but Leonid did use device_table.txt , see his previous post:

>I need some device nodes for my proprietary driver and I have added
>appropriate lines to the end of
>target/device/Atmel/root/device_table.txt table I'm using:


BR,
Ivan
--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------

[Buildroot] Some devices are not created in the ext2 filesystem.

[softa at ttechgroup.com]

----- Original Message ----- 
From: "Ivan Kuten" <ivan.kuten@promwad.com>
To: <softa@ttechgroup.com>
Cc: "Leonid" <Leonid@a-k-a.net>; <buildroot@uclibc.org>
Sent: Sunday, October 14, 2007 7:59 PM
Subject: Re: [Buildroot] Some devices are not created in the ext2 
filesystem.


>>
>> Listed files are regular files, not device nodes! Use devicetable.txt for
>> creating device nodes.
>>
>> BR
>> Assen
>>
>
> Assen, but Leonid did use device_table.txt , see his previous post:

OK, sorry, my mistake.

>
>>I need some device nodes for my proprietary driver and I have added
>>appropriate lines to the end of
>>target/device/Atmel/root/device_table.txt table I'm using:
>
>
> BR,
> Ivan
> --------------------------------
> Embedded Linux engineer,
> Promwad Company: http://www.promwad.com/
> Homepage : http://www.ivankuten.com/
> -------------------------------- 

[Buildroot] Some devices are not created in the ext2 filesystem.

[Leonid]

Hi, Ivan:

Your guess was right: I have learnt that udev is used in my build indeed
and my (proprietary) driver doesn't bother to register its nodes with
sysfs filesystem. Now everything is clear thank you. 

For the time being (I didn't want to change code just yet) I added mknod
commands to rcS file, so necessary nodes are created upon restart. 

I also see some error from udev:

Populating /dev using udev: cannot open /dev/null
done

/dev/null is certainly present:

# ls -al /dev/null
crw-rw----    1 root     root       1,   3 Dec 31 17:00 /dev/null

What this error is about?

Thanks,

Leonid.

-----Original Message-----
From: buildroot-bounces@uclibc.org [mailto:buildroot-bounces at uclibc.org]
On Behalf Of Ivan Kuten
Sent: Sunday, October 14, 2007 5:43 AM
To: Leonid
Cc: buildroot at uclibc.org
Subject: Re: [Buildroot] Some devices are not created in the ext2
filesystem.

> I see that correspondent files are indeed created in the root
filesystem
> tree:
> 
> [leonid at jaipur buildroot]$ ls -al root/dev/mc*
> -rw-r----- 1 root root 0 2007-10-13 21:56 root/dev/mcfp-0
> -rw-r----- 1 root root 0 2007-10-13 21:56 root/dev/mcfp-1
> 
> However when I load my ext2 root filesystem, I don't see these device
> nodes in /dev directory. What is wrong?
> 

Check that you are not using udev, because udev is mounted over /dev
thus hiding your entries.

BR,
Ivan

--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------
_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Some devices are not created in the ext2 filesystem.

[Ivan Kuten]

> I also see some error from udev:
> 
> Populating /dev using udev: cannot open /dev/null
> done
> 
> /dev/null is certainly present:
> 
> # ls -al /dev/null
> crw-rw----    1 root     root       1,   3 Dec 31 17:00 /dev/null
> 
> What this error is about?
> 

I think it can not just open /dev/null. If udev is run as udev user,
crw-rw----    1 root     root       1,   3 Dec 31 17:00 /dev/null

/dev/null could not be opened because rw-rw--- but not rw-rw-rw

BR,
Ivan

--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------

[Buildroot] Some devices are not created in the ext2 filesystem.

[Leonid]

Hi, Ivan:

As I see also on other systems, /dev/null is normally created with 660
permission like many other devices (/dev/console for example). I thought
that buildroot runs udev with correct user to be able to rewrite all
devices in /dev without trouble. 

So, I suppose, my question is this: is it some intrinsic buildroot
udev-related bug or something wrong in my own system which results in
such error? What would you recommend to do?

Thanks,

Leonid.

-----Original Message-----
From: buildroot-bounces@uclibc.org [mailto:buildroot-bounces at uclibc.org]
On Behalf Of Ivan Kuten
Sent: Sunday, October 14, 2007 2:33 PM
To: Leonid
Cc: buildroot at uclibc.org
Subject: Re: [Buildroot] Some devices are not created in the ext2
filesystem.

> I also see some error from udev:
> 
> Populating /dev using udev: cannot open /dev/null
> done
> 
> /dev/null is certainly present:
> 
> # ls -al /dev/null
> crw-rw----    1 root     root       1,   3 Dec 31 17:00 /dev/null
> 
> What this error is about?
> 

I think it can not just open /dev/null. If udev is run as udev user,
crw-rw----    1 root     root       1,   3 Dec 31 17:00 /dev/null

/dev/null could not be opened because rw-rw--- but not rw-rw-rw

BR,
Ivan

--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------
_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Some devices are not created in the ext2 filesystem.

[Ivan Kuten]

Leonid wrote:
> Hi, Ivan:
> 
> As I see also on other systems, /dev/null is normally created with 660
> permission like many other devices (/dev/console for example). I thought
> that buildroot runs udev with correct user to be able to rewrite all
> devices in /dev without trouble. 
> 
> So, I suppose, my question is this: is it some intrinsic buildroot
> udev-related bug or something wrong in my own system which results in
> such error? What would you recommend to do?
> 

I'd suggest just turn udev off.


Best regards,
Ivan

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Ulf Samuelsson]

>> The guys at Atmel do the gcc ports for AVR32.
> I see.
> 
>> I am trying to make it easier for other people to build it.
> That's nice of you.
> 
>> This change does not break any other arch.
> Fair enough.  You may be right.
> 
>> It used to be "-cp", and the change to "cp" broke the AVR32 arch.
> 
> Alright.  Why don't you then make that '-cp' conditional on AVR32 and
> leave it 'cp' for all other?  In a way that would help identify oddities
> with AVR32 everywhere.  One size fits all is quite hard to find.
> 

Some people are against having architecture specific extensions in the common files.
I believe it is better to continue the build, and then do a verify afterwards.
If you read archives, a lot of people consider the libgcc_s to be a PITA.

>> Can you explain why all other archs are broken?
> 
> I'm afraid I can't.  And I won't bother trying to. It may be unfair to
> blame all buildroot brokenness on you.  Still, buildroot is broken in
> various places.  One thing gets fixed and two other break.  That's my
> experience of the passed weeks :(
> 

The "-cp" -> "cp" patch has caused me several hundred hours
of extra work, and this can all be blamed on Bernhard.
Any problems caused by patches trying to fix the broken AVR32
can therefore indirectly be blamed on Bernhard as well.

In practice, I do *not* want to blame Bernhard for *that* patch, since it 
very difficult to do a full test of buildroot using all parameters.

However, Bernhard has a policy which is to always use the latest stuff,
which makes IMHO Buildroot, nothing more than a (nice) toy.

You reported a build problem with JPEG and think that creating
a directory in $(STAGING_DIR) during the jpeg build
was the problem which caused the toolchain build to fail.
You probably only need to reflect on this for a millisecond or so to 
realize how absurd that is...

I rather think this is a result of Bernhards patch to deprecate older
versions of Binutils, automatically changing an existing *working* ".config" 
into something which might, or might not work after a "make menuconfig".


>> If the build works for all other archs, then the cp will work.
> 
> Yes, I agree.  'cp' shouldn't be a problem in this context.  Still, if for
> some misterious reason it doesn't get built, '-cp' doesn't break the build
> making us aware of that and things break later in other places?  Trouble
> shooting that scenario will be more painful, IMO.
> 
>> You have not explained in what way you suffer.
> 
> Thanks, I got better after getting out the previous post ;)
> 
> I'll try to explain.  Every time I check out a new tree, it takes one or
> several days to get it to build.  And when I think I'm done (save some
> patches not yet accepted upstream), check out a new tree, apply my
> patches, I start seeing things breaking again in various ways and I have
> to start all over again.  And that's _very_ frustrating!
> 
> Happened again today :(
> 

Build a toolchain that works, then use an external toolchain.
Saves you a lot of time...


Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Cristian Ionescu-Idbohrn]

On Mon, 15 Oct 2007, Ulf Samuelsson wrote:

> Some people are against having architecture specific extensions in the
> common files.

Alright.  I see a point in that.  But I still think, as I said before:
"one size doesn't fit everybody".  If incompatibilities arise, one good
thing is to pin them down, and make them visible.  Is there another way?

> I believe it is better to continue the build, and then do a verify
> afterwards.

I don't.  Side effects can lead one on to treacherous side tracks and
troubleshooting would be more painful.

> If you read archives, a lot of people consider the libgcc_s to be a
> PITA.

But of course.  Anything that is not dead simple is PITA.

> The "-cp" -> "cp" patch has caused me several hundred hours
> of extra work,

Really?  I'm not arguing, but I find it difficult to believe.

> and this can all be blamed on Bernhard.
> Any problems caused by patches trying to fix the broken AVR32
> can therefore indirectly be blamed on Bernhard as well.

Cool down now.  I do believe that one of the reasons why this project is
not moving at faster pace is that the magic between you and Bernhard is
just not working.  And that's really sad.  That said, things won't get
better if the only noticable thing is you two disagreeing.

> In practice, I do *not* want to blame Bernhard for *that* patch, since
> it very difficult to do a full test of buildroot using all parameters.

True.

> However, Bernhard has a policy which is to always use the latest stuff,
> which makes IMHO Buildroot, nothing more than a (nice) toy.

I don't see very much wrong with that, as long as you keep things tight.
Branching was suggested more than once.  What do you say?  More work?
Yes.  More satisfied "customers"?  Oh, yes.  Me for one.  I would rather
use something that is controllable (mind you, not top of the notch) than
something that is constantly broken.

> You reported a build problem with JPEG and think that creating a
> directory in $(STAGING_DIR) during the jpeg build was the problem which
> caused the toolchain build to fail.

Your words, not mine.  I'm just an occasional visitor ;)

> You probably only need to reflect on this for a millisecond or so to
> realize how absurd that is...

I have to admit, I'm not that sharp ;)

> I rather think this is a result of Bernhards patch to deprecate older
> versions of Binutils, automatically changing an existing *working*
> ".config" into something which might, or might not work after a "make
> menuconfig".

There you go again.  Don't waste your time throwing dirt on one another!
Work together instead!  Learn from eachother.  Everyone will benefit.
Life is short and then you die, both of you and your "customers".

> Build a toolchain that works, then use an external toolchain.
> Saves you a lot of time...

Yes.  Any FAQ on that?
But still aspirine, workaround, substitute for the real thing :(
Thanks for the advice, anyway.

You two you kan keep disagreing in the back stage.  But don't do it up
front.  Work together instead.  It's much better for the "business".


Cheers,

-- 
Cristian

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Ulf Samuelsson]

>> I rather think this is a result of Bernhards patch to deprecate older
>> versions of Binutils, automatically changing an existing *working*
>> ".config" into something which might, or might not work after a "make
>> menuconfig".
>
> There you go again.  Don't waste your time throwing dirt on one another!
> Work together instead!  Learn from eachother.  Everyone will benefit.
> Life is short and then you die, both of you and your "customers".
>

It is not "throwing dirt", it is advice on where to look for your JPEG build 
problems.
I.E: Try an older version of binutils...

>> Build a toolchain that works, then use an external toolchain.
>> Saves you a lot of time...
>
> Yes.  Any FAQ on that?
> But still aspirine, workaround, substitute for the real thing :(

It takes 1-2 hours to build a toolchain.
It is not neccessary to repeat the process everytime you want to rebuild 
buildroot.
Look in the docs directory..

Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Bernhard Fischer]

On Mon, Oct 15, 2007 at 07:40:05PM +0200, Cristian Ionescu-Idbohrn wrote:

>> However, Bernhard has a policy which is to always use the latest stuff,
>> which makes IMHO Buildroot, nothing more than a (nice) toy.
>
>I don't see very much wrong with that, as long as you keep things tight.
>Branching was suggested more than once.  What do you say?  More work?
>Yes.  More satisfied "customers"?  Oh, yes.  Me for one.  I would rather
>use something that is controllable (mind you, not top of the notch) than
>something that is constantly broken.

Well top notch would be always pulling the upstream repos. I don't
remember to have done this even a single time in buildroot.
There is a subtile difference between these three:
- top notch
- current, stable release, usually containing the best-fit bugfixes
- outdated packages with known bugs (sometimes all over the place).

I'm sure there is endless discussion archived out there about the pros
and cons of each of them, so i'll spare my keyboard interrupts and your
time.

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Ulf Samuelsson]

link: www.avrfreaks.net
----- Original Message ----- 
From: "Bernhard Fischer" <rep.dot.nop@gmail.com>
To: <buildroot@uclibc.org>
Sent: Monday, October 15, 2007 8:55 PM
Subject: Re: [Buildroot] svn commit: trunk/buildroot/toolchain/gcc


> On Mon, Oct 15, 2007 at 07:40:05PM +0200, Cristian Ionescu-Idbohrn wrote:
>
>>> However, Bernhard has a policy which is to always use the latest stuff,
>>> which makes IMHO Buildroot, nothing more than a (nice) toy.
>>
>>I don't see very much wrong with that, as long as you keep things tight.
>>Branching was suggested more than once.  What do you say?  More work?
>>Yes.  More satisfied "customers"?  Oh, yes.  Me for one.  I would rather
>>use something that is controllable (mind you, not top of the notch) than
>>something that is constantly broken.
>
> Well top notch would be always pulling the upstream repos. I don't
> remember to have done this even a single time in buildroot.
> There is a subtile difference between these three:
> - top notch
> - current, stable release, usually containing the best-fit bugfixes
> - outdated packages with known bugs (sometimes all over the place).
>
> I'm sure there is endless discussion archived out there about the pros
> and cons of each of them, so i'll spare my keyboard interrupts and your
> time.


I think the most important thing is to allow the user of buildroot
to make his/her own decision on strategy.
It should be possible to use a specific version of a package
but also to use the latests experimental version for other packages
possbily with own developed patches. (which hopefully are submitted later)

For this to work, there is a need for a stable source tarball server
which can be used, if the main location disappears.

I rather see multiple makefile fragments, than multiple trunks.

instead of

include package/*/*.mk

we could have

include    project/.distribution        # Override release versions
include    package/*/*.mk



<package>.mk could contain
+++++++++++++++++++++
ifneq ($(<PACKAGE>_RELEASE),)
include    <package>/$(<PACKAGE>_RELEASE)/<package>.mk
else
include    <package>/$(RELEASE)/<package>.mk
endif
--------------------------------

or similar.

This would allow some people to keep an old release and others
to work on new stuff.

It may be a good idea to allow patches to be applied based on a list
instead its name.

Best Regards
Ulf Samuelsson?

[Buildroot] svn commit: trunk/buildroot/toolchain/gcc

[Bernhard Fischer]

On Sat, Oct 13, 2007 at 11:57:19AM +0200, Ulf Samuelsson wrote:
>l?r 2007-10-13 klockan 10:49 +0200 skrev Cristian Ionescu-Idbohrn:
>> On Fri, 12 Oct 2007, ulf at uclibc.org wrote:
>> 
>> > Author: ulf
>> > Date: 2007-10-12 14:01:41 -0700 (Fri, 12 Oct 2007)
>> > New Revision: 20237
>> >
>> > Log:
>> > Allow library copy to fail
>> 
>> As it's not obvious to me, may I ask why?
>> Why not making sure it doesn't fail, instead?
>
>That is the long term approach, but I have no control over that part.
>
>If copying fails, then libgcc.a is available,

No, that's wrong. See previous discussion in the archives.

>and the end application can be linked with this instead
>It is better than aborting the build.

In my little world wrong behaviour is not a proper fix for a bug. YMMV