Should NBPG be unconditionally undefined to avoid references to PAGE_SIZE?

[Mike Frysinger]

On Friday 14 September 2007, Stephen M. Kenton wrote:
> Alan Modra wrote:
> > On Fri, Sep 14, 2007 at 09:55:13AM -0500, Stephen M. Kenton wrote:
> >> This is probably a better place to discuss this than bug-binutils. I am
> >> trying to make it easier for people to build cross-compile tool chains
> >> for all 20+ targets supported by the Linux kernel,
> >
> > All the world is not (yet) Linux.  Take a look at bfd/configure.  I
> > see linux, riscix, bsd, sysv, freebsd, sco, mach, osf, riscos, hpux,
> > ultrix and other unspecified operating systems using trad-core.c.
> > Have you considered how many of those targets you might break by
> > #undef NBPG?
>
> Yep, that's why I asked the question instead of submitting a
> quite-possibly-bogus patch.  However, if you look a couple of lines down
> from my putative undef of NBPG in trad-core.c  you will find.
>
> #ifndef NBPG
> # define NBPG getpagesize()
> #endif
>
> Maybe that should something to the effect of (if linux or not NBPG then
> define NBPG ), if getpagesize() is not portable enough. I don't know
> enough about "riscix, bsd, sysv, freebsd, sco, mach, osf, riscos,
> hpux,ultrix and other unspecified operating systems" to comment on
> them.  For this define to work, all the uses of NBPG have to be dynamic
> anyway so I assume the rest of the binutils code is OK with it.  Maybe
> there are target specific uses that require a constant?

the point of adding those lines was so that the headers in the Linux kernel 
and glibc could safely be transitioned.  the kernel headers are broken ... 
they should not be exporting asm/page.h.  unfortunately, i havent had time to 
finish posting patches to lkml to fix the situation.
-mike
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20070914/4c46bca1/attachment.sig>