[Buildroot] Qtopia4 Failure

[Buildroot] Qtopia4 Failure

[Ulf Samuelsson]

Anyone building qtopia?
I get (when compiling with gcc-4.2.1/binutils-2.18/uclibc-0.9.29):


arm-linux-g++ -c -pipe -g -g -fvisibility=hidden
-fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED
-DTSLIBMOUSEHANDLER_DEBUG -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
-I../../mkspecs/qws/linux-arm-g++ -I. -I../../include
-I../../include/QtCore -Iglobal -I.moc/debug-shared-emb-arm
-I.uic/debug-shared-emb-arm
-o .obj/debug-shared-emb-arm/qresource_iterator.o
io/qresource_iterator.cpp
io/qresource_iterator.cpp:46:66: error: macro "index" requires 2
arguments, but only 1 given
io/qresource_iterator.cpp: In constructor
?QResourceFileEngineIterator::QResourceFileEngineIterator(QFlags<QDir::Filter>, const QStringList&)?:
io/qresource_iterator.cpp:47: error: expected `(' before ?{? token
make[2]: *** [.obj/debug-shared-emb-arm/qresource_iterator.o] Fel 1


when compiling "src/corelib/io/qresource_iterator.cpp"
This is the line giving problems.

QResourceFileEngineIterator::QResourceFileEngineIterator(QDir::Filters
filters,
                                                         const
QStringList &filterNames)
    : QAbstractFileEngineIterator(filters, filterNames), index(-1)
{
}



Best Regards
Ulf Samuelsson

[Buildroot] Qtopia4 Failure

[Thiago A. Corrêa]

I built for AVR32. I even have some patches here that I'm not sure
were applied or not. I haven't updated the svn for a little while as I
have been working on the application lately.

It seams like the include path issue, if I'm not mistaken there is
some header (uClib I guess, not sure, and not Qt's) that does a
#define index

which is very bad :P

On 9/23/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> Anyone building qtopia?
> I get (when compiling with gcc-4.2.1/binutils-2.18/uclibc-0.9.29):
>
>
> arm-linux-g++ -c -pipe -g -g -fvisibility=hidden
> -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED
> -DTSLIBMOUSEHANDLER_DEBUG -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII
> -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
> -I../../mkspecs/qws/linux-arm-g++ -I. -I../../include
> -I../../include/QtCore -Iglobal -I.moc/debug-shared-emb-arm
> -I.uic/debug-shared-emb-arm
> -o .obj/debug-shared-emb-arm/qresource_iterator.o
> io/qresource_iterator.cpp
> io/qresource_iterator.cpp:46:66: error: macro "index" requires 2
> arguments, but only 1 given
> io/qresource_iterator.cpp: In constructor
> 'QResourceFileEngineIterator::QResourceFileEngineIterator(QFlags<QDir::Filter>, const QStringList&)':
> io/qresource_iterator.cpp:47: error: expected `(' before '{' token
> make[2]: *** [.obj/debug-shared-emb-arm/qresource_iterator.o] Fel 1
>
>
> when compiling "src/corelib/io/qresource_iterator.cpp"
> This is the line giving problems.
>
> QResourceFileEngineIterator::QResourceFileEngineIterator(QDir::Filters
> filters,
>                                                          const
> QStringList &filterNames)
>     : QAbstractFileEngineIterator(filters, filterNames), index(-1)
> {
> }
>
>
>
> Best Regards
> Ulf Samuelsson
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Qtopia4 Failure

[Adam Hawes]

On Sun, 2007-09-23 at 18:12 +0200, Ulf Samuelsson wrote:
> Anyone building qtopia?
> I get (when compiling with gcc-4.2.1/binutils-2.18/uclibc-0.9.29):
> 
> 
> arm-linux-g++ -c -pipe -g -g -fvisibility=hidden
> -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED
> -DTSLIBMOUSEHANDLER_DEBUG -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII
> -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
> -I../../mkspecs/qws/linux-arm-g++ -I. -I../../include
> -I../../include/QtCore -Iglobal -I.moc/debug-shared-emb-arm
> -I.uic/debug-shared-emb-arm
> -o .obj/debug-shared-emb-arm/qresource_iterator.o
> io/qresource_iterator.cpp
> io/qresource_iterator.cpp:46:66: error: macro "index" requires 2
> arguments, but only 1 given
> io/qresource_iterator.cpp: In constructor
> ?QResourceFileEngineIterator::QResourceFileEngineIterator(QFlags<QDir::Filter>, const QStringList&)?:
> io/qresource_iterator.cpp:47: error: expected `(' before ?{? token
> make[2]: *** [.obj/debug-shared-emb-arm/qresource_iterator.o] Fel 1
> 

Yup.  To quote Carmelo Amoroso (search the archives in the last month):

"The problem is that you have uClibc configure with SUSv3_LEGACY_MACRO
on that define index."

I have attached a patch that fixes the problem in all the places that
needs to be fixed (#undef index).  I need SUSv3 macros to build some
other things so I didn't want to turn them off and fix other things.

Cheers,
A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: qtopia-4.3.1-buildroot_index.patch
Type: text/x-patch
Size: 7903 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070924/7e45ba53/attachment.bin 

[Buildroot] Qtopia4 Failure

[Thiago A. Corrêa]

shouldn't you patch uClib instead? Claiming index with a define is
really stupid on the part of the library. Others, including myself use
index as variable names quite often.

On 9/24/07, Adam Hawes <adam@infocab.com.au> wrote:
> On Sun, 2007-09-23 at 18:12 +0200, Ulf Samuelsson wrote:
> > Anyone building qtopia?
> > I get (when compiling with gcc-4.2.1/binutils-2.18/uclibc-0.9.29):
> >
> >
> > arm-linux-g++ -c -pipe -g -g -fvisibility=hidden
> > -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED
> > -DTSLIBMOUSEHANDLER_DEBUG -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII
> > -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
> > -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
> > -I../../mkspecs/qws/linux-arm-g++ -I. -I../../include
> > -I../../include/QtCore -Iglobal -I.moc/debug-shared-emb-arm
> > -I.uic/debug-shared-emb-arm
> > -o .obj/debug-shared-emb-arm/qresource_iterator.o
> > io/qresource_iterator.cpp
> > io/qresource_iterator.cpp:46:66: error: macro "index" requires 2
> > arguments, but only 1 given
> > io/qresource_iterator.cpp: In constructor
> > 'QResourceFileEngineIterator::QResourceFileEngineIterator(QFlags<QDir::Filter>, const QStringList&)':
> > io/qresource_iterator.cpp:47: error: expected `(' before '{' token
> > make[2]: *** [.obj/debug-shared-emb-arm/qresource_iterator.o] Fel 1
> >
>
> Yup.  To quote Carmelo Amoroso (search the archives in the last month):
>
> "The problem is that you have uClibc configure with SUSv3_LEGACY_MACRO
> on that define index."
>
> I have attached a patch that fixes the problem in all the places that
> needs to be fixed (#undef index).  I need SUSv3 macros to build some
> other things so I didn't want to turn them off and fix other things.
>
> Cheers,
> A
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
>

[Buildroot] Qtopia4 Failure

[Adam Hawes]

On Mon, 2007-09-24 at 01:56 +0100, Thiago A. Corr?a wrote:
> shouldn't you patch uClib instead? Claiming index with a define is
> really stupid on the part of the library. Others, including myself use
> index as variable names quite often.

Do you use index()?  The macro accepts 2 arguments and the pre-processor
only seems to baulk when you use a function or method called index(...).
Variable names appear unproblematic.

Fixing uClibc would be the sensible thing to do, and uClibc actually has
a configuration option to turn off the legacy macros.  Turning them off,
however, breaks compatibility with a few things (mplayer was the most
recent one I found that wouldn't build with SUSv3 macros disabled).

I found it easier to patch Qtopia because it was the only thing that
didn't like the macros that I have found thus far.

So please keep in mind that there is not one universal solution - there
are a few options depending on the needs.  My patch fixes Qtopia for
those people who need the SUSv3 legacy macros in other places.  For
everyone else there's the configuration option of the library!

Regards,
A

[Buildroot] Qtopia4 Failure

[Thiago A. Corrêa]

Sure. There are all sort of valid code that a define breaks:

class MyClass
{
    MyClass() : index( 0 )
    {}
};

class MyOtherClass
{
    int index() const { return 0; }
}


A define claims the name index as if it were a keyword. It is a well
known issue.

How about change it to a function that wrapps the strchr()?
According to this:
http://www.opengroup.org/onlinepubs/000095399/functions/index.html
it used to be a function anyway.

At least it would give the compiler a chance to figure out by the scope.

One other good solution would be to patch mplayer not to use this define.


On 9/24/07, Adam Hawes <adam@infocab.com.au> wrote:
> On Mon, 2007-09-24 at 01:56 +0100, Thiago A. Corr?a wrote:
> > shouldn't you patch uClib instead? Claiming index with a define is
> > really stupid on the part of the library. Others, including myself use
> > index as variable names quite often.
>
> Do you use index()?  The macro accepts 2 arguments and the pre-processor
> only seems to baulk when you use a function or method called index(...).
> Variable names appear unproblematic.
>
> Fixing uClibc would be the sensible thing to do, and uClibc actually has
> a configuration option to turn off the legacy macros.  Turning them off,
> however, breaks compatibility with a few things (mplayer was the most
> recent one I found that wouldn't build with SUSv3 macros disabled).
>
> I found it easier to patch Qtopia because it was the only thing that
> didn't like the macros that I have found thus far.
>
> So please keep in mind that there is not one universal solution - there
> are a few options depending on the needs.  My patch fixes Qtopia for
> those people who need the SUSv3 legacy macros in other places.  For
> everyone else there's the configuration option of the library!
>
> Regards,
> A
>
>
>

[Buildroot] Qtopia4 Failure

[Adam Hawes]

> A define claims the name index as if it were a keyword. It is a well
> known issue.

Yes, I am well aware of that.

> How about change it to a function that wrapps the strchr()?
> According to this:
> http://www.opengroup.org/onlinepubs/000095399/functions/index.html
> it used to be a function anyway.

It's LEGACY.  To quote the open Group page you linked:

"For maximum portability, it is recommended to replace the function call
to index() as follows:

#define index(a,b) strchr((a),(b))"

The recommendation is to #define index when you need it in legacy code
because it no longer exists in the standard library.  uClibc does this
globally with a configuration option.

> One other good solution would be to patch mplayer not to use this define.

A good solution: yes.

The only solution: no.  There is all sorts of other code that still uses
legacy function calls.  It's not ideal but it's the way it is.  See my
quote below.  

Quoting me:
> > Fixing uClibc would be the sensible thing to do, and uClibc actually has
> > a configuration option to turn off the legacy macros.  Turning them off,
> > however, breaks compatibility with a few things (mplayer was the most
> > recent one I found that wouldn't build with SUSv3 macros disabled).

It is already possible to remove the macros from uClibc by turning off
SUSv3_LEGACY_MACROS in the configuration file before you build it.  You
don't need to patch uClibc.   Removing the macros may break more than
just mplayer though.

Regards,
Adam

[Buildroot] Qtopia4 Failure

[Thiago A. Corrêa]

Adam,

   You are fixing newer, valid and good code in the name of legacy
compatibility with a flawed work around for legacy API. The simple
fact that there are more than one way around it doesn't make the patch
the better way. And I think we should strive for the better way to fix
things ;)

   Instead, I propose talk to the uclib guys (they are hopefully here,
if not, will join the uclib mailling list) to implement the legacy
support in a proper way.
   The OpenGroup is only recomending to use a macro. The only reason
for it is to avoid a function call, which might even be optimized out
by the compiler. The code that was implemented with the index() in
mind, expected it to be a function anyway, not a macro.

something like:
#ifdef SUSv3_LEGACY_MACROS
char * index (const char *string, int c)
{  return strchr( string, c ); }
#endif

I'm not proposing to drop the workaround, but keeping the macro does
break code as we are well aware. The above has no drawbacks that I can
think of, and beats patching good code ;)

Friendly Regards

On 9/24/07, Adam Hawes <adam@infocab.com.au> wrote:
> > A define claims the name index as if it were a keyword. It is a well
> > known issue.
>
> Yes, I am well aware of that.
>
> > How about change it to a function that wrapps the strchr()?
> > According to this:
> > http://www.opengroup.org/onlinepubs/000095399/functions/index.html
> > it used to be a function anyway.
>
> It's LEGACY.  To quote the open Group page you linked:
>
> "For maximum portability, it is recommended to replace the function call
> to index() as follows:
>
> #define index(a,b) strchr((a),(b))"
>
> The recommendation is to #define index when you need it in legacy code
> because it no longer exists in the standard library.  uClibc does this
> globally with a configuration option.
>
> > One other good solution would be to patch mplayer not to use this define.
>
> A good solution: yes.
>
> The only solution: no.  There is all sorts of other code that still uses
> legacy function calls.  It's not ideal but it's the way it is.  See my
> quote below.
>
> Quoting me:
> > > Fixing uClibc would be the sensible thing to do, and uClibc actually has
> > > a configuration option to turn off the legacy macros.  Turning them off,
> > > however, breaks compatibility with a few things (mplayer was the most
> > > recent one I found that wouldn't build with SUSv3 macros disabled).
>
> It is already possible to remove the macros from uClibc by turning off
> SUSv3_LEGACY_MACROS in the configuration file before you build it.  You
> don't need to patch uClibc.   Removing the macros may break more than
> just mplayer though.
>
> Regards,
> Adam
>
>
>

[Buildroot] Qtopia4 Failure

[Adam Hawes]

>    You are fixing newer, valid and good code in the name of legacy
> compatibility with a flawed work around for legacy API. The simple
> fact that there are more than one way around it doesn't make the patch
> the better way. And I think we should strive for the better way to fix
> things ;)

"Better" is such a subjective word.  Who defines what is better in their
particular instance?

> I'm not proposing to drop the workaround, but keeping the macro does
> break code as we are well aware. The above has no drawbacks that I can
> think of, and beats patching good code ;)

I agree that improving the legacy code which relies on index() is the
way to go, but there is a lot of it.  I don't have the time to patch
everything I come across.

At the moment the best solution for me and probably others is to fix the
one thing that doesn't work (qtopia) and move on, improving other things
as I get around to them.

A

[Buildroot] Qtopia4 Failure

[Bernhard Fischer]

On Mon, Sep 24, 2007 at 01:25:13PM +0930, Adam Hawes wrote:
>
>>    You are fixing newer, valid and good code in the name of legacy
>> compatibility with a flawed work around for legacy API. The simple
>> fact that there are more than one way around it doesn't make the patch
>> the better way. And I think we should strive for the better way to fix
>> things ;)
>
>"Better" is such a subjective word.  Who defines what is better in their
>particular instance?

The current impl in uClibc is fine. You're broken if you rely on those
legacy stuff anyway, just turn it off to safe you some headache.

[Buildroot] Qtopia4 Failure

[Thiago A. Corrêa]

Bernhard,

   The implementation doesn't seam fine. Is there any good reason not
to wrap strchr in a function instead of a macro? It can be stripped
off by the SUS3 switch just as easily.

   According to Adam, this is required by mplayer (yeah, they are
broken, shame on them). I don't see why mplayer and qtopia and
possibly other packages should be mutually exclusive. Unless one
builds uClib twice.

On 9/24/07, Bernhard Fischer <rep.dot.nop@gmail.com> wrote:
> On Mon, Sep 24, 2007 at 01:25:13PM +0930, Adam Hawes wrote:
> >
> >>    You are fixing newer, valid and good code in the name of legacy
> >> compatibility with a flawed work around for legacy API. The simple
> >> fact that there are more than one way around it doesn't make the patch
> >> the better way. And I think we should strive for the better way to fix
> >> things ;)
> >
> >"Better" is such a subjective word.  Who defines what is better in their
> >particular instance?
>
> The current impl in uClibc is fine. You're broken if you rely on those
> legacy stuff anyway, just turn it off to safe you some headache.
>

[Buildroot] Qtopia4 Failure

[Bernhard Fischer]

On Mon, Sep 24, 2007 at 01:59:32PM +0100, Thiago A. Corr?a wrote:
>Bernhard,
>
>   The implementation doesn't seam fine. Is there any good reason not
>to wrap strchr in a function instead of a macro? It can be stripped

I don't understand this.

>off by the SUS3 switch just as easily.

$ grep LEGACY toolchain/uClibc/uClibc-0.9.29.config 
# UCLIBC_SUSV3_LEGACY is not set
# UCLIBC_SUSV3_LEGACY_MACROS is not set

>   According to Adam, this is required by mplayer (yeah, they are
>broken, shame on them). I don't see why mplayer and qtopia and
>possibly other packages should be mutually exclusive. Unless one

There is no issue for me. I don't have these LEGACY functions, nor the
macros. Packages that have bugs (i.e. use DEPRECATED or LEGACY as in the
SUSv3 ) should be fixed. IIRC, 'index' is not a reserved name and can be
used applications, be they written in C or C++.

For reserved keywords, let me refer you to the spec of your favourite
language, SUSv, POSIX and those IEEE specs that are relevant for your
system.

[Buildroot] Qtopia4 Failure

[Ulf Samuelsson]

m?n 2007-09-24 klockan 15:22 +0200 skrev Bernhard Fischer:
> On Mon, Sep 24, 2007 at 01:59:32PM +0100, Thiago A. Corr?a wrote:
> >Bernhard,
> >
> >   The implementation doesn't seam fine. Is there any good reason not
> >to wrap strchr in a function instead of a macro? It can be stripped
> 
> I don't understand this.
> 
> >off by the SUS3 switch just as easily.
> 
> $ grep LEGACY toolchain/uClibc/uClibc-0.9.29.config 
> # UCLIBC_SUSV3_LEGACY is not set
> # UCLIBC_SUSV3_LEGACY_MACROS is not set
> 
> >   According to Adam, this is required by mplayer (yeah, they are
> >broken, shame on them). I don't see why mplayer and qtopia and
> >possibly other packages should be mutually exclusive. Unless one
> 
> There is no issue for me. I don't have these LEGACY functions, nor the
> macros. Packages that have bugs (i.e. use DEPRECATED or LEGACY as in the
> SUSv3 ) should be fixed. IIRC, 'index' is not a reserved name and can be
> used applications, be they written in C or C++.

Maybe it is a good idea to fix things in a controlled manner.
Have you tested your patch against anything, to see what
it actually breaks, was it just a whim?

Why not turn off everything in uclibc.config as well?

> For reserved keywords, let me refer you to the spec of your favourite
> language, SUSv, POSIX and those IEEE specs that are relevant for your
> system.
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Qtopia4 Failure

[Thiago A. Corrêa]

On 9/24/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>
> Maybe it is a good idea to fix things in a controlled manner.
> Have you tested your patch against anything, to see what
> it actually breaks, was it just a whim?

Ulf, do you mean my proposed change? Not really. Right now I was
trying to grep for mplayer sources to find the index or rindex, but
could only find it in win32 code. Next step would be to try to
reproduce Adam's build of mplayer.

I can give it a shot in uClib, surely would make it more robust. But
Bernard is right that using that API is just plain wrong, so if I can
find it in mplayer, I'm reporting or sending a patch their way.

> Why not turn off everything in uclibc.config as well?

I was considering toying with buildbot to do automated build tests of
buildroot. But then I realised that I have screwed my system more than
once installing uClib into the /lib rather than the target folder
*smile*.

Regards,
   Thiago A. Correa

[Buildroot] Qtopia4 Failure

[Adam Hawes]

> >   According to Adam, this is required by mplayer (yeah, they are
> >broken, shame on them). I don't see why mplayer and qtopia and
> >possibly other packages should be mutually exclusive. Unless one\

I spent some time last night looking into mplayer.  It seems that it's
only broken in one place.  I made a quick hack to fix it (#define
index(a,b) ... in the file that was broken and tried compiling it
against a uClibc without the legacy macros.  It builds and runs fine on
my target.

I will submit a patch later to BR and MPlayer.

I haven't gone any further finding other packages that are broken - i
only built mplayer last night.

Regards,
A

[Buildroot] MPlayer using LEGACY Functions (was: Qtopia4 Failure)

[Adam Hawes]

> I will submit a patch later to BR and MPlayer.

After searching the archives it seems someone else already patched the
same place and submitted it nearly a year ago.

http://article.gmane.org/gmane.comp.video.mplayer.devel/39313/match=stream%5fdvb+c

It appeared in the mplayer svn at 21480 (dec, 06).  RC1 was released at
Oct 06.

Thus far with the patch in the link I have no trouble - mplayer and
qtopia both build without SUSV3 stuff.  Now to find out if the rest
builds as well.

A

[Buildroot] Qtopia4 Failure

[Bernhard Fischer]

On Tue, Sep 25, 2007 at 09:01:04AM +0930, Adam Hawes wrote:
>
>> >   According to Adam, this is required by mplayer (yeah, they are
>> >broken, shame on them). I don't see why mplayer and qtopia and
>> >possibly other packages should be mutually exclusive. Unless one\
>
>I spent some time last night looking into mplayer.  It seems that it's
>only broken in one place.  I made a quick hack to fix it (#define
>index(a,b) ... in the file that was broken and tried compiling it

Let me note that defining it is not a real fix as opposed to using the
appropriate modern variant. An example of all those replacements that is
very easy to read is against gcc's libmudflap (which is in the buildroot
repository).

HTH,

[Buildroot] Qtopia4 Failure

[Ulf Samuelsson]

m?n 2007-09-24 klockan 04:43 +0100 skrev Thiago A. Corr?a:
> Adam,
> 
>    You are fixing newer, valid and good code in the name of legacy
> compatibility with a flawed work around for legacy API. The simple
> fact that there are more than one way around it doesn't make the patch
> the better way. And I think we should strive for the better way to fix
> things ;)
> 
>    Instead, I propose talk to the uclib guys (they are hopefully here,
> if not, will join the uclib mailling list) to implement the legacy
> support in a proper way.
>    The OpenGroup is only recomending to use a macro. The only reason
> for it is to avoid a function call, which might even be optimized out
> by the compiler. The code that was implemented with the index() in
> mind, expected it to be a function anyway, not a macro.
> 
> something like:
> #ifdef SUSv3_LEGACY_MACROS
> char * index (const char *string, int c)
> {  return strchr( string, c ); }
> #endif

#undef UCLIBC_SUSV3_LEGACY_MACROS
#define UCLIBC_SUSV3_LEGACY

alredy does this.

I will submit a patch that allows UCLIBC_SUSV3_LEGACY
to be SED'ed into the uclibc configuration based on
BR2_UCLIBC_SUSV3_LEGACY (a new makeconfig choice).


> I'm not proposing to drop the workaround, but keeping the macro does
> break code as we are well aware. The above has no drawbacks that I can
> think of, and beats patching good code ;)
> 
> Friendly Regards
> 
> On 9/24/07, Adam Hawes <adam@infocab.com.au> wrote:
> > > A define claims the name index as if it were a keyword. It is a well
> > > known issue.
> >
> > Yes, I am well aware of that.
> >
> > > How about change it to a function that wrapps the strchr()?
> > > According to this:
> > > http://www.opengroup.org/onlinepubs/000095399/functions/index.html
> > > it used to be a function anyway.
> >
> > It's LEGACY.  To quote the open Group page you linked:
> >
> > "For maximum portability, it is recommended to replace the function call
> > to index() as follows:
> >
> > #define index(a,b) strchr((a),(b))"
> >
> > The recommendation is to #define index when you need it in legacy code
> > because it no longer exists in the standard library.  uClibc does this
> > globally with a configuration option.
> >
> > > One other good solution would be to patch mplayer not to use this define.
> >
> > A good solution: yes.
> >
> > The only solution: no.  There is all sorts of other code that still uses
> > legacy function calls.  It's not ideal but it's the way it is.  See my
> > quote below.
> >
> > Quoting me:
> > > > Fixing uClibc would be the sensible thing to do, and uClibc actually has
> > > > a configuration option to turn off the legacy macros.  Turning them off,
> > > > however, breaks compatibility with a few things (mplayer was the most
> > > > recent one I found that wouldn't build with SUSv3 macros disabled).
> >
> > It is already possible to remove the macros from uClibc by turning off
> > SUSv3_LEGACY_MACROS in the configuration file before you build it.  You
> > don't need to patch uClibc.   Removing the macros may break more than
> > just mplayer though.
> >
> > Regards,
> > Adam
> >
> >
> >
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Qtopia4 Failure

[Bernhard Fischer]

On Mon, Sep 24, 2007 at 10:12:10AM +0200, Ulf Samuelsson wrote:

>I will submit a patch that allows UCLIBC_SUSV3_LEGACY
>to be SED'ed into the uclibc configuration based on
>BR2_UCLIBC_SUSV3_LEGACY (a new makeconfig choice).

Please don't. This is way too fine-grained.
That's exactly the reason why we have
$ make uclibc-menuconfig

This is easy enough.

[Buildroot] Qtopia4 Failure

[Ulf Samuelsson]

> On Mon, Sep 24, 2007 at 10:12:10AM +0200, Ulf Samuelsson wrote:
> 
>>I will submit a patch that allows UCLIBC_SUSV3_LEGACY
>>to be SED'ed into the uclibc configuration based on
>>BR2_UCLIBC_SUSV3_LEGACY (a new makeconfig choice).
> 
> Please don't. This is way too fine-grained.
> That's exactly the reason why we have
> $ make uclibc-menuconfig
> 
> This is easy enough.
>

I can do that, but then I have to enable UCLIBC_SUSV3_LEGACY as default
and not the UCLIBC_SUSV3_LEGACY_MACROS as it is today.

The current situation is not acceptable.
There needs to be either a dependency on UCLIBC_SUSV3_LEGACY
when enabling Qtopia, (and I do not see how that can be accomplished)
or the default operation should allow Qtopia to build without problems.

Best Regards
Ulf Samuelsson

[Buildroot] Qtopia4 Failure

[Bernhard Fischer]

On Mon, Sep 24, 2007 at 11:34:02AM +0200, Ulf Samuelsson wrote:
>> On Mon, Sep 24, 2007 at 10:12:10AM +0200, Ulf Samuelsson wrote:
>> 
>>>I will submit a patch that allows UCLIBC_SUSV3_LEGACY
>>>to be SED'ed into the uclibc configuration based on
>>>BR2_UCLIBC_SUSV3_LEGACY (a new makeconfig choice).
>> 
>> Please don't. This is way too fine-grained.
>> That's exactly the reason why we have
>> $ make uclibc-menuconfig
>> 
>> This is easy enough.
>>
>
>I can do that, but then I have to enable UCLIBC_SUSV3_LEGACY as default
>and not the UCLIBC_SUSV3_LEGACY_MACROS as it is today.

This is a *sample* config. You are supposed to configure this yourself.

This sample config is definately *not* ment to be used without
configuring it according to your special needs. If you want a libc
that's easy to use (because it is not configurable), then go use glibc.

>
>The current situation is not acceptable.

It is unacceptable to shield the user from any configuration, especially
if he did change the default config anyway (since he selected qtopia
which was not on per default, last time i looked).

>There needs to be either a dependency on UCLIBC_SUSV3_LEGACY
>when enabling Qtopia, (and I do not see how that can be accomplished)
>or the default operation should allow Qtopia to build without problems.

Whatever. I disabled the LEGACY stuff in the provided *example* config.
Still, the user is responsible for configuring his desired buildroot
config as well as his desired uClibc-, busybox- and kernel config.

If a user is not willing to configure for his needs, he'd be better off
to either use the default, without changing anything (which will result
in a very minimal i386 uClibc rootfs) or use some pre-built distro like
redhat, suse, debian etc are providing.

[Buildroot] Qtopia4 Failure

[Ulf Samuelsson]

m?n 2007-09-24 klockan 14:27 +0200 skrev Bernhard Fischer:
> On Mon, Sep 24, 2007 at 11:34:02AM +0200, Ulf Samuelsson wrote:
> >> On Mon, Sep 24, 2007 at 10:12:10AM +0200, Ulf Samuelsson wrote:
> >> 
> >>>I will submit a patch that allows UCLIBC_SUSV3_LEGACY
> >>>to be SED'ed into the uclibc configuration based on
> >>>BR2_UCLIBC_SUSV3_LEGACY (a new makeconfig choice).
> >> 
> >> Please don't. This is way too fine-grained.
> >> That's exactly the reason why we have
> >> $ make uclibc-menuconfig
> >> 
> >> This is easy enough.
> >>
> >
> >I can do that, but then I have to enable UCLIBC_SUSV3_LEGACY as default
> >and not the UCLIBC_SUSV3_LEGACY_MACROS as it is today.
> 
> This is a *sample* config. You are supposed to configure this yourself.
> 

If you know how...
It is not documented anywhere that SUSV3 affects Qtopia.

> This sample config is definately *not* ment to be used without
> configuring it according to your special needs. If you want a libc
> that's easy to use (because it is not configurable), then go use glibc.

> >
> >The current situation is not acceptable.
> 
> It is unacceptable to shield the user from any configuration, especially
> if he did change the default config anyway (since he selected qtopia
> which was not on per default, last time i looked).

Certain packages requires that the library is configured in a certain
way. You want people to find out for themselves what works and what
does not work. This is a timeconsuiming and frustrating exercise.

I am of the opinion, that if someone has figured out how to build
those packages, this needs to formalized by introducing rules in
buildroot, to avoid people wasting time in the future.


> >There needs to be either a dependency on UCLIBC_SUSV3_LEGACY
> >when enabling Qtopia, (and I do not see how that can be accomplished)
> >or the default operation should allow Qtopia to build without problems.
> 
> Whatever. I disabled the LEGACY stuff in the provided *example* config.
> Still, the user is responsible for configuring his desired buildroot
> config as well as his desired uClibc-, busybox- and kernel config.
> 
> If a user is not willing to configure for his needs, he'd be better off
> to either use the default, without changing anything (which will result
> in a very minimal i386 uClibc rootfs) or use some pre-built distro like
> redhat, suse, debian etc are providing.

You live in an x86 universe, a lot of other people (like me) are not.


BR
Ulf Samuelsson

[Buildroot] Qtopia4 Failure

[Ulf Samuelsson]

> >The current situation is not acceptable.
> 
> It is unacceptable to shield the user from any configuration, especially
> if he did change the default config anyway (since he selected qtopia
> which was not on per default, last time i looked).
> 

If I would take you on youre word, then I would remove all
"depends on" lines in Config.in files.
This definitely shields the user from configurations.


BR
Ulf Samuelsson

[Buildroot] Qtopia4 Failure

[Bernhard Fischer]

On Mon, Sep 24, 2007 at 04:51:13PM +0200, Ulf Samuelsson wrote:
>
>> >The current situation is not acceptable.
>> 
>> It is unacceptable to shield the user from any configuration, especially
>> if he did change the default config anyway (since he selected qtopia
>> which was not on per default, last time i looked).
>> 
>
>If I would take you on youre word, then I would remove all
>"depends on" lines in Config.in files.
>This definitely shields the user from configurations.

The select is much worse, imho. oh well.

[Buildroot] Qtopia4 Failure

[Ulf Samuelsson]

m?n 2007-09-24 klockan 10:36 +0930 skrev Adam Hawes:
> On Mon, 2007-09-24 at 01:56 +0100, Thiago A. Corr?a wrote:
> > shouldn't you patch uClib instead? Claiming index with a define is
> > really stupid on the part of the library. Others, including myself use
> > index as variable names quite often.
> 
> Do you use index()?  The macro accepts 2 arguments and the pre-processor
> only seems to baulk when you use a function or method called index(...).
> Variable names appear unproblematic.
> 
> Fixing uClibc would be the sensible thing to do, and uClibc actually has
> a configuration option to turn off the legacy macros.  Turning them off,
> however, breaks compatibility with a few things (mplayer was the most
> recent one I found that wouldn't build with SUSv3 macros disabled).
> 

Did you try with UCLIBC_SUSV3_LEGACY enabled?

> I found it easier to patch Qtopia because it was the only thing that
> didn't like the macros that I have found thus far.
> 
> So please keep in mind that there is not one universal solution - there
> are a few options depending on the needs.  My patch fixes Qtopia for
> those people who need the SUSv3 legacy macros in other places.  For
> everyone else there's the configuration option of the library!
> 
> Regards,
> A
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Qtopia4 Failure

[Ulf Samuelsson]

m?n 2007-09-24 klockan 09:25 +0930 skrev Adam Hawes:
> On Sun, 2007-09-23 at 18:12 +0200, Ulf Samuelsson wrote:
> > Anyone building qtopia?
> > I get (when compiling with gcc-4.2.1/binutils-2.18/uclibc-0.9.29):
> > 
> > 
> > arm-linux-g++ -c -pipe -g -g -fvisibility=hidden
> > -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED
> > -DTSLIBMOUSEHANDLER_DEBUG -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII
> > -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT
> > -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
> > -I../../mkspecs/qws/linux-arm-g++ -I. -I../../include
> > -I../../include/QtCore -Iglobal -I.moc/debug-shared-emb-arm
> > -I.uic/debug-shared-emb-arm
> > -o .obj/debug-shared-emb-arm/qresource_iterator.o
> > io/qresource_iterator.cpp
> > io/qresource_iterator.cpp:46:66: error: macro "index" requires 2
> > arguments, but only 1 given
> > io/qresource_iterator.cpp: In constructor
> > ?QResourceFileEngineIterator::QResourceFileEngineIterator(QFlags<QDir::Filter>, const QStringList&)?:
> > io/qresource_iterator.cpp:47: error: expected `(' before ?{? token
> > make[2]: *** [.obj/debug-shared-emb-arm/qresource_iterator.o] Fel 1
> > 
> 
> Yup.  To quote Carmelo Amoroso (search the archives in the last month):
> 
> "The problem is that you have uClibc configure with SUSv3_LEGACY_MACRO
> on that define index."

I have tried another alternative, and that is to enable
UCLIBC_SUSV3_LEGACY instead of UCLIBC_SUSV3_LEGACY_MACROS
Then the Macros do not get defined, and you instead gets the 
real bcopy/bzero etc. routines.

With this, qtopia-4.3.1 compiles.

qtopia will depend on UCLIBC_SUSV3_LEGACY.

> 
> I have attached a patch that fixes the problem in all the places that
> needs to be fixed (#undef index).  I need SUSv3 macros to build some
> other things so I didn't want to turn them off and fix other things.
> 
> Cheers,
> A
>