From: Adam Hawes <adam@infocab.com.au>
To: buildroot@busybox.net
Subject: [Buildroot] Qtopia4 Failure
Date: Mon, 24 Sep 2007 11:46:25 +0930 [thread overview]
Message-ID: <1190600185.4299.44.camel@cyclops.infocab.com.au> (raw)
In-Reply-To: <d6cda7730709231841v7ce7eec2qa801e54b049763b7@mail.gmail.com>
> 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
next prev parent reply other threads:[~2007-09-24 2:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-23 16:12 [Buildroot] Qtopia4 Failure Ulf Samuelsson
2007-09-23 16:25 ` Thiago A. Corrêa
2007-09-23 23:55 ` Adam Hawes
2007-09-24 0:56 ` Thiago A. Corrêa
2007-09-24 1:06 ` Adam Hawes
2007-09-24 1:41 ` Thiago A. Corrêa
2007-09-24 2:16 ` Adam Hawes [this message]
2007-09-24 3:43 ` Thiago A. Corrêa
2007-09-24 3:55 ` Adam Hawes
2007-09-24 8:13 ` Bernhard Fischer
2007-09-24 12:59 ` Thiago A. Corrêa
2007-09-24 13:22 ` Bernhard Fischer
2007-09-24 15:13 ` Ulf Samuelsson
2007-09-24 15:34 ` Thiago A. Corrêa
2007-09-24 23:31 ` Adam Hawes
2007-09-25 0:09 ` [Buildroot] MPlayer using LEGACY Functions (was: Qtopia4 Failure) Adam Hawes
2007-09-25 7:27 ` [Buildroot] Qtopia4 Failure Bernhard Fischer
2007-09-24 8:12 ` Ulf Samuelsson
2007-09-24 9:12 ` Bernhard Fischer
2007-09-24 9:34 ` Ulf Samuelsson
2007-09-24 12:27 ` Bernhard Fischer
2007-09-24 14:25 ` Ulf Samuelsson
2007-09-24 14:51 ` Ulf Samuelsson
2007-09-24 18:41 ` Bernhard Fischer
2007-09-24 8:06 ` Ulf Samuelsson
2007-09-24 8:02 ` Ulf Samuelsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1190600185.4299.44.camel@cyclops.infocab.com.au \
--to=adam@infocab.com.au \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox