Re: CVS commit: src/share/mk

2024-01-03 Thread Izumi Tsutsui
I would also prefer current general "virt68k", rather than
specific emulators like qemu68k etc. because:

- it's unlikely that someone will design and implement new virtual
  Ethernet/storage I/O devices for ancient architectures

- we should avoid dumb copies of MD locore.s, pmap_bootstrap.c,
   headers, and src/distrib files etc.

- even if we will support different VM implementation, we can
  still have multiple kernel config files in a single port,
  as we've merged sun3 (020 + Sun's MMU) and sun3x (030 MMU)
  into a single sun3 port in the past
  (atari and evbarm also have multiple GENERIC like config files
   for different archtectures)

Thanks,
---
Izumi Tsutsui


Re: CVS commit: src/share/mk

2024-01-03 Thread Jason Thorpe



> On Jan 3, 2024, at 9:16 AM, Jason Thorpe  wrote:
> 
> There’s really nothing Qemu specific about it, other than Qemu version number 
> extraction.

Let me elaborate, actually, now that I am not constrained by thumbs-only typing.

It uses the generic Linux m68k “bootinfo”, which specify the machine type and 
address of the various devices, and provisions for how reset/halt are handled 
are also dealt with generically.  Every Linux m68k platform uses this mechanism 
and I would be shocked (SHOCKED) if some hypothetical future non-Qemu m68k 
VirtIO platform did not support Linux natively.  The Qemu version extraction is 
actually done with one of those “bootinfo” records.

There are really only two assumptions that are made:

- RAM starts at PA $., the kernel starts with the MMU disabled, and is 
loaded at its link address.

- I/O devices start at PA $FF00., and that they can be mapped VA==PA with a 
TT register.

The latter would be pretty easy to deal with dynamically if the situation 
arose.  And the former would be possible to adapt to if that assumption were to 
suddenly not be valid.  Heck, the hp300 kernel is linked at VA=$. and 
knows how to deal with the start of RAM varying based on how much memory is 
installed (whereas the end of RAM is always at the same location, at the top of 
the physical address space. Weirdos.)

-- thorpej



Re: CVS commit: src/share/mk

2024-01-03 Thread Jason Thorpe
There’s really nothing Qemu specific about it, other than Qemu version number 
extraction.

-- thorpej
Sent from my iPhone.

> On Jan 2, 2024, at 11:03 PM, Valery Ushakov  wrote:
> 
> On Wed, Jan 03, 2024 at 02:48:06 +, Jason R Thorpe wrote:
> 
>> Add virt68k to MACHINES.m68k.
> 
> "virt" is too generic a name, if this is specifically a qemu version,
> may be it should have been called qemu68k... Guess it's too late now.
> 
> -uwe


Re: CVS commit: src/share/mk

2024-01-02 Thread Valery Ushakov
On Wed, Jan 03, 2024 at 02:48:06 +, Jason R Thorpe wrote:

> Add virt68k to MACHINES.m68k.

"virt" is too generic a name, if this is specifically a qemu version,
may be it should have been called qemu68k... Guess it's too late now.

-uwe


re: CVS commit: src/share/mk

2023-08-08 Thread matthew green
please review this.  i'll try to figure out tests for everything,
though it seems annoying :)

  https://www.netbsd.org/~mrg/gcc12-use-after-free.diff

it should handle all the open use-after-free problems.


.mrg.

ps: you'll notice no new headers needed for ptrdiff_t usage  ;)


re: CVS commit: src/share/mk

2023-08-08 Thread matthew green
matthew green writes:
> > > - used = dst - conv->wbuff;
> > > + size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;
> >
> > Any particular reason why there is a cast to uintptr_t here? I don't
> > think there is a guarantee that you can calculate an offset by
> > subtracting uintptr_ts calculated from pointers. The description in the
> > C Standard only guarantees that you can convert them back to a pointer
> > which compares the same to the original, but that's it. I don't find any
> > other promises about uintptr_t.
>
> in this case, they're not necessary it seems.  probably left
> over from my initial attempts at this workaround.

uh, apparently i forgot to save the file before compiling,
because simply removing them returns the sign-compare warning,
but that's fixable by using ptrdiff_t.


.mrg.


re: CVS commit: src/share/mk

2023-08-08 Thread matthew green
> > -   used = dst - conv->wbuff;
> > +   size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;
>
> Any particular reason why there is a cast to uintptr_t here? I don't
> think there is a guarantee that you can calculate an offset by
> subtracting uintptr_ts calculated from pointers. The description in the
> C Standard only guarantees that you can convert them back to a pointer
> which compares the same to the original, but that's it. I don't find any
> other promises about uintptr_t.

in this case, they're not necessary it seems.  probably left
over from my initial attempts at this workaround.


.mrg.


Re: CVS commit: src/share/mk

2023-08-08 Thread Rhialto
On Tue 08 Aug 2023 at 14:10:41 +0200, Joerg Sonnenberger wrote:
> On Tue, Aug 08, 2023 at 01:42:39PM +0200, Rhialto wrote:
> > On Tue 08 Aug 2023 at 09:44:41 +1000, matthew green wrote:
> > > Index: lib/libedit/chartype.c
> > > ===
> > > RCS file: /cvsroot/src/lib/libedit/chartype.c,v
> > > retrieving revision 1.36
> > > diff -p -u -r1.36 chartype.c
> > > --- lib/libedit/chartype.c30 Oct 2022 19:11:31 -  1.36
> > > +++ lib/libedit/chartype.c7 Aug 2023 23:41:44 -
> > > @@ -235,17 +235,17 @@ ct_visual_string(const wchar_t *s, ct_bu
> > >   }
> > >  
> > >   /* failed to encode, need more buffer space */
> > > - used = dst - conv->wbuff;
> > > + size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;
> > 
> > Any particular reason why there is a cast to uintptr_t here? I don't
> > think there is a guarantee that you can calculate an offset by
> > subtracting uintptr_ts calculated from pointers. The description in the
> > C Standard only guarantees that you can convert them back to a pointer
> > which compares the same to the original, but that's it. I don't find any
> > other promises about uintptr_t.
> 
> Given that we used to make this assumption for offsetof like most
> systems, this seems to be portable naval gazing to me.

It is one thing to hide such an assumption away in a macro (and with all
compilers currently in use, offsetof() is mapped to __builtin_offsetof()
(see ), which quite likely exists because of the
unstandardness of the other version), but quite another to open-code it
again and again in general code. Think of the
PDP-10 port!

I was expecting some sort of answer related to unsigned vs signed sizes
and differences, or something like that, for which there is likely a
cleaner solution.

> Joerg
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work.   --I. Rose


signature.asc
Description: PGP signature


Re: CVS commit: src/share/mk

2023-08-08 Thread Joerg Sonnenberger
On Tue, Aug 08, 2023 at 01:42:39PM +0200, Rhialto wrote:
> On Tue 08 Aug 2023 at 09:44:41 +1000, matthew green wrote:
> > Index: lib/libedit/chartype.c
> > ===
> > RCS file: /cvsroot/src/lib/libedit/chartype.c,v
> > retrieving revision 1.36
> > diff -p -u -r1.36 chartype.c
> > --- lib/libedit/chartype.c  30 Oct 2022 19:11:31 -  1.36
> > +++ lib/libedit/chartype.c  7 Aug 2023 23:41:44 -
> > @@ -235,17 +235,17 @@ ct_visual_string(const wchar_t *s, ct_bu
> > }
> >  
> > /* failed to encode, need more buffer space */
> > -   used = dst - conv->wbuff;
> > +   size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;
> 
> Any particular reason why there is a cast to uintptr_t here? I don't
> think there is a guarantee that you can calculate an offset by
> subtracting uintptr_ts calculated from pointers. The description in the
> C Standard only guarantees that you can convert them back to a pointer
> which compares the same to the original, but that's it. I don't find any
> other promises about uintptr_t.

Given that we used to make this assumption for offsetof like most
systems, this seems to be portable naval gazing to me.

Joerg


Re: CVS commit: src/share/mk

2023-08-08 Thread Rhialto
On Tue 08 Aug 2023 at 09:44:41 +1000, matthew green wrote:
> Index: lib/libedit/chartype.c
> ===
> RCS file: /cvsroot/src/lib/libedit/chartype.c,v
> retrieving revision 1.36
> diff -p -u -r1.36 chartype.c
> --- lib/libedit/chartype.c30 Oct 2022 19:11:31 -  1.36
> +++ lib/libedit/chartype.c7 Aug 2023 23:41:44 -
> @@ -235,17 +235,17 @@ ct_visual_string(const wchar_t *s, ct_bu
>   }
>  
>   /* failed to encode, need more buffer space */
> - used = dst - conv->wbuff;
> + size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;

Any particular reason why there is a cast to uintptr_t here? I don't
think there is a guarantee that you can calculate an offset by
subtracting uintptr_ts calculated from pointers. The description in the
C Standard only guarantees that you can convert them back to a pointer
which compares the same to the original, but that's it. I don't find any
other promises about uintptr_t.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work.   --I. Rose


signature.asc
Description: PGP signature


Re: CVS commit: src/share/mk

2023-08-08 Thread Taylor R Campbell
> Date: Mon, 7 Aug 2023 23:58:50 +0200
> From: Tobias Nygren 
> 
> Is this sort of fix acceptable for the above cases?
> 
> + ptrdiff_t offset = pos - buf;
>   new_buf = realloc(buf, buf_size);
>   if (!new_buf)
>   err(2, "realloc of linebuf to %zu bytes failed",
>   buf_size);
> - 
> +
>   end = new_buf + buf_size;
> - pos = new_buf + (pos - buf);
> + pos = new_buf + offset;
>   buf = new_buf;

Yes, this is a good approach.

Even if it's suboptimal in some cases, it is very easy to audit
mechanical changes, which is important if there are a lot of them.

Any further case-specific simplifications (like changing ptrdiff_t to
size_t, since it will always be nonnegative here; just using `size_t
offset = buf_size' before `buf_size *= 2', since since pos == end and
end == buf + buf_size) can be done afterward in a separate commit.


re: CVS commit: src/share/mk

2023-08-07 Thread matthew green
Valery Ushakov writes:
> On Mon, Aug 07, 2023 at 23:58:50 +0200, Tobias Nygren wrote:
>
> > Is this sort of fix acceptable for the above cases?
> [...]
> > +   ptrdiff_t offset = pos - buf;
> [...]
> > -   pos = new_buf + (pos - buf);
> > +   pos = new_buf + offset;
>
> I think so.  But e.g. in this particular case I don't see why pos
> pointer is needed at all.  If pos is made into a size_t pos; index
> into the buf instead of a separate pointer, one avoids the whole thing
> and "end" can be g/c'ed too, b/c you can just compare the index to the
> "buf_size".  But the above kind of fix has the advantage of being more
> or less mechanical.

yup, i agree.  if we can fix it better, please do, but i'm all for
making it "less bad" if not properly fixed like the above.

i've used this idiom in a couple of places, but didn't quite get it
working in several others.

these are the problematic files i've see:

lib/libc/net/gethnamaddr.c
lib/libedit/chartype.c
lib/libkvm/kvm_proc.c
usr.bin/find/misc.c
usr.bin/mail/fio.c
external/bsd/pdisk/dist/io.c
usr.bin/rs/rs.c
usr.bin/sort/files.c

the first 3 i worked around, eg below, but i think i only tested
the gethnamaddr.c portion so far.


.mrg.


Index: lib/libc/net/gethnamaddr.c
===
RCS file: /cvsroot/src/lib/libc/net/gethnamaddr.c,v
retrieving revision 1.94
diff -p -u -r1.94 gethnamaddr.c
--- lib/libc/net/gethnamaddr.c  19 Apr 2022 20:32:15 -  1.94
+++ lib/libc/net/gethnamaddr.c  7 Aug 2023 23:41:44 -
@@ -110,10 +110,11 @@ __weak_alias(gethostent,_gethostent)
 
 #define addalias(d, s, arr, siz) do {  \
if (d >= [siz]) {   \
+   size_t _off = d - arr;  \
char **xptr = realloc(arr, (siz + 10) * sizeof(*arr)); \
if (xptr == NULL)   \
goto nospc; \
-   d = xptr + (d - arr);   \
+   d = xptr + _off;\
arr = xptr; \
siz += 10;  \
}   \
Index: lib/libedit/chartype.c
===
RCS file: /cvsroot/src/lib/libedit/chartype.c,v
retrieving revision 1.36
diff -p -u -r1.36 chartype.c
--- lib/libedit/chartype.c  30 Oct 2022 19:11:31 -  1.36
+++ lib/libedit/chartype.c  7 Aug 2023 23:41:44 -
@@ -235,17 +235,17 @@ ct_visual_string(const wchar_t *s, ct_bu
}
 
/* failed to encode, need more buffer space */
-   used = dst - conv->wbuff;
+   size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;
if (ct_conv_wbuff_resize(conv, conv->wsize + CT_BUFSIZ) == -1)
return NULL;
-   dst = conv->wbuff + used;
+   dst = conv->wbuff + sused;
}
 
if (dst >= (conv->wbuff + conv->wsize)) { /* sigh */
-   used = dst - conv->wbuff;
+   size_t sused = (uintptr_t)dst - (uintptr_t)conv->wbuff;
if (ct_conv_wbuff_resize(conv, conv->wsize + CT_BUFSIZ) == -1)
return NULL;
-   dst = conv->wbuff + used;
+   dst = conv->wbuff + sused;
}
 
*dst = L'\0';
Index: lib/libkvm/kvm_proc.c
===
RCS file: /cvsroot/src/lib/libkvm/kvm_proc.c,v
retrieving revision 1.98
diff -p -u -r1.98 kvm_proc.c
--- lib/libkvm/kvm_proc.c   19 Apr 2022 20:32:16 -  1.98
+++ lib/libkvm/kvm_proc.c   7 Aug 2023 23:41:44 -
@@ -980,7 +980,7 @@ kvm_argv(kvm_t *kd, const struct minipro
if (len + cc > kd->argspc_len) {
ptrdiff_t off;
char **pp;
-   char *op = kd->argspc;
+   uintptr_t op = (uintptr_t)kd->argspc;
 
kd->argspc_len *= 2;
kd->argspc = _kvm_realloc(kd, kd->argspc,
@@ -991,7 +991,7 @@ kvm_argv(kvm_t *kd, const struct minipro
 * Adjust argv pointers in case realloc moved
 * the string space.
 */
-   off = kd->argspc - op;
+   off = (uintptr_t)kd->argspc - op;
for (pp = kd->argv; pp < argv; pp++)
*pp += off;
ap += off;


Re: Restoring pointers after realloc (was: Re: CVS commit: src/share/mk)

2023-08-07 Thread Valery Ushakov
On Tue, Aug 08, 2023 at 00:44:41 +0200, Roland Illig wrote:

> Am 07.08.2023 um 23:58 schrieb Tobias Nygren:
> > Is this sort of fix acceptable for the above cases?
> >
> > +   ptrdiff_t offset = pos - buf;
> > new_buf = realloc(buf, buf_size);
> > -   pos = new_buf + (pos - buf);
> > +   pos = new_buf + offset;
> 
> Yes.
> 
> Instead of ptrdiff_t, I prefer to use size_t to avoid having to include
> , even if that means an additional type cast at WARNS=6 level:
> 
> > +   size_t offset = (size_t)(pos - buf);

I just had a massive cognitive dissonance moment... :)


-uwe


Re: CVS commit: src/share/mk

2023-08-07 Thread Valery Ushakov
On Mon, Aug 07, 2023 at 23:58:50 +0200, Tobias Nygren wrote:

> Is this sort of fix acceptable for the above cases?
[...]
> + ptrdiff_t offset = pos - buf;
[...]
> - pos = new_buf + (pos - buf);
> + pos = new_buf + offset;

I think so.  But e.g. in this particular case I don't see why pos
pointer is needed at all.  If pos is made into a size_t pos; index
into the buf instead of a separate pointer, one avoids the whole thing
and "end" can be g/c'ed too, b/c you can just compare the index to the
"buf_size".  But the above kind of fix has the advantage of being more
or less mechanical.

-uwe


Restoring pointers after realloc (was: Re: CVS commit: src/share/mk)

2023-08-07 Thread Roland Illig
Am 07.08.2023 um 23:58 schrieb Tobias Nygren:
> Is this sort of fix acceptable for the above cases?
>
> + ptrdiff_t offset = pos - buf;
>   new_buf = realloc(buf, buf_size);
> - pos = new_buf + (pos - buf);
> + pos = new_buf + offset;

Yes.

Instead of ptrdiff_t, I prefer to use size_t to avoid having to include
, even if that means an additional type cast at WARNS=6 level:

> + size_t offset = (size_t)(pos - buf);

Roland



Re: CVS commit: src/share/mk

2023-08-07 Thread Tobias Nygren
On Thu, 3 Aug 2023 23:30:31 +0900
Rin Okuyama  wrote:

> On 2023/08/03 23:23, Valery Ushakov wrote:
> > On Thu, Aug 03, 2023 at 13:33:27 +, Rin Okuyama wrote:
> > 
> >> -Wuse-after-free for GCC 12 is premature. It fires on a common idiom:
> >>
> >>newbuf = realloc(buf, size);
> >>p = newbuf + (p - buf);
> >>
> >> Let shut this up for GCC 12 (with hoping it gets improved for 13!).
> > 
> > C99 says
> > 
> > J.2  Undefined behavior
> > 
> > [#1]   The   behavior   is   undefined   in   the  following
> > circumstances:
> > [...]
> >   -- The  value of a pointer to an object whose lifetime has
> >  ended is used (6.2.4).
> > 
> > 
> > Yes, for the "obvious" implementation of pointers as addresses the
> > above idiom happens to work, but it doesn't make that idiom any less
> > UB.
> 
> Ah, I only thought about "obvious" impl. Thank you for kind
> explanation! I will revert them for now.

Hi,

Is this sort of fix acceptable for the above cases?

-Tobias

RCS file: /cvsroot/src/usr.bin/sort/files.c,v
retrieving revision 1.42
diff -p -u -r1.42 files.c
--- files.c 5 Aug 2015 07:10:03 -   1.42
+++ files.c 7 Aug 2023 21:53:45 -
@@ -199,13 +199,14 @@ seq(FILE *fp, u_char **line)
/* Long line - double size of buffer */
/* XXX: Check here for stupidly long lines */
buf_size *= 2;
+   ptrdiff_t offset = pos - buf;
new_buf = realloc(buf, buf_size);
if (!new_buf)
err(2, "realloc of linebuf to %zu bytes failed",
buf_size);
-   
+
end = new_buf + buf_size;
-   pos = new_buf + (pos - buf);
+   pos = new_buf + offset;
buf = new_buf;
}
}


re: CVS commit: src/share/mk

2023-08-03 Thread matthew green
> > Ah, I only thought about "obvious" impl. Thank you for kind
> > explanation! I will revert them for now.
>
> We should fix those cases that gcc12 found.

i was able to fix some of them with some code to apply offsets
generated before realloc() or free(), but not in all case.

a couple of them were pretty difficult because the alloc and
the re-align were not close together.

i was going to post about this soon, this is about 10% of the
remaining files i have in my tree... i actually don't think
the ${CC_..} change was worth reverting, as long as it was
using the "-Wno-error=..." method -- ie, the warnings are
still displayed, but not as errors (vs, the "-Wno-..." method
which elides the warning entirely.)

ie, i agree we should fix all these, i'm just not against
using the error disable as a temporary measure.

thanks.


.mrg.


Re: CVS commit: src/share/mk

2023-08-03 Thread Valery Ushakov
On Thu, Aug 03, 2023 at 23:30:31 +0900, Rin Okuyama wrote:

> On 2023/08/03 23:23, Valery Ushakov wrote:
> > On Thu, Aug 03, 2023 at 13:33:27 +, Rin Okuyama wrote:
> > 
> > > -Wuse-after-free for GCC 12 is premature. It fires on a common idiom:
> > > 
> > >   newbuf = realloc(buf, size);
> > >   p = newbuf + (p - buf);
> > > 
> > > Let shut this up for GCC 12 (with hoping it gets improved for 13!).
> > 
> > C99 says
> > 
> > J.2  Undefined behavior
> > 
> > [#1]   The   behavior   is   undefined   in   the  following
> > circumstances:
> > [...]
> >   -- The  value of a pointer to an object whose lifetime has
> >  ended is used (6.2.4).
> > 
> > 
> > Yes, for the "obvious" implementation of pointers as addresses the
> > above idiom happens to work, but it doesn't make that idiom any less
> > UB.
> 
> Ah, I only thought about "obvious" impl. Thank you for kind
> explanation! I will revert them for now.

We should fix those cases that gcc12 found.

While it may seem like a stretch of imagination (e.g. compiling C to
JVM or something like that, where the pointer is actually a nontrivial
object), "fat" function pointers on itanium were a mundane thing and
caused their fair share of problems for code that naively assumed
trivial "address-only" pointers.  I would imagine UB sanitizers will
trip up on that idiom too...

Thanks!

-uwe


Re: CVS commit: src/share/mk

2023-08-03 Thread Rin Okuyama

On 2023/08/03 23:23, Valery Ushakov wrote:

On Thu, Aug 03, 2023 at 13:33:27 +, Rin Okuyama wrote:


-Wuse-after-free for GCC 12 is premature. It fires on a common idiom:

newbuf = realloc(buf, size);
p = newbuf + (p - buf);

Let shut this up for GCC 12 (with hoping it gets improved for 13!).


C99 says

J.2  Undefined behavior

[#1]   The   behavior   is   undefined   in   the  following
circumstances:
[...]
  -- The  value of a pointer to an object whose lifetime has
 ended is used (6.2.4).


Yes, for the "obvious" implementation of pointers as addresses the
above idiom happens to work, but it doesn't make that idiom any less
UB.


Ah, I only thought about "obvious" impl. Thank you for kind
explanation! I will revert them for now.

Thanks,
rin


Re: CVS commit: src/share/mk

2023-08-03 Thread Valery Ushakov
On Thu, Aug 03, 2023 at 13:33:27 +, Rin Okuyama wrote:

> -Wuse-after-free for GCC 12 is premature. It fires on a common idiom:
> 
>   newbuf = realloc(buf, size);
>   p = newbuf + (p - buf);
>
> Let shut this up for GCC 12 (with hoping it gets improved for 13!).

C99 says

   J.2  Undefined behavior

   [#1]   The   behavior   is   undefined   in   the  following
   circumstances:
[...]
 -- The  value of a pointer to an object whose lifetime has
ended is used (6.2.4).


Yes, for the "obvious" implementation of pointers as addresses the
above idiom happens to work, but it doesn't make that idiom any less
UB.

-uwe


Re: Detecting typos in makefiles (was: Re: CVS commit: src/share/mk)

2023-01-15 Thread Simon Gerraty
On Sun, 15 Jan 2023 19:14:14 +0100, Roland Illig writes:
>It is really unfortunate that make didn't catch this typo by itself.
>
>.if ${MACHINE_ARCH} =3D=3D "x86_64" || \
> ${MACHINE_ARCH} =3D=3D "i386" || \
> ${MACHINE_ARCH} =3D=3D "alpha" || \\
> !empty(MACHINE_ARCH:Maarch64*) || \
> !empty(MACHINE_ARCH:Msparc*)
>
>(The 'alpha' line has a trailing '\\' instead of the usual '\'.)

Yes warnings would be good I think.

FWIW the above is why I encouage use of :N to reduce the complexity of
conditionals (eaier to extend without screwing up) as in:

.if ${MACHINE_ARCH:Nalpha:Ni386:Nx86_64} == ""

is equivalent to the first 3 lines above.


Detecting typos in makefiles (was: Re: CVS commit: src/share/mk)

2023-01-15 Thread Roland Illig

Am 15.01.2023 um 11:51 schrieb Nick Hudson:

Module Name:src
Committed By:   skrll
Date:   Sun Jan 15 10:51:04 UTC 2023

Modified Files:
src/share/mk: bsd.own.mk

Log Message:
Really switch aarch64 and sparc binutils to 2.39


To generate a diff of this commit:
cvs rdiff -u -r1.1293 -r1.1294 src/share/mk/bsd.own.mk


It is really unfortunate that make didn't catch this typo by itself.

.if ${MACHINE_ARCH} == "x86_64" || \
${MACHINE_ARCH} == "i386" || \
${MACHINE_ARCH} == "alpha" || \\
!empty(MACHINE_ARCH:Maarch64*) || \
!empty(MACHINE_ARCH:Msparc*)

(The 'alpha' line has a trailing '\\' instead of the usual '\'.)

Here is what happened:

1. In the condition '${SOMETHING} || \\', the trailing '\\' is a bare
word, which in the case of a simple '.if' directive is interpreted as
'defined(\\)'.  So if there had been a variable named '\\', the branch
would have been taken.

2. If the branch is not taken, make ignores all text until the next
'.elif' or '.else' or '.endif' line.

3. If the branch is taken, the line below the '.if' line is indented
with a few spaces and then starts with '!'.  This line is interpreted as
a dependency using the dependency operator '!'.  The left-hand side of
the dependency line is empty, saying 'nothing depends on these sources'.
 Except for the case of automatically generated makefiles, this doesn't
make sense.

4. The '!' dependency has 3 sources:

4a. The first and third sources are archive members.  In the first
source, the archive is named 'empty' and the member is named
'MACHINE_ARCH:Maarch64*'.

4b. The second source is '||'.


There are a few things that make could warn about:

* The variable name '\\' is very rare.

* The bare word '\\' occurs in a condition that otherwise uses "proper
expressions".

* The dependency line starts with spaces.

* The dependency line has no targets, only sources.

* The dependency line contains an archive member.  Archive members,
while required by POSIX, are seldom used.

* The archive filename is 'empty', which is missing the typical archive
filename suffix '.a'.

* The archive member contains a ':', which is uncommon for filenames.

* The dependency source '||' has a name that is neither a usual filename
nor a usual variable name.


None of these things generates any warning right now.  Should they?

Roland



Re: Detecting typos in makefiles (was: Re: CVS commit: src/share/mk)

2023-01-15 Thread Christos Zoulas
That's very funny. Yes I think we should warn. I don't think that \\ should
be a valid variable name.

Best,

christos

> On Jan 15, 2023, at 1:14 PM, Roland Illig  wrote:
> 
> Am 15.01.2023 um 11:51 schrieb Nick Hudson:
>> Module Name: src
>> Committed By:skrll
>> Date:Sun Jan 15 10:51:04 UTC 2023
>> 
>> Modified Files:
>>  src/share/mk: bsd.own.mk
>> 
>> Log Message:
>> Really switch aarch64 and sparc binutils to 2.39
>> 
>> 
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.1293 -r1.1294 src/share/mk/bsd.own.mk
> 
> It is really unfortunate that make didn't catch this typo by itself.
> 
> .if ${MACHINE_ARCH} == "x86_64" || \
>${MACHINE_ARCH} == "i386" || \
>${MACHINE_ARCH} == "alpha" || \\
>!empty(MACHINE_ARCH:Maarch64*) || \
>!empty(MACHINE_ARCH:Msparc*)
> 
> (The 'alpha' line has a trailing '\\' instead of the usual '\'.)
> 
> Here is what happened:
> 
> 1. In the condition '${SOMETHING} || \\', the trailing '\\' is a bare
> word, which in the case of a simple '.if' directive is interpreted as
> 'defined(\\)'.  So if there had been a variable named '\\', the branch
> would have been taken.
> 
> 2. If the branch is not taken, make ignores all text until the next
> '.elif' or '.else' or '.endif' line.
> 
> 3. If the branch is taken, the line below the '.if' line is indented
> with a few spaces and then starts with '!'.  This line is interpreted as
> a dependency using the dependency operator '!'.  The left-hand side of
> the dependency line is empty, saying 'nothing depends on these sources'.
> Except for the case of automatically generated makefiles, this doesn't
> make sense.
> 
> 4. The '!' dependency has 3 sources:
> 
> 4a. The first and third sources are archive members.  In the first
> source, the archive is named 'empty' and the member is named
> 'MACHINE_ARCH:Maarch64*'.
> 
> 4b. The second source is '||'.
> 
> 
> There are a few things that make could warn about:
> 
> * The variable name '\\' is very rare.
> 
> * The bare word '\\' occurs in a condition that otherwise uses "proper
> expressions".
> 
> * The dependency line starts with spaces.
> 
> * The dependency line has no targets, only sources.
> 
> * The dependency line contains an archive member.  Archive members,
> while required by POSIX, are seldom used.
> 
> * The archive filename is 'empty', which is missing the typical archive
> filename suffix '.a'.
> 
> * The archive member contains a ':', which is uncommon for filenames.
> 
> * The dependency source '||' has a name that is neither a usual filename
> nor a usual variable name.
> 
> 
> None of these things generates any warning right now.  Should they?
> 
> Roland



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/share/mk

2021-05-27 Thread Christos Zoulas
Ok, I did not realize that all mips had switched.

christos

> On May 27, 2021, at 4:48 PM, matthew green  wrote:
> 
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Thu May 27 20:29:24 UTC 2021
>> 
>> Modified Files:
>>  src/share/mk: bsd.own.mk
>> 
>> Log Message:
>> mips64 only works with gcc-10
> 
> the MACHINE_CPU==mips test should cover mipsn64, that i assume
> you mean here...
> 
> 
> .mrg.



signature.asc
Description: Message signed with OpenPGP


re: CVS commit: src/share/mk

2021-05-27 Thread matthew green
"Christos Zoulas" writes:
> Module Name:  src
> Committed By: christos
> Date: Thu May 27 20:29:24 UTC 2021
>
> Modified Files:
>   src/share/mk: bsd.own.mk
>
> Log Message:
> mips64 only works with gcc-10

the MACHINE_CPU==mips test should cover mipsn64, that i assume
you mean here...


.mrg.


Re: CVS commit: src/share/mk

2020-11-09 Thread Rin Okuyama

On 2020/11/10 1:15, Christos Zoulas wrote:

- when we need to run ctfconvert, go through an intermediate ${.TARGET}.o
   file, instead of writing directly to ${.TARGET} and then overwriting
   ${.TARGET} with ctfconvert. This avoids build failures after a build
   got interrupted (the "partially built from C" scourge).


Thanks, I wanted this!

rin


re: CVS commit: src/share/mk

2020-07-13 Thread matthew green
Joerg Sonnenberger writes:
> On Mon, Jul 13, 2020 at 07:22:51AM +, matthew green wrote:
> > Module Name:src
> > Committed By:   mrg
> > Date:   Mon Jul 13 07:22:51 UTC 2020
> > 
> > Modified Files:
> > src/share/mk: bsd.README
> > 
> > Log Message:
> > MKLLVMRT is automatically enabled on x86 and arm64, not mesa18+.
> 
> It is both.

we only use mesa20 in xsrc now so there's no "choice"
about mesa here.  just haven't deleted mesa.old yet..


.mrg.


Re: CVS commit: src/share/mk

2020-07-13 Thread Joerg Sonnenberger
On Mon, Jul 13, 2020 at 07:22:51AM +, matthew green wrote:
> Module Name:  src
> Committed By: mrg
> Date: Mon Jul 13 07:22:51 UTC 2020
> 
> Modified Files:
>   src/share/mk: bsd.README
> 
> Log Message:
> MKLLVMRT is automatically enabled on x86 and arm64, not mesa18+.

It is both.

Joerg


re: CVS commit: src/share/mk

2020-02-08 Thread matthew green
> what sort of testing did you do with this change?  simply removing
> it breaks the build.  and trying to fix it otherwise is hard.  see
> only a month ago:

huh.

my build *did* complete.  so something else has changed in the
last month or so to fix this... 

sorry for the noise.


.mrg.


re: CVS commit: src/share/mk

2020-02-08 Thread matthew green
"Maya Rashish" writes:
> Module Name:  src
> Committed By: maya
> Date: Sat Feb  8 21:16:53 UTC 2020
> 
> Modified Files:
>   src/share/mk: sys.mk
> 
> Log Message:
> Don't special case aarch64 and add -fomit-frame-pointer to builds.
> 
> This behaviour is probably due to a past behaviour of clang, where it
> always emitted frame pointer code.
> This is no longer true for clang on netbsd, and I don't think it was true
> for GCC.
> 
> Meanwhile, this flag bleeds into pkgsrc where it breaks random packages,
> requiring workarounds like lang/ruby*-base/hacks.mk.

what sort of testing did you do with this change?  simply removing
it breaks the build.  and trying to fix it otherwise is hard.  see
only a month ago:

revision 1.142
date: 2020-01-08 14:04:24 -0800;  author: christos;  state: Exp;  lines: +1 -1; 
 commitid: NcvOnC9CgM4A5WRB;
Back out previous. This has no chance to work unless the make variable parsing
is not changed do that instead of scanning for a single character delim ':',
it scans for "?:". This is because !empty(COMPILE.c:M*-pg*) contains a ':'.

revision 1.141
date: 2020-01-07 20:15:45 -0800;  author: christos;  state: Exp;  lines: +2 -2; 
 commitid: U2dp6ScXDBHOaQRB;
tweak the DBG rule that -fomit-frame-pointer for aarch64 when profiling
(because the compiler complains), to use a match with the compile flags
and *pg*, instead of using a match to a target suffix (which is NetBSD
build-specific). Pointed out by phone@.


.mrg.


Re: CVS commit: src/share/mk

2019-12-20 Thread David Holland
On Thu, Dec 19, 2019 at 11:04:25PM -0500, Christos Zoulas wrote:
 > Module Name: src
 > Committed By:christos
 > Date:Fri Dec 20 04:04:25 UTC 2019
 > 
 > Modified Files:
 >  src/share/mk: bsd.sys.mk sys.mk
 > 
 > Log Message:
 > move MV to sys.mk because it is used there. Pointed out by joerg@

Since the original change was apparently in January, does this need to
be in -9?

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/share/mk

2019-12-19 Thread Joerg Sonnenberger
On Mon, Jan 21, 2019 at 04:11:55PM -0500, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Mon Jan 21 21:11:55 UTC 2019
> 
> Modified Files:
>   src/share/mk: bsd.dep.mk bsd.hostprog.mk bsd.info.mk bsd.kmodule.mk
>   bsd.lib.mk bsd.man.mk bsd.prog.mk bsd.sys.mk bsd.test.mk bsd.x11.mk
>   sys.mk
> 
> Log Message:
> Most of the mv operations are to move temporary files to their final place.
> Some use -f, others don't. This can lead to spurious build failures when
> the user performing the build changes. Centralize, and always use -f.

At least the sys.mk part of this breaks standalone Makefiles, because MV
is not defined.

Joerg


Re: CVS commit: src/share/mk

2019-11-15 Thread Roy Marples

On 15/11/2019 13:41, Greg Troxel wrote:

Me too.


#metoo

Roy


Re: CVS commit: src/share/mk

2019-11-15 Thread Greg Troxel
David Brownlee  writes:

> On Thu, 14 Nov 2019 at 21:05, Christos Zoulas  wrote:
>>
>> The first issue is that I prefer to have tar respect existing
>> symlinks (ones that it did not create by default -- without having
>> to specify extra flags) since to do this (in my opinion) does not
>> pose a security risk. Yes my implementation is Q+D, but it works.
>>
>> https://www.netbsd.org/~christos/track-symlinks.diff
>>
>> The second issue is that the way libarchive-tar overwrites existing
>> files is by removing them first, and writing them directly to the
>> final destination pathname. This creates a significant amount of
>> time where the file is either not available or not completely
>> written. Imagine trying to replace shared libraries or programs
>> frequently used. Pax-as-tar wrote the file to a temporary one first
>> and used rename(2) to atomically replace it. I've written a patch
>> to do the same for libarchive-tar:
>>
>> https://www.netbsd.org/~christos/libarchive-atomic.diff
>>
>> With those two patches we can put libarchive as tar back and we don't
>> need to make any other changes since behavioraly the old pax-as-tar
>> and libarchive-tar behave the same for those two cases that bothered us.
>>
>> I am inclined to just commit them and flip the default again.
>
> I could see an argument for having an option to turn off the
> extract-to-temp-and-rename behaviour (not that I'd use it), but I'd be
> very happy to see both above changes in as defaults and us back onto
> libarchive-tar

Me too.

My sense of the list is that

  most people want unpacking sets over a system to work as well as it
  used to work

  some people really want a tar that handles newer formats, and probably
  everything thinks this would be good

  some concern has been expresseed over performance, but more people
  have expressed the notion that things working correctly (which does
  not have a universal definition) is more important.

so Christos's proposal seems to steer very well to this rough consensus.

> Thanks for working on this!

Seconded!


Re: CVS commit: src/share/mk

2019-11-15 Thread David Brownlee
On Thu, 14 Nov 2019 at 21:05, Christos Zoulas  wrote:
>
> In article <2c05e1ed-8410-fa0f-d786-06ee6e1c4...@marples.name>,
> Roy Marples   wrote:
> >On 14/11/2019 05:47, Martin Husemann wrote:
> >> On Thu, Nov 14, 2019 at 03:53:02PM +1100, matthew green wrote:
> >>> i'm not happy about this change.  i wish that bsdtar was
> >>> fixed to not be unfriendly, because it mostly is a better
> >>> implementation.  just these edge cases are rather ..
> >>> problematic yet these issues are being ignored or
> >>> rejected as being irrelevant.
> >>
> >> Me neither, especially as we now effectively have different command line
> >> args passed from sysinst to tar depending on the tar invocation (and this
> >> is all hard coded). I'll have to make it a define in sysinst depending
> >> on the seleted tar variant :-/.
> >
> >Just for the record, I don't really care about different cmd line args,
> >symlinks and security involved.
> >
> >My expectation is that a modern NetBSD tar can extract a modern tar
> >archive from other sources.
> >
> >If it cannot do this we have failed.
>
> So I am trying to find some time to pursue the two issues I have
> with upstream and understand if they will accept the following two
> changes (or versions thereof):
>
> The first issue is that I prefer to have tar respect existing
> symlinks (ones that it did not create by default -- without having
> to specify extra flags) since to do this (in my opinion) does not
> pose a security risk. Yes my implementation is Q+D, but it works.
>
> https://www.netbsd.org/~christos/track-symlinks.diff
>
> The second issue is that the way libarchive-tar overwrites existing
> files is by removing them first, and writing them directly to the
> final destination pathname. This creates a significant amount of
> time where the file is either not available or not completely
> written. Imagine trying to replace shared libraries or programs
> frequently used. Pax-as-tar wrote the file to a temporary one first
> and used rename(2) to atomically replace it. I've written a patch
> to do the same for libarchive-tar:
>
> https://www.netbsd.org/~christos/libarchive-atomic.diff
>
> With those two patches we can put libarchive as tar back and we don't
> need to make any other changes since behavioraly the old pax-as-tar
> and libarchive-tar behave the same for those two cases that bothered us.
>
> I am inclined to just commit them and flip the default again.

I could see an argument for having an option to turn off the
extract-to-temp-and-rename behaviour (not that I'd use it), but I'd be
very happy to see both above changes in as defaults and us back onto
libarchive-tar

Thanks for working on this!

David


Re: CVS commit: src/share/mk

2019-11-14 Thread Christos Zoulas
In article <2c05e1ed-8410-fa0f-d786-06ee6e1c4...@marples.name>,
Roy Marples   wrote:
>On 14/11/2019 05:47, Martin Husemann wrote:
>> On Thu, Nov 14, 2019 at 03:53:02PM +1100, matthew green wrote:
>>> i'm not happy about this change.  i wish that bsdtar was
>>> fixed to not be unfriendly, because it mostly is a better
>>> implementation.  just these edge cases are rather ..
>>> problematic yet these issues are being ignored or
>>> rejected as being irrelevant.
>> 
>> Me neither, especially as we now effectively have different command line
>> args passed from sysinst to tar depending on the tar invocation (and this
>> is all hard coded). I'll have to make it a define in sysinst depending
>> on the seleted tar variant :-/.
>
>Just for the record, I don't really care about different cmd line args, 
>symlinks and security involved.
>
>My expectation is that a modern NetBSD tar can extract a modern tar 
>archive from other sources.
>
>If it cannot do this we have failed.

So I am trying to find some time to pursue the two issues I have
with upstream and understand if they will accept the following two
changes (or versions thereof):

The first issue is that I prefer to have tar respect existing
symlinks (ones that it did not create by default -- without having
to specify extra flags) since to do this (in my opinion) does not
pose a security risk. Yes my implementation is Q+D, but it works.

https://www.netbsd.org/~christos/track-symlinks.diff

The second issue is that the way libarchive-tar overwrites existing
files is by removing them first, and writing them directly to the
final destination pathname. This creates a significant amount of
time where the file is either not available or not completely
written. Imagine trying to replace shared libraries or programs
frequently used. Pax-as-tar wrote the file to a temporary one first
and used rename(2) to atomically replace it. I've written a patch
to do the same for libarchive-tar:

https://www.netbsd.org/~christos/libarchive-atomic.diff

With those two patches we can put libarchive as tar back and we don't
need to make any other changes since behavioraly the old pax-as-tar
and libarchive-tar behave the same for those two cases that bothered us.

I am inclined to just commit them and flip the default again.

Best,

christos



Re: CVS commit: src/share/mk

2019-11-13 Thread Roy Marples

On 14/11/2019 04:53, matthew green wrote:

TLDR; libarchive has feature parity with NetBSD pax.


i don't know how you can make this claim.  are you simply
ignoring that others have a problem you haven't seen?


How can you make this claim?
Are you ignoring my very simple request that NetBSD tar should be able 
to extract modern archives?


I asked this simple question internally:
"Why does this archive give error on extraction using NetBSD?"

and lo the answer was
"Our tar is too old and not maintained. Does libarchive work?"

And verily I answered
"Yes! It does work? Can we fix the standard tar?"

"N" cameth the answer.

So, I asked the simple question ..
"Can we change the tar from pax to libarchive?"

And verily no-one had any reason to dispute this . until now.


people's upgrades are breaking now in ways they never have
before.  that's not feature parity by a long shot.

instead of ignoring the real issues, perhaps you could
argue that bsdtar should actually match the features of
pax-as-tar, and then we can all benefit from the change.

i'm not happy about this change.  i wish that bsdtar was
fixed to not be unfriendly, because it mostly is a better
implementation.  just these edge cases are rather ..
problematic yet these issues are being ignored or
rejected as being irrelevant.

we can do better.  i like christos' patch.  there's some
nuance with the symlink vs security issue, but there is
only clear additional failure cases with the unlink vs
rename issue.


Please do not be blind to my issues either.

From the conversations internally it's basically revert to pax and fuck 
modern archives or add a warning note to upgraders that chroot symlinks 
wont work on upgrading.


I myself have been bitten by this on my ERLITE router.
Real men have backups!
Actually I didn't (lesson learned here) and rc.d/nsd and unbound refused 
to copy over  so I was able to restore my configs from the chroots.

So here, our rc.d is A WIN FOR UPGRADERS!

Can we not add a note to check links in etc?

Roy


Re: CVS commit: src/share/mk

2019-11-13 Thread Roy Marples

On 14/11/2019 05:47, Martin Husemann wrote:

On Thu, Nov 14, 2019 at 03:53:02PM +1100, matthew green wrote:

i'm not happy about this change.  i wish that bsdtar was
fixed to not be unfriendly, because it mostly is a better
implementation.  just these edge cases are rather ..
problematic yet these issues are being ignored or
rejected as being irrelevant.


Me neither, especially as we now effectively have different command line
args passed from sysinst to tar depending on the tar invocation (and this
is all hard coded). I'll have to make it a define in sysinst depending
on the seleted tar variant :-/.


Just for the record, I don't really care about different cmd line args, 
symlinks and security involved.


My expectation is that a modern NetBSD tar can extract a modern tar 
archive from other sources.


If it cannot do this we have failed.

Roy


Re: CVS commit: src/share/mk

2019-11-13 Thread Martin Husemann
On Thu, Nov 14, 2019 at 03:53:02PM +1100, matthew green wrote:
> i'm not happy about this change.  i wish that bsdtar was
> fixed to not be unfriendly, because it mostly is a better
> implementation.  just these edge cases are rather ..
> problematic yet these issues are being ignored or
> rejected as being irrelevant.

Me neither, especially as we now effectively have different command line
args passed from sysinst to tar depending on the tar invocation (and this
is all hard coded). I'll have to make it a define in sysinst depending
on the seleted tar variant :-/.

Martin


re: CVS commit: src/share/mk

2019-11-13 Thread matthew green
> TLDR; libarchive has feature parity with NetBSD pax.

i don't know how you can make this claim.  are you simply
ignoring that others have a problem you haven't seen?

people's upgrades are breaking now in ways they never have
before.  that's not feature parity by a long shot.

instead of ignoring the real issues, perhaps you could
argue that bsdtar should actually match the features of
pax-as-tar, and then we can all benefit from the change.

i'm not happy about this change.  i wish that bsdtar was
fixed to not be unfriendly, because it mostly is a better
implementation.  just these edge cases are rather ..
problematic yet these issues are being ignored or
rejected as being irrelevant.

we can do better.  i like christos' patch.  there's some
nuance with the symlink vs security issue, but there is
only clear additional failure cases with the unlink vs
rename issue.


.mrg.


Re: CVS commit: src/share/mk

2019-11-13 Thread Kamil Rytarowski
On 14.11.2019 05:11, Kamil Rytarowski wrote:
> On 14.11.2019 04:55, Roy Marples wrote:
>> On 14/11/2019 02:40, Kamil Rytarowski wrote:
>>> On 14.11.2019 03:34, Roy Marples wrote:
 On 13/11/2019 22:32, Joerg Sonnenberger wrote:
> Module Name:    src
> Committed By:    joerg
> Date:    Wed Nov 13 22:32:16 UTC 2019
>
> Modified Files:
>  src/share/mk: bsd.own.mk
>
> Log Message:
> Restore pax-as-tar.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.1159 -r1.1160 src/share/mk/bsd.own.mk

 And so we are doomed that we cannot open more modern archives with the
 base system tar  :/
>>>
>>> Nothing is determined here to be doomed.
>>>
>>> Michal prepared a summary of TAR features in his write up:
>>>
>>> https://dev.gentoo.org/~mgorny/articles/portability-of-tar-features.html
>>
>> TLDR; libarchive has feature parity with NetBSD pax.
>> So why the peanut gallery complaints or is this write missing something
>> or I've missed something.
>>
>> I've had two recent archives that failed to open with NetBSD pax as tar
>> and the internal consensous was to use libarchive instead because NetBSD
>> pax wasn't maintained and thus would never support these.
>>
>> So, to re-iterate, am I doomed never to open these archives w NetBSD
>> base OS or do you have some magic wand of +4 solving Roy's problems I've
>> not seen yet?
>>
>> Roy
> 
> Please file a PR and/or use gtar/bsdtar from pkgsrc as a fallback.
> 

Another fallback option is to set MKBSDTAR=yes when building base OS.



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src/share/mk

2019-11-13 Thread Kamil Rytarowski
On 14.11.2019 04:55, Roy Marples wrote:
> On 14/11/2019 02:40, Kamil Rytarowski wrote:
>> On 14.11.2019 03:34, Roy Marples wrote:
>>> On 13/11/2019 22:32, Joerg Sonnenberger wrote:
 Module Name:    src
 Committed By:    joerg
 Date:    Wed Nov 13 22:32:16 UTC 2019

 Modified Files:
  src/share/mk: bsd.own.mk

 Log Message:
 Restore pax-as-tar.


 To generate a diff of this commit:
 cvs rdiff -u -r1.1159 -r1.1160 src/share/mk/bsd.own.mk
>>>
>>> And so we are doomed that we cannot open more modern archives with the
>>> base system tar  :/
>>
>> Nothing is determined here to be doomed.
>>
>> Michal prepared a summary of TAR features in his write up:
>>
>> https://dev.gentoo.org/~mgorny/articles/portability-of-tar-features.html
> 
> TLDR; libarchive has feature parity with NetBSD pax.
> So why the peanut gallery complaints or is this write missing something
> or I've missed something.
> 
> I've had two recent archives that failed to open with NetBSD pax as tar
> and the internal consensous was to use libarchive instead because NetBSD
> pax wasn't maintained and thus would never support these.
> 
> So, to re-iterate, am I doomed never to open these archives w NetBSD
> base OS or do you have some magic wand of +4 solving Roy's problems I've
> not seen yet?
> 
> Roy

Please file a PR and/or use gtar/bsdtar from pkgsrc as a fallback.



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src/share/mk

2019-11-13 Thread Roy Marples

On 14/11/2019 02:40, Kamil Rytarowski wrote:

On 14.11.2019 03:34, Roy Marples wrote:

On 13/11/2019 22:32, Joerg Sonnenberger wrote:

Module Name:    src
Committed By:    joerg
Date:    Wed Nov 13 22:32:16 UTC 2019

Modified Files:
 src/share/mk: bsd.own.mk

Log Message:
Restore pax-as-tar.


To generate a diff of this commit:
cvs rdiff -u -r1.1159 -r1.1160 src/share/mk/bsd.own.mk


And so we are doomed that we cannot open more modern archives with the
base system tar  :/


Nothing is determined here to be doomed.

Michal prepared a summary of TAR features in his write up:

https://dev.gentoo.org/~mgorny/articles/portability-of-tar-features.html


TLDR; libarchive has feature parity with NetBSD pax.
So why the peanut gallery complaints or is this write missing something 
or I've missed something.


I've had two recent archives that failed to open with NetBSD pax as tar 
and the internal consensous was to use libarchive instead because NetBSD 
pax wasn't maintained and thus would never support these.


So, to re-iterate, am I doomed never to open these archives w NetBSD 
base OS or do you have some magic wand of +4 solving Roy's problems I've 
not seen yet?


Roy


Re: CVS commit: src/share/mk

2019-11-13 Thread Kamil Rytarowski
On 14.11.2019 03:34, Roy Marples wrote:
> On 13/11/2019 22:32, Joerg Sonnenberger wrote:
>> Module Name:    src
>> Committed By:    joerg
>> Date:    Wed Nov 13 22:32:16 UTC 2019
>>
>> Modified Files:
>> src/share/mk: bsd.own.mk
>>
>> Log Message:
>> Restore pax-as-tar.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.1159 -r1.1160 src/share/mk/bsd.own.mk
> 
> And so we are doomed that we cannot open more modern archives with the
> base system tar  :/

Nothing is determined here to be doomed.

Michal prepared a summary of TAR features in his write up:

https://dev.gentoo.org/~mgorny/articles/portability-of-tar-features.html



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src/share/mk

2019-11-13 Thread Roy Marples

On 13/11/2019 22:32, Joerg Sonnenberger wrote:

Module Name:src
Committed By:   joerg
Date:   Wed Nov 13 22:32:16 UTC 2019

Modified Files:
src/share/mk: bsd.own.mk

Log Message:
Restore pax-as-tar.


To generate a diff of this commit:
cvs rdiff -u -r1.1159 -r1.1160 src/share/mk/bsd.own.mk


And so we are doomed that we cannot open more modern archives with the 
base system tar  :/


re: CVS commit: src/share/mk

2019-08-13 Thread Paul Goyette

So 9.99.7 does not install *_pic.a any longer while earlier versions did.
Shouldn't they be marked as "obsolete" in the set lists?


this would break builds that do want them.

they've been built conditionally for a long time, we just changed
the default value of the condition is all.

i understand where you are coming from -- i have to clean my
destdir for dozens of builds now -- but there's no easy answer
to this besides manual fixing..

(it fortunately does not leave anything in the objdir, as these
files are created as part of creating the shlibs -- the only
difference now is that we don't install them by dfeault.)


Ah, got it!  Thanks for the detailed explanation.



++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


re: CVS commit: src/share/mk

2019-08-13 Thread matthew green
Thomas Klausner writes:
> On Sat, Aug 10, 2019 at 08:20:17AM -0400, Christos Zoulas wrote:
> > Module Name:src
> > Committed By:   christos
> > Date:   Sat Aug 10 12:20:17 UTC 2019
> > 
> > Modified Files:
> > src/share/mk: bsd.own.mk
> > 
> > Log Message:
> > Don't install PIC libraries by default because they are too big since they
> > contain debug symbols. I supplied a patch in PR/54449 to remove the 
> > debugging
> > symbols but folks preferred to not install them at all.
> 
> So 9.99.7 does not install *_pic.a any longer while earlier versions did.
> Shouldn't they be marked as "obsolete" in the set lists?

this would break builds that do want them.

they've been built conditionally for a long time, we just changed
the default value of the condition is all.

i understand where you are coming from -- i have to clean my 
destdir for dozens of builds now -- but there's no easy answer
to this besides manual fixing..

(it fortunately does not leave anything in the objdir, as these
files are created as part of creating the shlibs -- the only
difference now is that we don't install them by dfeault.)


.mrg.


Re: CVS commit: src/share/mk

2019-08-13 Thread Paul Goyette

On Wed, 14 Aug 2019, Thomas Klausner wrote:


On Sat, Aug 10, 2019 at 08:20:17AM -0400, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Sat Aug 10 12:20:17 UTC 2019

Modified Files:
src/share/mk: bsd.own.mk

Log Message:
Don't install PIC libraries by default because they are too big since they
contain debug symbols. I supplied a patch in PR/54449 to remove the debugging
symbols but folks preferred to not install them at all.


So 9.99.7 does not install *_pic.a any longer while earlier versions did.
Shouldn't they be marked as "obsolete" in the set lists?


Yes.  They should be obsolete.


++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+


Re: CVS commit: src/share/mk

2019-08-13 Thread Thomas Klausner
On Sat, Aug 10, 2019 at 08:20:17AM -0400, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Sat Aug 10 12:20:17 UTC 2019
> 
> Modified Files:
>   src/share/mk: bsd.own.mk
> 
> Log Message:
> Don't install PIC libraries by default because they are too big since they
> contain debug symbols. I supplied a patch in PR/54449 to remove the debugging
> symbols but folks preferred to not install them at all.

So 9.99.7 does not install *_pic.a any longer while earlier versions did.
Shouldn't they be marked as "obsolete" in the set lists?
 Thomas


Re: CVS commit: src/share/mk

2019-06-21 Thread Kamil Rytarowski
On 21.06.2019 18:29, Christos Zoulas wrote:
> On Jun 21,  3:21pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: CVS commit: src/share/mk
> 
> | I've started to observe issues with signals in recent GDB as well, a
> | debugger is stopping self and detaching from terminal.
> | 
> | Please tell me whether you want me to fix it. It slows down testing of
> | my kernel changes now. I had to revert my previous change due to GDB
> | misbehavior (I suspect that the problems come from the recent GDB upgrade).=
> 
> Go for it. I think we need more "gdb" atf tests...
> 

Thanks!

I got NetBSD truss to be very reliable with multiple threads, but GDB is
misbehaving.

> | I can spend some more time on fixing local GDB, upstreaming the support
> | and adding support for running the regress test in GDB... this will
> | allow us to get more predictable results with future GDB upgrades, cover
> | kernel code paths with GDB tests and maybe run regression tests on the
> | GDB buildbot.
> 
> Sounds good to me!
> 

I've compared src/ GDB 8.3 and upstream GDB 8.3.

There are a lot of differences and it looks like a lot of our changes
predate gpl2->gpl3 switch in GDB. I have an impression that sometimes we
unintentionally revert to an older GDB code.

I will start with upstreaming small code chunks first and getting
upstream GDB to work on NetBSD/amd64 with its regression tests... It
should be better long term action than mutating local in-tree version.

> Thanks,
> 
> christos
> 




signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src/share/mk

2019-06-21 Thread Christos Zoulas
On Jun 21,  3:21pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: CVS commit: src/share/mk

| I've started to observe issues with signals in recent GDB as well, a
| debugger is stopping self and detaching from terminal.
| 
| Please tell me whether you want me to fix it. It slows down testing of
| my kernel changes now. I had to revert my previous change due to GDB
| misbehavior (I suspect that the problems come from the recent GDB upgrade).=

Go for it. I think we need more "gdb" atf tests...

| I can spend some more time on fixing local GDB, upstreaming the support
| and adding support for running the regress test in GDB... this will
| allow us to get more predictable results with future GDB upgrades, cover
| kernel code paths with GDB tests and maybe run regression tests on the
| GDB buildbot.

Sounds good to me!

Thanks,

christos


Re: CVS commit: src/share/mk

2019-06-21 Thread Christos Zoulas
Both of them should be simple to fix... Let me take a look.

christos

> On Jun 21, 2019, at 7:55 AM, Martin Husemann  wrote:
> 
> On Fri, Jun 21, 2019 at 11:22:18AM +, m...@netbsd.org wrote:
>> On Fri, Jun 21, 2019 at 01:15:18PM +0200, Martin Husemann wrote:
>>> On Fri, Jun 21, 2019 at 11:08:16AM +, m...@netbsd.org wrote:
 Please revert for mips. The debugger is extremely broken, and the old
 version is slightly less broken.
>>> 
>>> Same for sparc64.
>>> 
>>> Martin
>>> 
>> 
>> What's the failure mode for sparc64?
> 
> Various signal handling issues, gdb TSTOPs itself or something when receiving
> events (or so it looks).
> 
> Martin



Re: CVS commit: src/share/mk

2019-06-21 Thread Martin Husemann
On Fri, Jun 21, 2019 at 11:22:18AM +, m...@netbsd.org wrote:
> On Fri, Jun 21, 2019 at 01:15:18PM +0200, Martin Husemann wrote:
> > On Fri, Jun 21, 2019 at 11:08:16AM +, m...@netbsd.org wrote:
> > > Please revert for mips. The debugger is extremely broken, and the old
> > > version is slightly less broken.
> > 
> > Same for sparc64.
> > 
> > Martin
> > 
> 
> What's the failure mode for sparc64?

Various signal handling issues, gdb TSTOPs itself or something when receiving
events (or so it looks).

Martin


Re: CVS commit: src/share/mk

2019-06-21 Thread maya
On Fri, Jun 21, 2019 at 01:15:18PM +0200, Martin Husemann wrote:
> On Fri, Jun 21, 2019 at 11:08:16AM +, m...@netbsd.org wrote:
> > Please revert for mips. The debugger is extremely broken, and the old
> > version is slightly less broken.
> 
> Same for sparc64.
> 
> Martin
> 

What's the failure mode for sparc64?


Re: CVS commit: src/share/mk

2019-06-21 Thread Martin Husemann
On Fri, Jun 21, 2019 at 11:08:16AM +, m...@netbsd.org wrote:
> Please revert for mips. The debugger is extremely broken, and the old
> version is slightly less broken.

Same for sparc64.

Martin



Re: CVS commit: src/share/mk

2019-06-21 Thread maya
On Thu, May 30, 2019 at 05:33:57PM -0400, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Thu May 30 21:33:57 UTC 2019
> 
> Modified Files:
>   src/share/mk: bsd.own.mk
> 
> Log Message:
> Everyone is on gdb-8.3 now.

Please revert for mips. The debugger is extremely broken, and the old
version is slightly less broken.

gdb 8.3
"/mnt/sudo.core" is not a core dump: file format not recognized

gdb 8.0.1

# gdb -q /usr/pkg/bin/sudo /sudo.core
Reading symbols from /usr/pkg/bin/sudo...done.
[New process 1]
Core was generated by `sudo'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x78670744 in ?? () from /usr/pkg/lib/sudo/libsudo_util.so.0
(gdb) bt
#0  0x78670744 in ?? () from /usr/pkg/lib/sudo/libsudo_util.so.0
warning: GDB can't find the start of the function at 0x78662e57.

GDB is unable to find the start of the function at 0x78662e57
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x78662e57 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
#1  0x78662e58 in ?? () from /usr/pkg/lib/sudo/libsudo_util.so.0




Re: CVS commit: src/share/mk

2018-11-10 Thread Martin Husemann
On Sat, Nov 10, 2018 at 01:40:47AM +, Michael Lorenz wrote:
> Module Name:  src
> Committed By: macallan
> Date: Sat Nov 10 01:40:47 UTC 2018
> 
> Modified Files:
>   src/share/mk: bsd.own.mk
> 
> Log Message:
> more Xorg on iyonix building goop
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1078 -r1.1079 src/share/mk/bsd.own.mk

This part:

@@ -980,7 +980,7 @@
 # These platforms use softfloat by default.
 #
 .if ${MACHINE_ARCH} == "mips64eb" || ${MACHINE_ARCH} == "mips64el"
-MKSOFTFLOAT?=  yes
+MKSOFTFLOAT?=  no
 .endif
 
 #

is probably not intended and breaks the build for mips64eb.

Martin


Re: CVS commit: src/share/mk

2018-07-10 Thread Christos Zoulas
In article <20180710222851.ga5...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Tue, Jul 10, 2018 at 04:13:24PM -0400, Christos Zoulas wrote:
>> On Jul 10,  9:58pm, mar...@duskware.de (Martin Husemann) wrote:
>> -- Subject: Re: CVS commit: src/share/mk
>> 
>> | On Tue, Jul 10, 2018 at 08:31:16PM +0200, Joerg Sonnenberger wrote:
>> | > This is wrong. Please revert. The seed should be specific per source as
>> | > it is used to distinguish e.g. anonymous namespace mangling.
>> 
>> It is still specific per source since the ${.TARGET} contains the source
>> name (i.e. foo.c -> foo.o):
>
>So two .TARGET instances in different directories will get the same
>seed. Before, they would have most often be distinguished by the full
>(or relative) source path.

I guess that's true. I will revert it then...

christos



Re: CVS commit: src/share/mk

2018-07-10 Thread Joerg Sonnenberger
On Tue, Jul 10, 2018 at 04:13:24PM -0400, Christos Zoulas wrote:
> On Jul 10,  9:58pm, mar...@duskware.de (Martin Husemann) wrote:
> -- Subject: Re: CVS commit: src/share/mk
> 
> | On Tue, Jul 10, 2018 at 08:31:16PM +0200, Joerg Sonnenberger wrote:
> | > This is wrong. Please revert. The seed should be specific per source as
> | > it is used to distinguish e.g. anonymous namespace mangling.
> 
> It is still specific per source since the ${.TARGET} contains the source
> name (i.e. foo.c -> foo.o):

So two .TARGET instances in different directories will get the same
seed. Before, they would have most often be distinguished by the full
(or relative) source path.

Joerg


Re: CVS commit: src/share/mk

2018-07-10 Thread Christos Zoulas
On Jul 10,  9:58pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/share/mk

| On Tue, Jul 10, 2018 at 08:31:16PM +0200, Joerg Sonnenberger wrote:
| > This is wrong. Please revert. The seed should be specific per source as
| > it is used to distinguish e.g. anonymous namespace mangling.

It is still specific per source since the ${.TARGET} contains the source
name (i.e. foo.c -> foo.o):

__BUILDSEED=${BUILDSEED}/${__INITSEED}/${.TARGET} 

It does not contain *all* the sources like before, but one source should
be enough, or not?

| Can we just use the (normalized/sub-) path of the target object file?
| I don't understand why any source comes in here and obfuscates things.

Anyway, the fix to remove the files that contain relative paths should
make things deterministic again; I just wanted to make sure that they
were, and keeping this simple (using the timestamp) sounded like a good
idea (unless you need a better guarantee of uniqueness than the single
source name).

christos


Re: CVS commit: src/share/mk

2018-07-10 Thread Joerg Sonnenberger
On Tue, Jul 10, 2018 at 12:53:16PM -0400, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Tue Jul 10 16:53:16 UTC 2018
> 
> Modified Files:
>   src/share/mk: sys.mk
> 
> Log Message:
> Build seed fixes:
> - use MKREPRO_TIMESTAMP as the seed if available.
> - skip relative paths that cannot be normalized if it is not
> XXX: pullup-8

This is wrong. Please revert. The seed should be specific per source as
it is used to distinguish e.g. anonymous namespace mangling.

Joerg


Re: CVS commit: src/share/mk

2018-06-22 Thread maya
On Fri, Jun 22, 2018 at 12:37:34PM +1000, matthew green wrote:
> "Maya Rashish" writes:
> > Module Name:src
> > Committed By:   maya
> > Date:   Wed Jun 20 02:15:13 UTC 2018
> > 
> > Modified Files:
> > src/share/mk: sys.mk
> > 
> > Log Message:
> > Strip -Wsystem-headers from CXXFLAGS.
> > 
> > GCC's C++ headers are not clean (yet). They are trying, but haven't got 
> > there
> > yet.
> > 
> > Necessary for including  which uses .
> 
> can you add a comment about this?  the stripping is normally
> about stuff that c++ frontend does not support, vs stuff that
> breaks because of other issues.
> 
> ie, the rest of them should always stay, but this one will
> hopefully go away in the future.
> 
> thanks.

At least a few of them seem to be accepted by g++ and clang++:
  -ffreestanding  -Wno-format-zero-length


re: CVS commit: src/share/mk

2018-06-21 Thread matthew green
"Maya Rashish" writes:
> Module Name:  src
> Committed By: maya
> Date: Wed Jun 20 02:15:13 UTC 2018
> 
> Modified Files:
>   src/share/mk: sys.mk
> 
> Log Message:
> Strip -Wsystem-headers from CXXFLAGS.
> 
> GCC's C++ headers are not clean (yet). They are trying, but haven't got there
> yet.
> 
> Necessary for including  which uses .

can you add a comment about this?  the stripping is normally
about stuff that c++ frontend does not support, vs stuff that
breaks because of other issues.

ie, the rest of them should always stay, but this one will
hopefully go away in the future.

thanks.


.mrg.


Re: CVS commit: src/share/mk

2018-04-19 Thread Christos Zoulas
On Apr 19,  6:33am, m...@netbsd.org (m...@netbsd.org) wrote:
-- Subject: Re: CVS commit: src/share/mk

| On Sun, Apr 15, 2018 at 04:08:14PM -0400, Christos Zoulas wrote:
| > Module Name:src
| > Committed By:   christos
| > Date:   Sun Apr 15 20:08:13 UTC 2018
| > 
| > Modified Files:
| > src/share/mk: bsd.own.mk
| > 
| > Log Message:
| > switch x86 to binutils-2.30
| > 
| > 
| > To generate a diff of this commit:
| > cvs rdiff -u -r1.1056 -r1.1057 src/share/mk/bsd.own.mk
| 
| cd /usr/pkgsrc/lang/llvm; make install
| 
| [ 92%] Linking CXX executable ../../bin/llvm-as
| ld: BFD (NetBSD Binutils nb1) 2.30 assertion fail 
/current/src/external/gpl3/binutils/lib/libbfd/../../dist/bfd/elflink.c:2824

ouch, let's switch it back.

christos



Re: CVS commit: src/share/mk

2018-04-19 Thread maya
On Sun, Apr 15, 2018 at 04:08:14PM -0400, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Sun Apr 15 20:08:13 UTC 2018
> 
> Modified Files:
>   src/share/mk: bsd.own.mk
> 
> Log Message:
> switch x86 to binutils-2.30
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1056 -r1.1057 src/share/mk/bsd.own.mk

cd /usr/pkgsrc/lang/llvm; make install

[ 92%] Linking CXX executable ../../bin/llvm-as
ld: BFD (NetBSD Binutils nb1) 2.30 assertion fail 
/current/src/external/gpl3/binutils/lib/libbfd/../../dist/bfd/elflink.c:2824



re: CVS commit: src/share/mk

2018-03-05 Thread matthew green
Rin Okuyama writes:
> On 2018/03/05 16:46, matthew green wrote:
> > yes - it was alpha i switched, and while it worked a week
> > or two ago, it seems broken now.  argh.
> 
> Ah, I understand. Sorry for the noise.

no noise.  you let me know i had confused myself :-)

thanks.  arm and ia64 are now switched, leaving just
vax, m68k and sh3.


Re: CVS commit: src/share/mk

2018-03-04 Thread Rin Okuyama

On 2018/03/05 16:46, matthew green wrote:

yes - it was alpha i switched, and while it worked a week
or two ago, it seems broken now.  argh.


Ah, I understand. Sorry for the noise.

Thanks,
rin


re: CVS commit: src/share/mk

2018-03-04 Thread matthew green
Rin Okuyama writes:
> Hi,
> 
> On 2018/03/05 7:47, matthew green wrote:
> > Module Name:src
> > Committed By:   mrg
> > Date:   Sun Mar  4 22:47:49 UTC 2018
> > 
> > Modified Files:
> > src/share/mk: bsd.own.mk
> > 
> > Log Message:
> > switch powerpc, mips and arm ports to GCC 6.
> 
> arm was not switched actually.

yes - it was alpha i switched, and while it worked a week
or two ago, it seems broken now.  argh.

thanks.


.mrg.


Re: CVS commit: src/share/mk

2018-03-04 Thread Rin Okuyama

Hi,

On 2018/03/05 7:47, matthew green wrote:

Module Name:src
Committed By:   mrg
Date:   Sun Mar  4 22:47:49 UTC 2018

Modified Files:
src/share/mk: bsd.own.mk

Log Message:
switch powerpc, mips and arm ports to GCC 6.


arm was not switched actually.

rin


Re: CVS commit: src/share/mk

2017-02-20 Thread Joerg Sonnenberger
On Mon, Feb 20, 2017 at 04:05:34PM +, Rin Okuyama wrote:
> Module Name:  src
> Committed By: rin
> Date: Mon Feb 20 16:05:34 UTC 2017
> 
> Modified Files:
>   src/share/mk: bsd.prog.mk
> 
> Log Message:
> add missing LIBCXX

What is libcxx?

Joerg


Re: CVS commit: src/share/mk

2016-09-10 Thread Christos Zoulas
On Sep 10, 10:14pm, co...@sdf.org (co...@sdf.org) wrote:
-- Subject: Re: CVS commit: src/share/mk

| > a reduced case which shows the failure I had with pkgsrc (even with
| > gcc 4.8.5) is:
| >   awk 'BEGIN { print x++; }'
| > 
| > it prints 2.22507e-308 on gxemul-emulated pmax with gcc 4.8.5.
| > it might be a gxemul bug, too.
| > 
| > I didn't know all numbers in awk are doubles.
| 
| it's a gxemul bug (flxd doesn't see it on real hardware :) sorry for the
| noise.

NP, thanks for verifying.

christos


Re: CVS commit: src/share/mk

2016-09-10 Thread coypu
On Fri, Sep 09, 2016 at 09:26:40PM +, co...@sdf.org wrote:
> On Fri, Sep 09, 2016 at 04:02:18PM +, co...@sdf.org wrote:
> > On Thu, Sep 08, 2016 at 09:37:25PM -0400, Christos Zoulas wrote:
> > > On Sep 8,  8:40pm, co...@sdf.org (co...@sdf.org) wrote:
> > > -- Subject: Re: CVS commit: src/share/mk
> > > 
> > > | I think we need to revert this commit. I see issues with awk on pmax
> > > | too.
> > > | I don't have a nice hardfloat case like martin in PR 51026 but
> > > | attempting to build anything from pkgsrc will fail on checksum compare.
> > > 
> > > Can you make a unit test?
> > > 
> > > christos
> > 
> > Sorry, my problem seems unrelated. I just assumed because it's awk + bad
> > results. I'll try to dig more.
> 
> a reduced case which shows the failure I had with pkgsrc (even with
> gcc 4.8.5) is:
>   awk 'BEGIN { print x++; }'
> 
> it prints 2.22507e-308 on gxemul-emulated pmax with gcc 4.8.5.
> it might be a gxemul bug, too.
> 
> I didn't know all numbers in awk are doubles.

it's a gxemul bug (flxd doesn't see it on real hardware :) sorry for the
noise.


Re: CVS commit: src/share/mk

2016-09-09 Thread coypu
On Fri, Sep 09, 2016 at 04:02:18PM +, co...@sdf.org wrote:
> On Thu, Sep 08, 2016 at 09:37:25PM -0400, Christos Zoulas wrote:
> > On Sep 8,  8:40pm, co...@sdf.org (co...@sdf.org) wrote:
> > -- Subject: Re: CVS commit: src/share/mk
> > 
> > | I think we need to revert this commit. I see issues with awk on pmax
> > | too.
> > | I don't have a nice hardfloat case like martin in PR 51026 but
> > | attempting to build anything from pkgsrc will fail on checksum compare.
> > 
> > Can you make a unit test?
> > 
> > christos
> 
> Sorry, my problem seems unrelated. I just assumed because it's awk + bad
> results. I'll try to dig more.

a reduced case which shows the failure I had with pkgsrc (even with
gcc 4.8.5) is:
  awk 'BEGIN { print x++; }'

it prints 2.22507e-308 on gxemul-emulated pmax with gcc 4.8.5.
it might be a gxemul bug, too.

I didn't know all numbers in awk are doubles.


Re: CVS commit: src/share/mk

2016-09-08 Thread Christos Zoulas
On Sep 8,  8:40pm, co...@sdf.org (co...@sdf.org) wrote:
-- Subject: Re: CVS commit: src/share/mk

| I think we need to revert this commit. I see issues with awk on pmax
| too.
| I don't have a nice hardfloat case like martin in PR 51026 but
| attempting to build anything from pkgsrc will fail on checksum compare.

Can you make a unit test?

christos


Re: CVS commit: src/share/mk

2016-09-08 Thread coypu
I think we need to revert this commit. I see issues with awk on pmax
too.

I don't have a nice hardfloat case like martin in PR 51026 but
attempting to build anything from pkgsrc will fail on checksum compare.

On Sat, Sep 03, 2016 at 08:32:12AM -0400, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Sat Sep  3 12:32:12 UTC 2016
> 
> Modified Files:
>   src/share/mk: bsd.own.mk
> 
> Log Message:
> Switch mips32 to new binutils/gcc/gdb/pie. Tested with gxemul+pmax
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.950 -r1.951 src/share/mk/bsd.own.mk
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

> Modified files:
> 



Re: CVS commit: src/share/mk

2016-09-04 Thread Reinoud Zandijk
On Sun, Sep 04, 2016 at 06:57:40PM +, matthew green wrote:
...
> and considering riscv and or1k both need to either wait for GCC 6 or have
> someone who cares port their 5.x patches to our tree, that really only means
> we have mips and m68k left.

riscv is still a WIP in the current 5.x tree. I have no idea what needs to be
changed to get the latest patches in, better ask Matt (gimpy) about it.

Reinoud



re: CVS commit: src/share/mk

2016-09-01 Thread matthew green
> | > Modified Files:
> | >   src/share/mk: bsd.own.mk
> | > 
> | > Log Message:
> | > Turn on PIE for all arm and sh3
> | 
> | this breaks earmv4 builds.  the patch below "fixes" that for me.
> 
> I will take a look thanks!

this seems to have been the old binutils problem.  fixed now.

thanks.


.mrg.


re: CVS commit: src/share/mk

2016-08-30 Thread matthew green
Christos Zoulas writes:
> On Aug 30,  1:47pm, m...@eterna.com.au (matthew green) wrote:
> -- Subject: re: CVS commit: src/share/mk
> 
> | "Christos Zoulas" writes:
> | > Module Name:  src
> | > Committed By: christos
> | > Date: Sun Aug 28 14:22:35 UTC 2016
> | > 
> | > Modified Files:
> | >   src/share/mk: bsd.own.mk
> | > 
> | > Log Message:
> | > Turn on PIE for all arm and sh3
> | 
> | this breaks earmv4 builds.  the patch below "fixes" that for me.
> 
> I will take a look thanks!

thanks to you too :)


re: CVS commit: src/share/mk

2016-08-30 Thread Christos Zoulas
On Aug 30,  1:47pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/share/mk

| "Christos Zoulas" writes:
| > Module Name:src
| > Committed By:   christos
| > Date:   Sun Aug 28 14:22:35 UTC 2016
| > 
| > Modified Files:
| > src/share/mk: bsd.own.mk
| > 
| > Log Message:
| > Turn on PIE for all arm and sh3
| 
| this breaks earmv4 builds.  the patch below "fixes" that for me.

I will take a look thanks!

christos


re: CVS commit: src/share/mk

2016-08-29 Thread matthew green
"Christos Zoulas" writes:
> Module Name:  src
> Committed By: christos
> Date: Sun Aug 28 14:22:35 UTC 2016
> 
> Modified Files:
>   src/share/mk: bsd.own.mk
> 
> Log Message:
> Turn on PIE for all arm and sh3

this breaks earmv4 builds.  the patch below "fixes" that for me.


.mrg.


Index: bsd.own.mk
===
RCS file: /cvsroot/src/share/mk/bsd.own.mk,v
retrieving revision 1.948
diff -p -u -r1.948 bsd.own.mk
--- bsd.own.mk  28 Aug 2016 14:22:35 -  1.948
+++ bsd.own.mk  30 Aug 2016 03:46:51 -
@@ -1075,7 +1075,7 @@ MKCTF?=   yes
 #
 .if ${MACHINE_ARCH} == "i386" || \
 ${MACHINE_ARCH} == "x86_64" || \
-${MACHINE_CPU} == "arm" || \
+(${MACHINE_CPU} == "arm" && empty(MACHINE_ARCH:M*armv4*)) || \
 ${MACHINE_CPU} == "sh3" || \
 ${MACHINE} == "sparc64"
 MKPIE?=yes


re: CVS commit: src/share/mk

2016-02-01 Thread Christos Zoulas
On Feb 1, 11:45pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/share/mk

| I think you missed a change to bsd.README ;)

Fixed, thanks!

christos


re: CVS commit: src/share/mk

2016-01-12 Thread Christos Zoulas
On Jan 12,  5:06pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/share/mk

| > Modified Files:
| > src/share/mk: bsd.sys.mk
| > 
| > Log Message:
| > - use -fdebug-regex-map to remap one style of object dirs. There are others.
| > - change DESTDIR to nothing so that we don't get // in the front
| > - apply the mappings to both c and c++
| 
| for all the options like this that we (you've :-) added lately, can
| you please put them in their own variables that can be elided for
| the case we're not using the builtin compiler?  ie, all the recent
| things that break EXTERNAL_TOOLCHAIN.  :-)

They are all under MKREPRO. I don't expect that people will be testing
MKREPRO with EXTERNAL_TOOLCHAIN...

christos


re: CVS commit: src/share/mk

2016-01-11 Thread matthew green
> Modified Files:
>   src/share/mk: bsd.sys.mk
> 
> Log Message:
> - use -fdebug-regex-map to remap one style of object dirs. There are others.
> - change DESTDIR to nothing so that we don't get // in the front
> - apply the mappings to both c and c++

for all the options like this that we (you've :-) added lately, can
you please put them in their own variables that can be elided for
the case we're not using the builtin compiler?  ie, all the recent
things that break EXTERNAL_TOOLCHAIN.  :-)

thanks.


.mrg.


re: CVS commit: src/share/mk

2015-12-18 Thread Christos Zoulas
On Dec 19,  1:26pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/share/mk

| thanks for writing sortinfo!
| 
| can you apply this all the time?  i find it really frustrating
| when the top level file is unsorted and irregular.
| 

It is applied all the time now...

christos


re: CVS commit: src/share/mk

2015-12-18 Thread matthew green
"Christos Zoulas" writes:
> Module Name:  src
> Committed By: christos
> Date: Fri Dec 18 18:57:56 UTC 2015
> 
> Modified Files:
>   src/share/mk: bsd.info.mk bsd.own.mk
> 
> Log Message:
> Sort texinfo dir file for MKREPRO

thanks for writing sortinfo!

can you apply this all the time?  i find it really frustrating
when the top level file is unsorted and irregular.

thanks.


.mrg.


Re: CVS commit: src/share/mk

2015-09-08 Thread Joerg Sonnenberger
On Tue, Sep 08, 2015 at 01:14:59PM +0900, Masao Uebayashi wrote:
> On Tue, Sep 8, 2015 at 1:33 AM, Joerg Sonnenberger
>  wrote:
> > On Mon, Sep 07, 2015 at 06:42:07AM +, Masao Uebayashi wrote:
> >> Module Name:  src
> >> Committed By: uebayasi
> >> Date: Mon Sep  7 06:42:07 UTC 2015
> >>
> >> Modified Files:
> >>   src/share/mk: bsd.lib.mk
> >>
> >> Log Message:
> >> Order object build alphabetically.
> >
> > Given that we are still tsorting things: this change is wrong.
> 
> Could you elaborate more?  What I see is that, ${.ALLSRC:O} is
> lorder(1)'ed, and then tsort(1)'ed.

You have added additional work for nothing.

Joerg


Re: CVS commit: src/share/mk

2015-09-07 Thread Joerg Sonnenberger
On Mon, Sep 07, 2015 at 06:42:07AM +, Masao Uebayashi wrote:
> Module Name:  src
> Committed By: uebayasi
> Date: Mon Sep  7 06:42:07 UTC 2015
> 
> Modified Files:
>   src/share/mk: bsd.lib.mk
> 
> Log Message:
> Order object build alphabetically.

Given that we are still tsorting things: this change is wrong.

Joergr


Re: CVS commit: src/share/mk

2015-09-07 Thread Masao Uebayashi
On Tue, Sep 8, 2015 at 1:33 AM, Joerg Sonnenberger
 wrote:
> On Mon, Sep 07, 2015 at 06:42:07AM +, Masao Uebayashi wrote:
>> Module Name:  src
>> Committed By: uebayasi
>> Date: Mon Sep  7 06:42:07 UTC 2015
>>
>> Modified Files:
>>   src/share/mk: bsd.lib.mk
>>
>> Log Message:
>> Order object build alphabetically.
>
> Given that we are still tsorting things: this change is wrong.

Could you elaborate more?  What I see is that, ${.ALLSRC:O} is
lorder(1)'ed, and then tsort(1)'ed.


Re: CVS commit: src/share/mk

2015-07-20 Thread Joerg Sonnenberger
On Mon, Jul 20, 2015 at 02:25:33PM +0200, Thomas Klausner wrote:
 On Mon, Jul 20, 2015 at 12:20:27PM +, Joerg Sonnenberger wrote:
  Module Name:src
  Committed By:   joerg
  Date:   Mon Jul 20 12:20:26 UTC 2015
  
  Modified Files:
  src/share/mk: bsd.lib.mk
  
  Log Message:
  Simplify the build of library archives by no longer doing a topological
  sort.
 
 How does that affect MKREPRO=yes?

Clean build after the change will give consistent results, the files are
sorted (:O) explicitly.

Joerg


Re: CVS commit: src/share/mk

2015-07-20 Thread Thomas Klausner
On Mon, Jul 20, 2015 at 12:20:27PM +, Joerg Sonnenberger wrote:
 Module Name:  src
 Committed By: joerg
 Date: Mon Jul 20 12:20:26 UTC 2015
 
 Modified Files:
   src/share/mk: bsd.lib.mk
 
 Log Message:
 Simplify the build of library archives by no longer doing a topological
 sort.

How does that affect MKREPRO=yes?
 Thomas


Re: CVS commit: src/share/mk

2015-06-07 Thread Leonardo Taccari
Hello Matt,

Matt Thomas writes:
 Module Name:  src
 Committed By: matt
 Date: Sun Jun  7 15:04:28 UTC 2015
 
 Modified Files:
   src/share/mk: bsd.gcc.mk bsd.prog.mk
 
 Log Message:
 Make LIBCRT* depend on the right files if MLIBDIR from MKCOMPAT is defined.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.10 -r1.11 src/share/mk/bsd.gcc.mk
 cvs rdiff -u -r1.291 -r1.292 src/share/mk/bsd.prog.mk
 [...]
I think that these changes provoke the following failure
(NetBSD/amd64 7.99.18, using gcc in base):

 [...]
 nbmake[7]: nbmake[7]: don't know how to make 
/usr/src/obj/destdir.amd64/usr/lib/none/crti.o. Stop
 
 nbmake[7]: stopped in /usr/src/lib/libarch
 *** [dependall] Error code 2
 
 nbmake[6]: stopped in /usr/src/lib/libarch
 1 error
 
 nbmake[6]: stopped in /usr/src/lib/libarch
 *** Failed target:  dependall-libarch
 *** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift; 
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=lib/; 
real=/usr/src/lib ;; *) this=lib/${dir}/; real=/usr/src/lib/${dir} ;; 
esac; show=${this:-.}; echo ${target} === ${show%/}${1:+ (with: $@)}; cd 
${real}  /usr/src/obj/tooldir.NetBSD-7.99.18-amd64/bin/nbmake 
_THISDIR_=${this} $@ ${target}; }; _makedirtarget libarch dependall
 *** Error code 2
 Stop.
 [...]

I have changed them to the previous revisions and the build now seems
that proceed.
Can you give a look, please?


Thank you for your attention!
Ciao,
L.


re: CVS commit: src/share/mk

2015-06-02 Thread matthew green

Christos Zoulas writes:
 Module Name:  src
 Committed By: christos
 Date: Tue Jun  2 23:00:25 UTC 2015
 
 Modified Files:
   src/share/mk: bsd.lib.mk
 
 Log Message:
 Strip the debug symbols via a temporary file, atomically replacing the full
 random access archive to avoid races.

thanks for looking, but this doesn't really fix the problem.

the install target can still run before the .so is complete.  it's
just now that a file will always be there -- but it might be the
pre-stripped file now installed, as well as the debug info one.

i am testing a fix that merges the creation such that make won't
consider the .so up to date until after it's actually finished
creating it.


.mrg.


Re: CVS commit: src/share/mk

2014-11-12 Thread Masao Uebayashi
It'd be better to always generate kldscript and kill *.mk contionals completely.


Re: CVS commit: src/share/mk

2014-04-09 Thread Matt Thomas

On Apr 9, 2014, at 9:29 AM, Christos Zoulas chris...@netbsd.org wrote:

 Module Name:  src
 Committed By: christos
 Date: Wed Apr  9 16:29:08 UTC 2014
 
 Modified Files:
   src/share/mk: bsd.lib.mk
 
 Log Message:
 change -x to OBJCOPYLIBFLAGS like everywhere else.

Does that really fix it?  since .target is not a .po that should allow -x as 
well.

${${.TARGET:M*.po} != :?-X:-x}




Re: CVS commit: src/share/mk

2014-04-09 Thread Christos Zoulas
In article 8309261f-7d35-4be6-884a-bb10ec7ce...@3am-software.com,
Matt Thomas  m...@3am-software.com wrote:

Does that really fix it?  since .target is not a .po that should allow
-x as well.

${${.TARGET:M*.po} != :?-X:-x}

It does not change anything. It is the same as before. It just allows
OBJCOPYFLAGS to be overwritten for all targets.

christos



re: CVS commit: src/share/mk

2014-03-23 Thread matthew green

Matthias Scheler writes:
 Module Name:  src
 Committed By: tron
 Date: Sun Mar 23 19:49:52 UTC 2014
 
 Modified Files:
   src/share/mk: bsd.x11.mk
 
 Log Message:
 Fix generation of pkg-config(1) files. Patch from Ryo ONODERA via
 current-users mailing list.

thanks for fixing those.


.mrg.


re: CVS commit: src/share/mk

2014-02-28 Thread matthew green

 On Feb 27, 2014, at 12:43 PM, matthew green m...@netbsd.org wrote:
 
  remove the GCC 4 EXTERNAL_GCC_SUBDIR, and switch GCC 4.8 to use gcc.old.
 
 huh?

oh, the above should read GCC 4.5


Re: CVS commit: src/share/mk

2014-02-27 Thread Matt Thomas

On Feb 27, 2014, at 12:43 PM, matthew green m...@netbsd.org wrote:

 remove the GCC 4 EXTERNAL_GCC_SUBDIR, and switch GCC 4.8 to use gcc.old.

huh?


Re: CVS commit: src/share/mk

2014-02-20 Thread Matt Thomas

On Jan 23, 2014, at 8:53 PM, Masao Uebayashi uebay...@gmail.com wrote:

 How about kernel modules?

even kernel modules


Re: CVS commit: src/share/mk

2014-02-20 Thread David Laight
On Thu, Feb 20, 2014 at 01:30:27PM -0800, Matt Thomas wrote:
 
 On Jan 23, 2014, at 8:53 PM, Masao Uebayashi uebay...@gmail.com wrote:
 
  How about kernel modules?
 
 even kernel modules

Personally I think that DESTDIR should only contain the headers needed
for applications.
So some parts of sbin would only be buildable in a full source tree.
At the moment some headers seem to get released so that things
like libkvm (and other kernel grovellers) can be built.

If you look at the .d files for applcations you'll see that they end
up including all sorts of .h files that they really shouldn't need.

Separation in the kernel is even worse.

David

-- 
David Laight: da...@l8s.co.uk


  1   2   >