ney W. Grimes <
> > freebsd-...@gndrsh.dnsmgr.net> wrote:
> > >
> > >
> > >>
> > >> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling
> wrote:
> > >>>
> > >>> While viewing sys/sys/param.h I noticed that the comme
On Mon, Apr 19, 2021 at 7:12 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:
> > On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote:
> > > On Fri, 16 Apr 2021 at 16:22, Warner Losh wrote:
> > > >
> > > > > > As well as "Origin".
> > > > >
> > > > > (Single) Source of Truth, mayb
> On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote:
> > On Fri, 16 Apr 2021 at 16:22, Warner Losh wrote:
> > >
> > > > > As well as "Origin".
> > > >
> > > > (Single) Source of Truth, maybe?
> > >
> > > s/Master, p/P/ also makes sense.
> >
> > IMO instead of lightly rewording the existing
On Sun, Apr 18, 2021 at 07:07:44PM -0400, Ed Maste wrote:
> On Fri, 16 Apr 2021 at 16:22, Warner Losh wrote:
> >
> > > > As well as "Origin".
> > >
> > > (Single) Source of Truth, maybe?
> >
> > s/Master, p/P/ also makes sense.
>
> IMO instead of lightly rewording the existing comment we could ju
On Fri, 16 Apr 2021 at 16:22, Warner Losh wrote:
>
> > > As well as "Origin".
> >
> > (Single) Source of Truth, maybe?
>
> s/Master, p/P/ also makes sense.
IMO instead of lightly rewording the existing comment we could just
remove it, it doesn't really add any clarity.
Instead we ought to add an
On Fri, Apr 16, 2021 at 12:20 PM Michael Gmelin wrote:
>
>
> > On 16. Apr 2021, at 19:29, Rodney W. Grimes <
> freebsd-...@gndrsh.dnsmgr.net> wrote:
> >
> >
> >>
> >> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote:
> >>>
&g
> On 16. Apr 2021, at 19:29, Rodney W. Grimes
> wrote:
>
>
>>
>> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote:
>>>
>>> While viewing sys/sys/param.h I noticed that the comment of the
>>> definition of __FreeBSD_version is pro
> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote:
> >
> > While viewing sys/sys/param.h I noticed that the comment of the
> > definition of __FreeBSD_version is probably out of date.
> >
> > Since the switch to Git, doesn't it have to be 'main'
Am 16.04.21 um 18:38 schrieb Kyle Evans:
> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote:
>>
>> While viewing sys/sys/param.h I noticed that the comment of the
>> definition of __FreeBSD_version is probably out of date.
>>
>> Since the switch to Git, doesn&
n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote:
>
> While viewing sys/sys/param.h I noticed that the comment of the
> definition of __FreeBSD_version is probably out of date.
>
> Since the switch to Git, doesn't it have to be 'main' instead of 'master
While viewing sys/sys/param.h I noticed that the comment of the
definition of __FreeBSD_version is probably out of date.
Since the switch to Git, doesn't it have to be 'main' instead of 'master'?
#cd /usr/src
#diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff
[In part this note shows that the issue is not specific to
cross builds: -a arm64.aarch64 is not essential. But it
also shows just where the /sys/param.h comes from.]
On 2019-Nov-24, at 15:22, Mark Millard wrote:
> On 2019-Nov-24, at 15:11, Ben Woods wrote:
>
>> On Sun, 24 Nov 201
On 2019-Nov-24, at 15:11, Ben Woods wrote:
> On Sun, 24 Nov 2019 at 1:27 pm, Mark Millard wrote:
> My poudiere jail constructions with the likes of -a arm64.aarch64 -x are
> all getting:
>
> awk: can't open file /sys/param.h
> source line number 1
>
> Hi M
On Sun, 24 Nov 2019 at 1:27 pm, Mark Millard wrote:
> My poudiere jail constructions with the likes of -a arm64.aarch64 -x are
> all getting:
>
> awk: can't open file /sys/param.h
> source line number 1
Hi Mark,
I have been getting this same error on amd64 for some
My poudiere jail constructions with the likes of -a arm64.aarch64 -x are
all getting:
awk: can't open file /sys/param.h
source line number 1
If /sys is supposed to be something like:
# ls -ld /sys
lrwxr-xr-x 1 root wheel 11 May 21 2018 /sys -> usr/src/sys
then the path would a
On Sun, Jun 18, 2017 at 12:36:59PM +, Rick Macklem wrote:
> My recent commit (r320062) broke the arm build when it added
> extern int maxbcachebuf;
> to sys/param.h. Although I don't understand the actual failure, I believe
> it is caused by arm/arm/elf_note.S including param
My recent commit (r320062) broke the arm build when it added
extern int maxbcachebuf;
to sys/param.h. Although I don't understand the actual failure, I believe
it is caused by arm/arm/elf_note.S including param.h and then using the
ELFNOTE() macro.
As a temporary fix, I have committed r3
re I had
worked arround it defferently, nonetheless I'm not happy with reverting
to the old behaviour.
Since /usr/include gets populated regardless if "WITHOUT_TOOLCHAIN=true"
was set in src.conf, I think it's a good idea to have the one param.h
also installed, regardless of the option.
Pl
the hint from where include/Makefile gets conditionally
> (MK_TOOLCCHAIN!=no) included ... ?!? Somwhere it start's recursing the
> SUBDIRs, and I guess every binary calls installincludes: from it's
> directory (which works since bsd.lib.mk and bsd.prog.mk include
> bsd.incs.mk),
guess every binary calls installincludes: from it's
directory (which works since bsd.lib.mk and bsd.prog.mk include
bsd.incs.mk), but I can't find at what SUBDIR param.h is involved.
Thanks,
-Harry
signature.asc
Description: OpenPGP digital signature
On Tue, 2014-10-14 at 17:24 +0200, Harald Schmalzbauer wrote:
> Bezüglich David Wolfskill's Nachricht vom 14.10.2014 16:52 (localtime):
> > On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote:
> >> Hello,
> >>
> >> since bsd.port.mk insinst
Bezüglich David Wolfskill's Nachricht vom 14.10.2014 16:52 (localtime):
> On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote:
>> Hello,
>>
>> since bsd.port.mk insinsts on param.h, I have inconveniences on my
>> production systems which were i
On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote:
> Hello,
>
> since bsd.port.mk insinsts on param.h, I have inconveniences on my
> production systems which were installed with "WITHOUT_TOOLCHAIN=true" in
> src.conf (resulting in MK_TOOLCHAIN=no).
>
Hello,
since bsd.port.mk insinsts on param.h, I have inconveniences on my
production systems which were installed with "WITHOUT_TOOLCHAIN=true" in
src.conf (resulting in MK_TOOLCHAIN=no).
My first attempt was the following patch:
--- share/mk/bsd.incs.mk.orig 2014-10-14 16:35:53
Yes, this is an old mail I am replying to ;-)
On Fri, 02-Dec-2005 at 18:42:37 -0800, Doug Barton wrote:
> Andrey Chernov wrote:
> > On Fri, Dec 02, 2005 at 06:16:48PM -0800, Doug Barton wrote:
> >>> Do you mean that scripts without .sh runs in
> >>> the subshell and not damage main shell?
> >> Y
> > Are you trying to compile the -stable version of gcc? We make significant
> > modifications to integrate it within our environment. I would not at all
> > be suprised if the -stable version of gcc doesn't build on -current.
...
> > You are aware that there are gcc ports set up to configure th
On Fri, Mar 14, 2003 at 07:31:02PM -0800, Peter Wemm wrote:
> If you're going to try and
> use the -stable compiler on -current, you'll have to stub this out.
You can use a 4.x compiler on -current in chroot or jail
environment. I haven't tried to build gcc 2.9.x in -current.
--
Steve
To Unsub
Well, I was able to build it on -CURRENT, along with binutils
and other fine software from -STABLE tree. The reason was that
in several cases GCC 3.2.1 proved to be significantly slower
than 2.95.4 (I mean regular integer\floating-point operations,
MMX\SSE\3DNow! is a whole different story). I repl
Rhett Monteg Hollander wrote:
> Hello gentlemen,
>
> the question is, why param.h (v1.65) that comes with 5.0
> doesn't define OBJFORMAT_NAMES and OBJFORMAT_DEFAULT, but
> v1.54 does? These are required by GCC 2.95.4 at compile-time
> (pulled from -STABLE). It may look l
Hello gentlemen,
the question is, why param.h (v1.65) that comes with 5.0
doesn't define OBJFORMAT_NAMES and OBJFORMAT_DEFAULT, but
v1.54 does? These are required by GCC 2.95.4 at compile-time
(pulled from -STABLE). It may look like someone had decided
that GCC2 is of no use in -CU
CMSG_LEN(l) (ALIGN(sizeof(struct cmsghdr)) + (l))
+#defineCMSG_SPACE(l) (_ALIGN(sizeof(struct cmsghdr)) + _ALIGN(l))
+#defineCMSG_LEN(l) (_ALIGN(sizeof(struct cmsghdr)) + (l))
/* "Socket"-level control message types: */
#de
On Wed, 29 Mar 2000, Yoshinobu Inoue wrote:
> > > sys/socket.h:
> > > #ifdef _NO_NAME_SPACE_POLLUTION
> > > #include
> > > #else
> > > #define _NO_NAME_SPACE_POLLUTION
> > > #include
> > > #undef _NO_NAME_SPACE_POLLUTION
> > > #endif
> >
> > I like this for a quick fix. Only define _ALIGN()
8 12:02:12
@@ -37,6 +37,14 @@
#ifndef _SYS_SOCKET_H_
#define_SYS_SOCKET_H_
+#ifdef _NO_NAMESPACE_POLLUTION
+#include
+#else
+#define_NO_NAMESPACE_POLLUTION
+#include
+#undef _NO_NAMESPACE_POLLUTION
+#endif
+
/*
* Definitions related to sockets: type
On Sun, 26 Mar 2000, Yoshinobu Inoue wrote:
> > > OK, then how about creating machine/align.h?
> >
> > That approach in general would give too many headers.
> Then, how about defining a macro which specifies name space
> polluted part, for short term solution.
>
d headers then export
> precisely the names specified by the applicable standard, if any.
Then, how about defining a macro which specifies name space
polluted part, for short term solution.
machine/param.h:
#ifdef _NO_NAME_SPACE_POLLUTION
#define _ALIGN(x) ..
#else
#endif
sys/socket.h:
On Sat, 25 Mar 2000, Yoshinobu Inoue wrote:
> > Instead, CMSG* should use _ALIGN() and _ALIGN() should be implemented
> > somewhere that doesn't add any namespace pollution. We currently
> > use for things like this, but it is already too
> > overloaded.
> OK, then how about creating machine/a
> > So I think machine/param.h should be included from
> > sys/socket.h for more portability.
>
> can't be included in any standard header
> (except in ) because it gives massive, undocumented
> namespace pollution. The macro `MACHINE' is especially likely
et.h as an include file.
> >The old BSD man pages list both param.h and socket.h.
>
> And, from `man sendmsg` on FreeBSD, only,
>
> >SYNOPSIS
> > #include
> > #include
>
> are required.
Same in the not-so-old BSD man pages (Lite1).
> So I thin
man pages for sendmsg()
>only list socket.h as an include file.
>The old BSD man pages list both param.h and socket.h.
And, from `man sendmsg` on FreeBSD, only,
>SYNOPSIS
> #include
> #include
are required.
So I think machine/param.h should be included from
sys/so
In <[EMAIL PROTECTED]> Bruce A. Mah <[EMAIL PROTECTED]>
wrote:
> --==_Exmh_789141986P
> Content-Type: text/plain; charset=us-ascii
>
> If memory serves me right, Yoshinobu Inoue wrote:
>> > > I feel requesting inclusion of machine/param.h for any apps
>&
If memory serves me right, Yoshinobu Inoue wrote:
> > > I feel requesting inclusion of machine/param.h for any apps
> > > which use socket is better. But if there are any other smarter
> > > solution, please let me know and I'll appreciate it much.
>
> > I feel requesting inclusion of machine/param.h for any apps
> > which use socket is better. But if there are any other smarter
> > solution, please let me know and I'll appreciate it much.
>
> should never be included by applications since
> it is an imp
On Wed, 22 Mar 2000, Yoshinobu Inoue wrote:
> I feel requesting inclusion of machine/param.h for any apps
> which use socket is better. But if there are any other smarter
> solution, please let me know and I'll appreciate it much.
should never be included by applications
If memory serves me right, Yoshinobu Inoue wrote:
>
> > 'sys/scocket.h' header file start using ALIGN macro
> > defined in 'machine/param.h' header file while the man page
> > for "socket" only mentioned 'sys/types.h' as the prer
Hello,
> 'sys/scocket.h' header file start using ALIGN macro
> defined in 'machine/param.h' header file while the man page
> for "socket" only mentioned 'sys/types.h' as the prerequisite
> for 'sys/socket.h'.
>
> A
/lib/libc/net/rthdr.c
> 1.38 +8 -13 src/sys/sys/socket.h
> 1.55 +4 -5 src/sys/kern/uipc_socket2.c
> 1.12 +3 -3 src/sys/netinet6/ip6_output.c
> 1.21 +13 -15src/usr.bin/telnet/commands.c
> 1.52 +2 -2 src/sbin/ping/ping.c
'sy
46 matches
Mail list logo
