On Tuesday 07 April 2009 18:46:38 Yann E. MORIN wrote:
> The patch also removes setting the CFLAGS/LDFLAGS for endianness for the
> same reason, although the menuconfig entries are still there.
iirc, it is possible to build a toolchain that supports both big and little
endian simultaneously. i b
Hello All!
(patch attached, now)
Description:
As previously suggested, here is a patch that gets rid of the ARM variant
choice in the menuconfig.
The patch also removes setting the CFLAGS/LDFLAGS for endianness for the
same reason, although the menuconfig entries are still there.
Hello All!
Description:
As previously suggested, here is a patch that gets rid of the ARM variant
choice in the menuconfig.
The patch also removes setting the CFLAGS/LDFLAGS for endianness for the
same reason, although the menuconfig entries are still there.
This patch is just a pr
On Tuesday 07 April 2009 16:09:08 Yann E. MORIN wrote:
> On Tuesday 07 April 2009 21:14:36 Mike Frysinger wrote:
> > i dont think we should keep enabling lazy people. either the right
> > options are selected by gcc in their toolchain, or they should manually
> > add the -mcpu or whatever flags to
Hector,
All,
On Tuesday 07 April 2009 22:31:07 Hector Oron wrote:
> > I'm all for throwing away this mess as well. As new variants arrive, we'll
> > add more of this stuff. And when one will try to compile with a gcc that
-
> > is not
Hi Yann,
> I'm all for throwing away this mess as well. As new variants arrive, we'll
> add more of this stuff. And when one will try to compile with a gcc that
> is not recent enough, the -mcpu and -mtune options will not be recognised,
> and the build will break, and we'll be blamed for that.
I
Mike,
All,
On Tuesday 07 April 2009 21:14:36 Mike Frysinger wrote:
> On Tuesday 07 April 2009 14:29:06 Yann E. MORIN wrote:
> > Of course the processor variant we're building uClibc to run on matters!
> that's the decision of the compiler and/or user, not uClibc. building uClibc
> with a differe
On Tuesday 07 April 2009 06:48:07 Sagar Borikar wrote:
On Tue, Apr 7, 2009 at 12:58 PM, Sagar Borikar wrote:
> On Tue, Apr 7, 2009 at 12:25 PM, Mike Frysinger wrote:
>> On Tuesday 07 April 2009 01:26:33 Sagar Borikar wrote:
>>> Just wanted to check whether cortex A8 (ARM) is supported in uClibc?
>>
On Tuesday 07 April 2009 14:29:06 Yann E. MORIN wrote:
> On Tuesday 07 April 2009 08:55:25 Mike Frysinger wrote:
> > On Tuesday 07 April 2009 01:26:33 Sagar Borikar wrote:
> > > Just wanted to check whether cortex A8 (ARM) is supported in uClibc?
> >
> > uClibc doesnt care what ARM variant you're u
Hello all!
On Tuesday 07 April 2009 08:55:25 Mike Frysinger wrote:
> On Tuesday 07 April 2009 01:26:33 Sagar Borikar wrote:
> > Just wanted to check whether cortex A8 (ARM) is supported in uClibc?
>
> uClibc doesnt care what ARM variant you're using. it does have optional
> support for things l
Bernhard Reutner-Fischer wrote:
> On Thu, Apr 02, 2009 at 09:39:13AM +0200, Carmelo AMOROSO wrote:
>
>> Olivier Hochreutiner wrote:
>>> Hi there,
>>>
>>> I am facing a problem with the uClibc++ implementation of std::map,
>>> which can be illustrated with the following code:
>>>
>> uClibc++ is not
On Tue, Apr 07, 2009 at 04:18:07PM +0530, Sagar Borikar wrote:
>resending to the list
>
>Sagar
>On Tue, Apr 7, 2009 at 4:17 PM, Sagar Borikar wrote:
>> resending to list.
>>
>> Sagar
>>
>> On Tue, Apr 7, 2009 at 12:58 PM, Sagar Borikar
>> wrote:
>>> On Tue, Apr 7, 2009 at 12:25 PM, Mike Frysinge
resending to the list
Sagar
On Tue, Apr 7, 2009 at 4:17 PM, Sagar Borikar wrote:
> resending to list.
>
> Sagar
>
> On Tue, Apr 7, 2009 at 12:58 PM, Sagar Borikar
> wrote:
>> On Tue, Apr 7, 2009 at 12:25 PM, Mike Frysinger wrote:
>>> On Tuesday 07 April 2009 01:26:33 Sagar Borikar wrote:
On Sat, Mar 28, 2009 at 8:37 AM, Khem Raj wrote:
> On Friday 27 March 2009 08:58:07 Groleo Marius wrote:
>> I had some problems compiling and later, using shared libraries from
>> uClibc-0.9.30.1 on a Coldfire M5485 processor.
>>
>> The attached patches fixes the problems I've encountered:
>
> Wel
14 matches
Mail list logo