RFC: drop __GLIBC__ on gcc/kbsd
Hi,
(please CC me on replies, since I'm not subscribed to -bsd@.)
years ago, when Robert Millan improved the support for k*bsd* in gcc, he
added the __GLIBC__ define as part of the ones provided by gcc itself
(see [1][2]).
Unfortunately, __GLIBC__ is one of the defines provided by glibc itself
(in the internal features.h included in any public header), and
because of this (e)glibc on debian/kfreebsd has to carry the patch
local-undef-glibc.diff. Indeed, compiling trying to compile the simple:
#ifdef __GLIBC__
# error __GLIBC__ defined with no includes!
#endif
int main() { return 0; }
fails on kFreeBSD while it succeeds on Linux and Hurd.
This also causes that porting code like:
-#if defined(__linux__)
+#if defined(__linux__) || defined(__GLIBC__)
makes it work on kFreeBSD but still failing on Hurd (in situation where
there is no #include of stdlib headers prior to that), and in the past
I've been personally hit by this few times (and I'm not the only Hurd
porter to have hit such situation).
Since IMHO it is awkward for a compiler to claim to be a libc, my
suggestion (as also shown in the topic) is to drop the definition of
__GLIBC__ done in the k*bsd* configuration of gcc.
My proposal would be to remove it upstream and, once Whezy is released,
backport the patch for any gcc version in Debian. This should leave
plenty of time (at least 1-1½ years) to fix the (few?) kFreeBSD-specific
build failures and issues that could arise because of that (note that
some of the cases were fixed in the past with Hurd porting).
What do you think? Does it sound reasonable enough?
[1] http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00050.html
[2] http://gcc.gnu.org/viewcvs?view=revisionrevision=83577
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
python3.3 build failure on kfreebsd and the hurd
python3.3 build failure on kfreebsd and the hurd, please could somebody have a look and propose a patch? thanks, Matthias -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50996763.3090...@debian.org
Re: python3.3 build failure on kfreebsd and the hurd
Hi, Alle martedì 6 novembre 2012, Matthias Klose ha scritto: python3.3 build failure on kfreebsd and the hurd, please could somebody have a look and propose a patch? This was reported upstream months ago: http://bugs.python.org/issue13669 I just left a comment with a possible solution (although no patch for now). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: python3.3 build failure on kfreebsd and the hurd
Hi, I'd say the test at Modules/posixmodule.c:114 is wrong: #if defined(HAVE_SYS_XATTR_H) defined(__GLIBC__) #define USE_XATTRS #endif Because GLIBC doesn't imply a working xattr interface (traditionally a Linux thing?). There seem to be implementations only for Linux, GNU/Hurd and as part of NetBSD Linux compatibility layer. On GNU/kFreeBSD there is only a stub for setxattr, returning -ENOSYS (not implemented). Hence there is no XATTR_SIZE_MAX defined either. For now, maybe it would be better as: #if defined(HAVE_SYS_XATTR_H) (defined(__linux__) || defined(__GNU__)) The other problem is that GNU/Hurd doesn't enforce a maximum size and so still doesn't define XATTR_SIZE_MAX; on NetBSD they define it like this for compatibility it seems: http://fxr.watson.org/fxr/source/sys/xattr.h?v=NETBSD5#L52 #define XATTR_SIZE_MAX 65536 /* NetBSD does not enforce this */ So, GNU/Hurd could maybe add something like that if it helps with porting; or better still, upstream could do as Pino suggested in http://bugs.python.org/issue13669 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50997244.60...@pyro.eu.org
Re: python3.3 build failure on kfreebsd and the hurd
Hi, Alle martedì 6 novembre 2012, Steven Chamberlain ha scritto: I'd say the test at Modules/posixmodule.c:114 is wrong: #if defined(HAVE_SYS_XATTR_H) defined(__GLIBC__) #define USE_XATTRS #endif Because GLIBC doesn't imply a working xattr interface (traditionally a Linux thing?). There seem to be implementations only for Linux, GNU/Hurd and as part of NetBSD Linux compatibility layer. On GNU/kFreeBSD there is only a stub for setxattr, returning -ENOSYS (not implemented). Sure, and that's perfectly fine: those functions will return -1 with errno ENOSYS, and the caller will check that and determine there is no support for extended attributes. The fact that glibc/kfreebsd *now* does not implement these functions should not reflect on limiting features on userland, especially when userland can already know *at runtime* when such features are not available. If somebody implement them, say tomorrow, on glibc/kfreebsd, the python code will just work, with no need for further changes. Hence there is no XATTR_SIZE_MAX defined either. There is no relation on making the xattr functions working and defining this. And actually, it would be even better if you do *not* define it, since assuming a limit a compile time on something that can change at runtime is simply pointless, or even harmful. For now, maybe it would be better as: #if defined(HAVE_SYS_XATTR_H) (defined(__linux__) || defined(__GNU__)) Please no, the current check: #if defined(HAVE_SYS_XATTR_H) defined(__GLIBC__) is perfectly fine. The other problem is that GNU/Hurd doesn't enforce a maximum size and so still doesn't define XATTR_SIZE_MAX; on NetBSD they define it like this for compatibility it seems: http://fxr.watson.org/fxr/source/sys/xattr.h?v=NETBSD5#L52 #define XATTR_SIZE_MAX 65536 /* NetBSD does not enforce this */ So, GNU/Hurd could maybe add something like that if it helps with porting; You still seem to assume there must be some magic MAX constant giving you some upper limit... Consider that Hurd does not provide PATH_MAX, I personally think it would be a mistake providing the two XATTR_*_MAX defines just for the sake of applications not actually checking their return values. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: RFC: drop __GLIBC__ on gcc/kbsd
Hi!
On Tue, 2012-11-06 at 13:05:02 +0100, Pino Toscano wrote:
years ago, when Robert Millan improved the support for k*bsd* in gcc, he
added the __GLIBC__ define as part of the ones provided by gcc itself
(see [1][2]).
Unfortunately, __GLIBC__ is one of the defines provided by glibc itself
(in the internal features.h included in any public header), and
because of this (e)glibc on debian/kfreebsd has to carry the patch
local-undef-glibc.diff. Indeed, compiling trying to compile the simple:
#ifdef __GLIBC__
# error __GLIBC__ defined with no includes!
#endif
int main() { return 0; }
fails on kFreeBSD while it succeeds on Linux and Hurd.
This also causes that porting code like:
-#if defined(__linux__)
+#if defined(__linux__) || defined(__GLIBC__)
makes it work on kFreeBSD but still failing on Hurd (in situation where
there is no #include of stdlib headers prior to that), and in the past
I've been personally hit by this few times (and I'm not the only Hurd
porter to have hit such situation).
Since IMHO it is awkward for a compiler to claim to be a libc,
Well, yes and no, it might seem weird because as you say gcc != glibc,
but then the compiler is built targetting a specfic libc, which trickles
into the triplet (as seen from -dumpmachine), because it needs to know
how to interact with it, among other things.
For me the biggest issues are:
That the macro is defined even when using -ffreestanding (which is just
wrong, although as wrong is to build kernels w/o it, and at least Linux
is doing just that), and the possible problem of kernel headers exposed
to userland that might need to change userland (but not kernel-space)
behaviour (something like
http://lists.debian.org/debian-bsd/2012/02/msg00025.html comes to
mind).
And that it's not consistent across GNU systems, currently upstream gcc
on GNU/kFreeBSD, GNU/kNetBSD and GNU/kOpenSolaris define __GLIBC__,
other systems might not (which can create portability issues due to the
uncertainty as has been pointed out in the past, an example that came to
mind could be http://lists.debian.org/debian-bsd/2010/02/msg00097.html,
or the examples that you mention about problems for GNU/Hurd).
my suggestion (as also shown in the topic) is to drop the definition of
__GLIBC__ done in the k*bsd* configuration of gcc.
My proposal would be to remove it upstream and, once Whezy is released,
backport the patch for any gcc version in Debian. This should leave
plenty of time (at least 1-1½ years) to fix the (few?) kFreeBSD-specific
build failures and issues that could arise because of that (note that
some of the cases were fixed in the past with Hurd porting).
I think -ffreestanding should never define those, after or while that
is fixed in whatever way, all GNU systems should be unified in either
direction, because otherwise it just creates confusion. But that would
require the porters for those systems to agree on either direction,
because as you mention it might cause build failures for them.
GNU/kNetBSD is a non-issue as it's not currently under development.
For GNU/kFreeBSD I'd support either solution, although I think it'd
be better to just stop defining the macro.
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121107070201.ga30...@gaara.hadrons.org
