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,
> 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
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
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
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:
> >>>
> 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' instead of 'm
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, doe
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'?
>
This isn't base
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
--- sys/sys/param.h.orig
[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 Mark,
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 app
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.h an
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 r320070
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.
Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194401
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.0 +0200
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).
My first attempt
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 installed with WITHOUT_TOOLCHAIN=true
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 insinsts on param.h, I have inconveniences on my
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
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
The old code that used to work for you got the version via sysctl, so I
was recommending that you keep
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?
Yes, that's
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 the FSF
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 -CURRENT
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 like someone had decided
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
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
it would be OK without any anti-redefinition ifdefs. Redefinition
is only a micro-pessimization since there are only #define's (no
typedefs, etc.) and won't occur often since machine/param.h should only
be included by sys/param.h, sys/pipe.h and sys/socket.h. Reinclusion
can be optimized
On Wed, 29 Mar 2000, Yoshinobu Inoue wrote:
sys/socket.h:
#ifdef _NO_NAME_SPACE_POLLUTION
#include machine/param.h
#else
#define _NO_NAME_SPACE_POLLUTION
#include machine/param.h
#undef _NO_NAME_SPACE_POLLUTION
#endif
I like this for a quick fix. Only define _ALIGN
sys/socket.h:
#ifdef _NO_NAME_SPACE_POLLUTION
#include machine/param.h
#else
#define _NO_NAME_SPACE_POLLUTION
#include machine/param.h
#undef _NO_NAME_SPACE_POLLUTION
#endif
I like this for a quick fix. Only define _ALIGN() like the current
ALIGN(). Don't define all
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.
machine/param.h:
#ifdef
Arrgh. Now it seems I might need to reverse my position. I looked
through some code fragments in UNIX Network Programming (Volume 1,
Second Edition, pp. 362-365), and there's some precedent for needing
sys/param.h with the CMSG*() macros.
On the other hand, RFC 2292 and draft-ietf-ipngwg
So I think machine/param.h should be included from
sys/socket.h for more portability.
machine/param.h can't be included in any standard header
(except in sys/param.h) because it gives massive, undocumented
namespace pollution. The macro `MACHINE' is especially likely
to conflict
be handled in machine/types.h, but currently
aren't because machine/types.h would give namespace pollution in
ANSI headers. I think headers like machine/param.h and machine/types.h
should define only names in the implementation namespace, so that they
can be used in standard headers. The standard
, but currently
aren't because machine/types.h would give namespace pollution in
ANSI headers. I think headers like machine/param.h and machine/types.h
should define only names in the implementation namespace, so that they
can be used in standard headers. The standard headers then export
precisely
-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
'sys/scocket.h' header file start using ALIGN macro
defined in 'machine/param.h' header file while
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 prerequisite
for 'sys/socket.h'.
As a result the
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.
machine/param.h should never be included by applications since
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.
machine/param.h should never be included by applications since
it is an implementation detail.
Specify
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
which use socket is better. But if there are any
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'.
As a result the 'net/pchar' port is now broken.
Yes, th
44 matches
Mail list logo
