Re: [PATCH] Remove -nostdinc in aicasm
2011/7/3 Matthias Andree : > Note that there are GCC-version-specific directories for the more > intricate details such as stdarg.h and compiler-specific builtins -- you > don't get those with -I/usr/include either. I know. That's actually the problem I'm trying to solve ( not found). -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Benjamin Kaduk :
> % builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \
> % + builtin_define ("__FreeBSD_kernel__"); \
>
> Is there a reason to prefer just defining the symbol to also including the
> major version number as is done for __FreeBSD__?
None. It's just not useful from our side, but it does no harm either.
(In Debian world, there's no tight integration like you have by
putting FreeBSD kernel and compiler(s) in the same repository. A
particular version of GCC can be used to compile for one kernel or
another, so we wouldn't be able to "commit" it to a specific kernel
version)
--
Robert Millan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Alexander Kabaev :
> I do not think this belongs in GCC at all. You should already have a
> defined symbol to identify your OS and that should be used in cases
> where it matters.
If we wanted to identify the OS as a whole, we can currently do this
with something like:
"#if defined(__FreeBSD_kernel__) && defined(__GLIBC__)"
however, in practice this never happens. What almost every check
wants is either to know about our userland APIs (hence __GLIBC__) or
to know about our kernel APIs (then __FreeBSD_kernel__).
In both cases, the check also wants to match other operating systems
(FreeBSD when it comes to kernel API checks, and GNU/{Linux,Hurd} when
it comes to userland API checks). Using macros that are shared (like
__GLIBC__) or that could potentially be shared (like
__FreeBSD_kernel__) with other operating systems maximizes the
opportunities to:
a) produce simpler checks like "#ifdef __GLIBC__" which are easier to
read and maintain.
b) collaborate with other projects by producing patches which have the
collateral effect of improving portability with other operating
systems.
--
Robert Millan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Ed Maste : >> Alternatively, you should provide the symbol in >> similar way in which we provide __FreeBSD_version, through well-known >> header like sys/param.h and not pollute GCC. > > I suspect this is probably a reasonable alternative, but may mean software > will have to pick up an additional #include. Having to pick up an additional #include is sometimes a source of trouble, because: a) it's easy to forget (and hard to detect when having forgotten only breaks the other platform) b) one might not be able to assume this file is present ( is not in POSIX, for example) Nevermind that, it's much better than not having the macro at all. -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Alexander Kabaev : > GCC is on the way to be > pushed out into ports in FreeBSD and it will not the the only usable > compiler before long. Your proposal will force similar changes in > Clang, Path64 and PCC, , to be really universal which is not > practical. Would my proposal be more welcome if it included a patch for Clang, Path64 and PCC as well? -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
[PATCH] PAGE_SIZE in libsbuf
On arm, ia64, powerpc and sparc, Linux doesn't define a static
PAGE_SIZE. It can only be obtained via sysconf(). In addition,
GNU/Hurd doesn't define PAGE_SIZE at all.
This patch improves portability of libsbuf to be built on those platforms.
In case you'd like to know, Debian is using libsbuf not just for its
GNU/kFreeBSD port, but also provides it to developers in Debian
GNU/Linux:
http://packages.debian.org/search?keywords=libsbuf-dev
https://buildd.debian.org/status/package.php?p=freebsd-libs&suite=sid
--
Robert Millan
Index: sys/kern/subr_sbuf.c
===
--- sys/kern/subr_sbuf.c(revision 223721)
+++ sys/kern/subr_sbuf.c(working copy)
@@ -76,6 +76,11 @@
#defineSBUF_SETFLAG(s, f) do { (s)->s_flags |= (f); } while (0)
#defineSBUF_CLEARFLAG(s, f)do { (s)->s_flags &= ~(f); } while (0)
+#if !defined(PAGE_SIZE) && !defined(_KERNEL)
+#include
+#define PAGE_SIZE sysconf(_SC_PAGESIZE)
+#endif
+
#defineSBUF_MINEXTENDSIZE 16 /* Should be power of
2. */
#ifdef PAGE_SIZE
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] PAGE_SIZE in libsbuf
On Sun, Jul 03, 2011 at 01:47:38PM +0200, Robert Millan wrote: > On arm, ia64, powerpc and sparc, Linux doesn't define a static > PAGE_SIZE. It can only be obtained via sysconf(). In addition, > GNU/Hurd doesn't define PAGE_SIZE at all. > > This patch improves portability of libsbuf to be built on those platforms. > > In case you'd like to know, Debian is using libsbuf not just for its > GNU/kFreeBSD port, but also provides it to developers in Debian > GNU/Linux: > > http://packages.debian.org/search?keywords=libsbuf-dev > https://buildd.debian.org/status/package.php?p=freebsd-libs&suite=sid I think the different workaround is already included in the latest sbuf source. Please see http://svnweb.freebsd.org/base/head/sys/kern/subr_sbuf.c?revision=222015&view=markup pgpPQfiPS3PGr.pgp Description: PGP signature
Re: [PATCH] PAGE_SIZE in libsbuf
2011/7/3 Kostik Belousov : > I think the different workaround is already included in the latest > sbuf source. Please see > http://svnweb.freebsd.org/base/head/sys/kern/subr_sbuf.c?revision=222015&view=markup How does libsbuf react if the guess fails? Also note this codepath isn't tested in FreeBSD (except for pc98). I'm afraid this situation could lead to runtime errors somehow. I'd still propose replacing this guess with a sysconf() check. -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] PAGE_SIZE in libsbuf
On Sun, Jul 03, 2011 at 02:07:59PM +0200, Robert Millan wrote: > 2011/7/3 Kostik Belousov : > > I think the different workaround is already included in the latest > > sbuf source. Please see > > http://svnweb.freebsd.org/base/head/sys/kern/subr_sbuf.c?revision=222015&view=markup > > How does libsbuf react if the guess fails? Also note this codepath > isn't tested in FreeBSD (except for pc98). > > I'm afraid this situation could lead to runtime errors somehow. I'd > still propose replacing this guess with a sysconf() check. Which runtime errors ? The constant is used to size the malloc allocations. Use of the PAGE_SIZE is an attempt to do some optimization. I think it would work if you use e.g. 42 instead of PAGE_SIZE. pgpaKJ1P9cEbq.pgp Description: PGP signature
Re: [PATCH] Remove -nostdinc in aicasm
2011/7/2 Robert Millan :
> 2011/7/2 Benjamin Kaduk :
>> There is a functional difference between '-nostdinc -I/usr/include -I.' even
>> when the standard include search path is just /usr/include -- the standard
>> include paths are always searched last (unless -nostdinc is given), even if
>> they are explicitly listed on the command line. If there are conflicting
>> definitions in /usr/local/foo.h and ./foo.h, this gimmick can be necessary
>> to pull in the correct version. (I've needed to do this when packaging
>> software for the freebsd ports collection, though with /usr/local/include
>> replacing '.'.)
>
> In this case I'd rather be safe than sorry and use -iwithprefix or
> -isystem `gcc --print-file-name=` on GCC only.
I hope this patch is better. Please have a look.
--
Robert Millan
Index: sys/dev/aic7xxx/aicasm/Makefile
===
--- sys/dev/aic7xxx/aicasm/Makefile (revision 223721)
+++ sys/dev/aic7xxx/aicasm/Makefile (working copy)
@@ -26,6 +26,13 @@
NOSTDINC= -nostdinc
CFLAGS+= ${NOSTDINC} -I/usr/include -I.
+# This is needed when using upstream GCC (whose , etc, are
+# not re-enabled by -I/usr/inclde).
+.if ${CC:T:Mclang} != "clang"
+GCCINCDIR!=gcc --print-file-name=
+CFLAGS+= -I${GCCINCDIR}/include -I${GCCINCDIR}/include-fixed
+.endif
+
.ifdef MAKESRCPATH
CFLAGS+= -I${MAKESRCPATH}
.endif
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] PAGE_SIZE in libsbuf
2011/7/3 Kostik Belousov : > Which runtime errors ? The constant is used to size the malloc > allocations. Use of the PAGE_SIZE is an attempt to do some optimization. > > I think it would work if you use e.g. 42 instead of PAGE_SIZE. Never mind then. Thanks for the info. -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
On Sat, 2 Jul 2011 20:05:12 -0700
Garrett Cooper wrote:
> On Sat, Jul 2, 2011 at 7:08 PM, Ed Maste wrote:
> > On Sat, Jul 02, 2011 at 07:37:24PM -0400, Alexander Kabaev wrote:
> >
> >> On Sat, 2 Jul 2011 17:41:03 +0200
> >> Robert Millan wrote:
> >>
> >> > My request is that FreeBSD also defines __FreeBSD_kernel__. If
> >> > this happens, life would be made a bit easier on both sides, as
> >> > it'd be more natural for porters of either system to support
> >> > both using a single macro [1].
> >
> > I think this is a good idea, especially if it means that a single
> > change can make it into upstream projects to support both FreeBSD
> > and Debian kFreeBSD.
> >
> >> I do not think this belongs in GCC at all. You should already have
> >> a defined symbol to identify your OS and that should be used in
> >> cases where it matters.
> >
> > I suspect the proposed patch put it in GCC based on the fact that we
> > already have __FreeBSD__ in contrib/gcc/config/freebsd-spec.h:
> > builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR);
> > \
> >
> >> Alternatively, you should provide the symbol in
> >> similar way in which we provide __FreeBSD_version, through
> >> well-known header like sys/param.h and not pollute GCC.
> >
> > I suspect this is probably a reasonable alternative, but may mean
> > software will have to pick up an additional #include.
> >
> > Out of curiosity, what is the canonical way for software to
> > identify a Linux kernel -- __linux__ or some variant? Where is it
> > defined?
>
> linux is most often reliably defined value based on my personal
> experience and it's defined in gcc [look for
> `builtin_define.*("linux");' (note: this is a regexp..)]. Example:
>
> $ echo '' | gcc -E -xc -dM -c - 2>&1 | grep linux
> #define __linux 1
> #define __linux__ 1
> #define __gnu_linux__ 1
> #define linux 1
>
> HTH,
> -Garrett
__linux__ is exactly what __FreeBSD__ is and dies not identify kernel
but rather Linux as whole OS, whatever that might be these days.
There does not appear to be an universal macro that identifies
environment as using Linux kernel regardless of the rest of components
used (say, to identify Android and Ubuntu or something embedded with
ucLibc as running Linux kernel with different userland
implementations).
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Alexander Kabaev : > > __linux__ is exactly what __FreeBSD__ is and dies not identify kernel > but rather Linux as whole OS, whatever that might be these days. > > There does not appear to be an universal macro that identifies > environment as using Linux kernel regardless of the rest of components > used (say, to identify Android and Ubuntu or something embedded with > ucLibc as running Linux kernel with different userland > implementations). Please-- Linux is not and has never been an OS. __linux__ applies to the kernel, the OS is called GNU/Linux. Call me pedantic, but that was a nonsensical statement. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
On Sun, 3 Jul 2011 12:41:44 +0200 Robert Millan wrote: > 2011/7/3 Alexander Kabaev : > > GCC is on the way to be > > pushed out into ports in FreeBSD and it will not the the only usable > > compiler before long. Your proposal will force similar changes in > > Clang, Path64 and PCC, , to be really universal which is > > not practical. > > Would my proposal be more welcome if it included a patch for Clang, > Path64 and PCC as well? > > -- > Robert Millan Not really, unless you have way of sticking this definition into past compiler releases. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [PATCH] __FreeBSD_kernel__
On Sun, 3 Jul 2011 15:38:41 +0100 Chris Rees wrote: > 2011/7/3 Alexander Kabaev : > > > > __linux__ is exactly what __FreeBSD__ is and dies not identify > > kernel but rather Linux as whole OS, whatever that might be these > > days. > > > > There does not appear to be an universal macro that identifies > > environment as using Linux kernel regardless of the rest of > > components used (say, to identify Android and Ubuntu or something > > embedded with ucLibc as running Linux kernel with different userland > > implementations). > > Please-- Linux is not and has never been an OS. > > __linux__ applies to the kernel, the OS is called GNU/Linux. > > Call me pedantic, but that was a nonsensical statement. > > Chris How about you spare Linux vs. GNU/Linux wordplay for advocacy lists, where they belong? -- Alexander Kabaev signature.asc Description: PGP signature
Re: [PATCH] __FreeBSD_kernel__
On 3 July 2011 15:44, Alexander Kabaev wrote: > On Sun, 3 Jul 2011 15:38:41 +0100 > Chris Rees wrote: >> 2011/7/3 Alexander Kabaev : >> > >> > __linux__ is exactly what __FreeBSD__ is and dies not identify >> > kernel but rather Linux as whole OS, whatever that might be these >> > days. >> > >> > There does not appear to be an universal macro that identifies >> > environment as using Linux kernel regardless of the rest of >> > components used (say, to identify Android and Ubuntu or something >> > embedded with ucLibc as running Linux kernel with different userland >> > implementations). >> >> Please-- Linux is not and has never been an OS. >> >> __linux__ applies to the kernel, the OS is called GNU/Linux. >> >> Call me pedantic, but that was a nonsensical statement. >> >> Chris > > How about you spare Linux vs. GNU/Linux wordplay for advocacy lists, > where they belong? [Further discussion on IRC] Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Alexander Kabaev : > __linux__ is exactly what __FreeBSD__ is and dies not identify kernel > but rather Linux as whole OS, whatever that might be these days. > > There does not appear to be an universal macro that identifies > environment as using Linux kernel regardless of the rest of components > used (say, to identify Android and Ubuntu or something embedded with > ucLibc as running Linux kernel with different userland > implementations). I think I'll cowardly try to stick to a practical POV and avoid the discussion about names that tends to get people excited about :-) So from a purely practical perspective: - If __linux__ is defined, this implies you're using a specific kernel. - If you're using that specific kernel, this implies __linux__ is defined. which explains why using __linux__ to identify the kernel is useful and reliable. Can __linux__ be used to identify more things? Most notably, can __linux__ be used to identify userland API? - If __linux__ is defined, this does not imply you're using GNU libc. - If you're using GNU libc, this does not imply __linux__ is defined. which explains why using __linux__ to identify libc is a bad idea. However, it can be useful to identify a set of different C libraries (Glibc, Bionic, uclibc, etc) if they share the property you're interested in. -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Alexander Kabaev : > Not really, unless you have way of sticking this definition into past > compiler releases. There is one way, but it's slow. It basically involves waiting for long enough that any past release of any compiler you care about includes the macros you need, before starting to use them. :-) -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Robert Millan : > 2011/7/3 Alexander Kabaev : >> Not really, unless you have way of sticking this definition into past >> compiler releases. > > There is one way, but it's slow. It basically involves waiting for > long enough that any past release of any compiler you care about > includes the macros you need, before starting to use them. :-) However, in the case of FreeBSD, where the compilers are imported into your codebase, isn't it enough if support is present in the FreeBSD version of these compilers (for production and development releases of FreeBSD), plus the latest release of the upstream version of each of those compilers? -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] __FreeBSD_kernel__
On 7/3/11 7:35 AM, Alexander Kabaev wrote: __linux__ is exactly what __FreeBSD__ is and dies not identify kernel but rather Linux as whole OS, whatever that might be these days. There does not appear to be an universal macro that identifies environment as using Linux kernel regardless of the rest of components used (say, to identify Android and Ubuntu or something embedded with ucLibc as running Linux kernel with different userland implementations). I thought it was (__linux__ && __KERNEL__) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] build config(8) on GNU systems
* Robert Millan , 20110702 16:56:
> Index: usr.sbin/config/main.c
> ===
> --- usr.sbin/config/main.c(revision 223721)
> +++ usr.sbin/config/main.c(working copy)
> @@ -591,7 +591,11 @@
> if ((dirp = opendir(p)) == NULL)
> err(EX_OSERR, "opendir %s", p);
> while ((dp = readdir(dirp)) != NULL) {
> +#ifdef _DIRENT_HAVE_D_NAMLEN
> i = dp->d_namlen - 2;
> +#else
> + i = strlen (dp->d_name) - 2;
> +#endif
> /* Skip non-headers */
> if (dp->d_name[i] != '.' || dp->d_name[i + 1] != 'h')
> continue;
Why not simply use strlen() unconditionally?
--
Ed Schouten
WWW: http://80386.nl/
pgpjq8GSwsoLs.pgp
Description: PGP signature
Re: [PATCH] build config(8) on GNU systems
* Zhihao Yuan , 20110703 22:22: > Programmers always want to make things "cooler". Just leave the > ->d_namlen there :) Portability isn't achieved by adding #ifdefs, but by writing portable code. ;-) -- Ed Schouten WWW: http://80386.nl/ pgpbqUUDWhNbF.pgp Description: PGP signature
Re: [PATCH] build config(8) on GNU systems
2011/7/3 Ed Schouten : > * Zhihao Yuan , 20110703 22:22: >> Programmers always want to make things "cooler". Just leave the >> ->d_namlen there :) > > Portability isn't achieved by adding #ifdefs, but by writing portable > code. ;-) I really don't mind either way. I hope you two can agree on what's best ;-) -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] build config(8) on GNU systems
Programmers always want to make things "cooler". Just leave the
->d_namlen there :)
On Sun, Jul 3, 2011 at 2:49 PM, Ed Schouten wrote:
> * Robert Millan , 20110702 16:56:
>> Index: usr.sbin/config/main.c
>> ===
>> --- usr.sbin/config/main.c (revision 223721)
>> +++ usr.sbin/config/main.c (working copy)
>> @@ -591,7 +591,11 @@
>> if ((dirp = opendir(p)) == NULL)
>> err(EX_OSERR, "opendir %s", p);
>> while ((dp = readdir(dirp)) != NULL) {
>> +#ifdef _DIRENT_HAVE_D_NAMLEN
>> i = dp->d_namlen - 2;
>> +#else
>> + i = strlen (dp->d_name) - 2;
>> +#endif
>> /* Skip non-headers */
>> if (dp->d_name[i] != '.' || dp->d_name[i + 1] != 'h')
>> continue;
>
> Why not simply use strlen() unconditionally?
>
> --
> Ed Schouten
> WWW: http://80386.nl/
>
--
Zhihao Yuan, nickname lichray
The best way to predict the future is to invent it.
___
4BSD -- http://4bsd.biz/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] build config(8) on GNU systems
Fixed in r223744. Thanks! -- Ed Schouten WWW: http://80386.nl/ pgpBp8MHciKH9.pgp Description: PGP signature
Re: [PATCH] __FreeBSD_kernel__
2011/7/3 Mark Linimon : > On Sun, Jul 03, 2011 at 05:47:02PM +0200, Robert Millan wrote: >> isn't it enough if support is present in the FreeBSD >> version of these compilers (for production and development releases of >> FreeBSD), plus the latest release of the upstream version of each of >> those compilers? > > You may find the gcc team very uninterested in changing things around > to support FreeBSD. >From my experience interacting with them, what I know for sure is they won't add a new macro for FreeBSD unless they get a clear signal that FreeBSD wants it (e.g. by checking it in its downstream version of GCC). Other than that, I don't see a problem with getting a one-line patch accepted in upstream GCC tree. -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
