Re: CVS commit: src/share/mk
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
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
> 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
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
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: CVS commit: src/share/mk
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
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
> > 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
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
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
re: CVS commit: src/share/mk
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 >= &arr[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: CVS commit: src/share/mk
> 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
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
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
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
> > - 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
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
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
Am 28.06.2024 um 22:45 schrieb Taylor R Campbell:
> +# It is tempting to use the make :P modifier here so that you can just
> +# write
> +#
> +#VERSION_MAP=foo.map
> +#
> +# instead of
> +#
> +#VERSION_MAP=${.CURDIR}/foo.map
> +#
> +# but it appears that :P works _only_ with literal names, not with
> +# expansions, so while you could write
> +#
> +#VERSION_MAP=${foo.map:P}
> +#
> +# in the makefile, we can't set
> +#
> +#LDFLAGS+= -Wl,--version-script=${${VERSION_MAP}:P}
> +#
> +# here.
The ':P' modifier treats a literal in the same way as an expression, so
there's no difference between ${foo.map:P} and ${${:Ufoo.map}:P}, as in
both cases the "variable name" is 'foo.map'. If you still remember how
you came to that conclusion, I'd be interested in it.
In order to make the ':P' modifier work, the "variable name" must be an
existing node in the dependency tree, at the point where the ':P'
modifier is evaluated.
Here's a demonstration:
> .MAKEFLAGS: -dv
> .PATH: /dev
> VERSION_MAP= null
> Resolve_via_Path: .PHONY .NOTMAIN ${VERSION_MAP}
> LDFLAGS+= -Wl,--version-script=${${VERSION_MAP}:P}
> LDFLAGS+= -Wl,--version-script=${null:P}
> .info ${LDFLAGS}
> .MAKEFLAGS: -dF/dev/null
> all:
The 'Resolve_via_Path' dependency line adds the VERSION_MAP file to the
dependency tree. Instead of 'Resolve_via_Path', you can choose any other
name or even leave it empty, making the line start with a "magic colon".
Roland
Re: CVS commit: src/share/mk
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
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
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
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
On Saturday 19 September 2009 15:53:13 Nick Hudson wrote: > Module Name: src > Committed By: skrll > Date: Sat Sep 19 14:53:13 UTC 2009 > > Modified Files: > src/share/mk: bsd.own.mk > > Log Message: > Switch vax to binutils 2.19. Thanks to martin@ for testing. Nick
Re: CVS commit: src/share/mk
On Sun, Nov 29, 2009 at 04:00:00PM +, Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Sun Nov 29 16:00:00 UTC 2009
>
> Modified Files:
> src/share/mk: bsd.subdir.mk
>
> Log Message:
> Remove an unneeded test (.if defined(V)) in .for v in ${V} ... .endfor.
> Tested by running build.sh distribution.
Some versions of make error ${V} when V is undefined.
Safer is ${V:U}
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src/share/mk
On Sun, Nov 29, 2009 at 06:43:10PM +, David Laight wrote:
> > Modified Files:
> >src/share/mk: bsd.subdir.mk
> >
> > Log Message:
> > Remove an unneeded test (.if defined(V)) in .for v in ${V} ... .endfor.
> > Tested by running build.sh distribution.
>
> Some versions of make error ${V} when V is undefined.
> Safer is ${V:U}
...versions of *our* make?
--
David A. Holland
dholl...@netbsd.org
Re: CVS commit: src/share/mk
On Fri, Dec 04, 2009 at 12:57:55AM +0900, Masao Uebayashi wrote: > > I'm sorry but I don't think this is a good solution. > > What is your better solution? I can see why "_MKVARS" would be nice. But why do we need "_MKVARS.yes" and "_MKVARS.no"? Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/share/mk
Maybe this is simpler:
sidebeach% nbmake-i386 -V MKZFS
yes
sidebeach% nbmake-i386 -V MKZFS MKZFS=no
no
sidebeach% nbmake-shark -V MKZFS
no
sidebeach% nbmake-shark -V MKZFS MKZFS=yes
yes
Masao
Index: share/mk/bsd.own.mk
===
RCS file: /cvsroot/src/share/mk/bsd.own.mk,v
retrieving revision 1.601
diff -u -r1.601 bsd.own.mk
--- share/mk/bsd.own.mk 3 Dec 2009 15:57:18 - 1.601
+++ share/mk/bsd.own.mk 4 Dec 2009 03:41:12 -
@@ -663,6 +663,13 @@
.endif
#
+# We want to build zfs only for i386 and amd64 by default for now.
+#
+.if ${MACHINE} == "amd64" || ${MACHINE} == "i386"
+MKZFS?=yes
+.endif
+
+#
# MK* options which default to "yes".
#
_MKVARS.yes= \
@@ -699,7 +706,7 @@
MKMANDOC MKMANZ MKOBJDIRS \
MKPCC MKPCCCMDS \
MKSOFTFLOAT MKSTRIPIDENT \
- MKUNPRIVED MKUPDATE MKX11
+ MKUNPRIVED MKUPDATE MKX11 MKZFS
.for var in ${_MKVARS.no}
${var}?=no
.endfor
@@ -721,17 +728,6 @@
.endif
#
-# We want to build zfs only for i386 and amd64 by default for now.
-#
-.if ${MACHINE} == "amd64" || ${MACHINE} == "i386"
-MKZFS?=yes
-_MKVARS.yes+= MKZFS
-.else
-MKZFS?=no
-_MKVARS.no+= MKZFS
-.endif
-
-#
# Force some options off if their dependencies are off.
#
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/share/mk
On Fri, Dec 04, 2009 at 12:45:22PM +0900, Masao Uebayashi wrote: > Maybe this is simpler: > > sidebeach% nbmake-i386 -V MKZFS > yes > sidebeach% nbmake-i386 -V MKZFS MKZFS=no > no > sidebeach% nbmake-shark -V MKZFS > no > sidebeach% nbmake-shark -V MKZFS MKZFS=yes > yes Yes, indeed. But this will only work if "sets.subr" actually checks for this variable, won't it? Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/share/mk
> Yes, indeed. But this will only work if "sets.subr" actually
> checks for this variable, won't it?
Yes.
sets.subr fetches ${_MKVARS.yes} and ${_MKVARS.no} var names:
=> MKZFS is in ${_MKVARS.no}
sets.subr agains fetches all values for all var names:
=> MKZFS=${MKZFS}
Am I missing anything else?
Masao
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/share/mk
On Dec,Friday 4 2009, at 6:13 AM, Masao Uebayashi wrote:
>> Yes, indeed. But this will only work if "sets.subr" actually
>> checks for this variable, won't it?
>
> Yes.
>
> sets.subr fetches ${_MKVARS.yes} and ${_MKVARS.no} var names:
> => MKZFS is in ${_MKVARS.no}
>
> sets.subr agains fetches all values for all var names:
> => MKZFS=${MKZFS}
>
> Am I missing anything else?
MKZFS should be enabled by default on i386 + amd64. Can anyone explain to me
what are you doing here with _MKVARS ?
Regards
Adam.
Re: CVS commit: src/share/mk
On Tue, Dec 08, 2009 at 03:18:42PM +, Masao Uebayashi wrote:
>
> OTOH you can't pass parameters to ${CC}, because in suffix rules make(1) only
> knows the name of ${.IMPSRC} and ${.TARGET}
Actually it would do no harm for bsd.prog.mk (IIRC) to define an
explicit dependency when it generates ${OBJS} from ${SRCS}.
Make will use the rules from the appropriate suffix rule, but
it will force the specific dependency.
So if SRCS contains foo.c the will be built, even if there is a foo.S
David
--
David Laight: da...@l8s.co.uk
re: CVS commit: src/share/mk
Module Name: src
Committed By:uebayasi
Date:Tue Dec 8 15:18:42 UTC 2009
Modified Files:
src/share/mk: bsd.lib.mk bsd.prog.mk
Log Message:
When PROGS / LIBS are used, you can pass each PROG / LIB specific parameters
to ${LD} via:
${_LDADD.${PROG}}
${_LDFLAGS.${PROG}}
${_LDSTATIC.${PROG}}
${_LDADD.${LIB}}
${_LDFLAGS.${LIB}}
OTOH you can't pass parameters to ${CC}, because in suffix rules make(1) only
knows the name of ${.IMPSRC} and ${.TARGET}; it's users' responsivility to
define ${CC} parameters to all the sources of a given ${PROG} / ${LIB}.
why are these in the _ namespace? are they not supposed to be
used by end-user Makefiles?
.mrg.
Re: CVS commit: src/share/mk
> > OTOH you can't pass parameters to ${CC}, because in suffix rules make(1)
> > only
> > knows the name of ${.IMPSRC} and ${.TARGET}
>
> Actually it would do no harm for bsd.prog.mk (IIRC) to define an
> explicit dependency when it generates ${OBJS} from ${SRCS}.
> Make will use the rules from the appropriate suffix rule, but
> it will force the specific dependency.
>
> So if SRCS contains foo.c the will be built, even if there is a foo.S
I was unclear; I meant "you can't pass per-target (${PROG} / ${LIB}) parameters
to ${CC} directly".
And yes, it's actually possible to append ${CPPFLAGS.foo} to
${CPPFLAGS.foo_src_a.c}, ${CPPFLAGS.foo_src_b.c}, ... by using .for. I don't
think that is worth bothering. I can also think of odd situations where you
share one source among multiple targets:
PROGS=foo bar
SRCS.foo=foo.c common.c
SRCS.bar=bar.c common.c
CPPFLAGS.foo=-Dfoo
CPPFLAGS.bar=-Dbar
Think how common.o will be built...
Masao
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/share/mk
> ${_LDADD.${PROG}}
> ${_LDFLAGS.${PROG}}
> ${_LDSTATIC.${PROG}}
> ${_LDADD.${LIB}}
> ${_LDFLAGS.${LIB}}
>
>OTOH you can't pass parameters to ${CC}, because in suffix rules make(1)
> only
>knows the name of ${.IMPSRC} and ${.TARGET}; it's users' responsivility to
>define ${CC} parameters to all the sources of a given ${PROG} / ${LIB}.
>
>
> why are these in the _ namespace? are they not supposed to be
> used by end-user Makefiles?
Oops. I meant ${LDADD.${PROG}} etc. (no _ prefix). The _ prefix ones are
only used internally in bsd.{prog,lib}.mk. I'll fix the cvs log. Thanks.
Masao
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/share/mk
On Fri, Dec 04, 2009 at 11:21:07AM +, Adam Hamsik wrote: > Module Name: src > Committed By: haad > Date: Fri Dec 4 11:21:07 UTC 2009 > > Modified Files: > src/share/mk: bsd.own.mk > > Log Message: > Switch MKLVM to default value to yes. There are only few bits missing and it > would be great if it can receive more testing. > > Oked: core@, yamt@ > > > To generate a diff of this commit: > cvs rdiff -u -r1.601 -r1.602 src/share/mk/bsd.own.mk BTW: could you please also add "pseudo-device dm" to "GENERIC", etc.? It should probably be added to all kernel configuration which use "pseudo-device raid". Kind regards -- Matthias Scheler http://zhadum.org.uk/
re: CVS commit: src/share/mk
Module Name: src
Committed By:uebayasi
Date:Fri Dec 11 08:37:34 UTC 2009
Modified Files:
src/share/mk: bsd.own.mk
Log Message:
${GENCMD} is used to generate only one output from file generation commands
which potentially have multiple output files, which confuses make(1).
This wrapper copies all involved files into /tmp, execute the command, and
copy the wanted file back to ${.OBJDIR}. If this is expensive, consider to
rewrite the generation command to output files individually.
this seems pretty gross. i'm not sure it's a good way to
solve the problem at hand. it hides everything away with
@. it also doesn't appear to avoid updating a file if it
hasn't actually changed. it also hard codes /tmp, which
it shouldn't need to use at all. it also uses "cp"
instead of "mv".
did anyone review this?
.mrg.
Re: CVS commit: src/share/mk
> this seems pretty gross. i'm not sure it's a good way to > solve the problem at hand. it hides everything away with > @. it also doesn't appear to avoid updating a file if it > hasn't actually changed. it also hard codes /tmp, which > it shouldn't need to use at all. it also uses "cp" > instead of "mv". Could you give me a test case this fails? I'm all for better solution. Masao -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/share/mk
In article <26371.1260567...@splode.eterna.com.au>,
matthew green wrote:
>
> Module Name:src
> Committed By: uebayasi
> Date: Fri Dec 11 08:37:34 UTC 2009
>
> Modified Files:
> src/share/mk: bsd.own.mk
>
> Log Message:
> ${GENCMD} is used to generate only one output from file generation commands
> which potentially have multiple output files, which confuses make(1).
>
> This wrapper copies all involved files into /tmp, execute the command, and
> copy the wanted file back to ${.OBJDIR}. If this is expensive, consider to
> rewrite the generation command to output files individually.
>
>
>this seems pretty gross. i'm not sure it's a good way to
>solve the problem at hand. it hides everything away with
>@. it also doesn't appear to avoid updating a file if it
>hasn't actually changed. it also hard codes /tmp, which
>it shouldn't need to use at all. it also uses "cp"
>instead of "mv".
>
>did anyone review this?
I think this should be backed out; there must be better ways of dealing
with the problem.
christos
re: CVS commit: src/share/mk
In article <26371.1260567...@splode.eterna.com.au>,
matthew green wrote:
>
> Module Name: src
> Committed By:uebayasi
> Date:Fri Dec 11 08:37:34 UTC 2009
>
> Modified Files:
>src/share/mk: bsd.own.mk
>
> Log Message:
> ${GENCMD} is used to generate only one output from file generation
commands
> which potentially have multiple output files, which confuses make(1).
>
> This wrapper copies all involved files into /tmp, execute the command,
and
> copy the wanted file back to ${.OBJDIR}. If this is expensive, consider
to
> rewrite the generation command to output files individually.
>
>
>this seems pretty gross. i'm not sure it's a good way to
>solve the problem at hand. it hides everything away with
>@. it also doesn't appear to avoid updating a file if it
>hasn't actually changed. it also hard codes /tmp, which
>it shouldn't need to use at all. it also uses "cp"
>instead of "mv".
>
>did anyone review this?
I think this should be backed out; there must be better ways of dealing
with the problem.
i agree. the problem at hand is not new and there are much better
workarounds than this..
.mrg.
Re: CVS commit: src/share/mk
I had a discussion with dsl@ on source-change...@.
http://mail-index.netbsd.org/source-changes-d/2009/12/08/msg001261.html
His suggestion was:
arith.h: arith.y
arith.o: arith.h
[ -f ${@:.o=c} ] || { rm ${@:.o=.h}; exit 1; }
ie having no real dependency against arith.c
I showd my idea to make commands to generate only one output. I got no
response. I took that as no one has interest about this. GENCMD is just
one way to achieve that. You can do it in $YOUR_OWN_WAY but the idea is
that.
Masao
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/share/mk
On Dec 12, 11:48am, uebay...@tombi.co.jp (Masao Uebayashi) wrote:
-- Subject: Re: CVS commit: src/share/mk
| I had a discussion with dsl@ on source-change...@.
|
| http://mail-index.netbsd.org/source-changes-d/2009/12/08/msg001261.html
|
| His suggestion was:
| arith.h: arith.y
|
|
| arith.o: arith.h
| [ -f ${@:.o=c} ] || { rm ${@:.o=.h}; exit 1; }
|
|
| ie having no real dependency against arith.c
|
| I showd my idea to make commands to generate only one output. I got no
| response. I took that as no one has interest about this. GENCMD is just
| one way to achieve that. You can do it in $YOUR_OWN_WAY but the idea is
| that.
Actually I am interested. You just did not present your solution in
tech-whatever so I did not have a chance to comment. Do you have an
example where the existing rules fail, so that I can see what you are
trying to fix?
christos
Re: CVS commit: src/share/mk
On Mon, Dec 13, 2010 at 05:22:26PM +, Antti Kantee wrote:
> Module Name: src
> Committed By: pooka
> Date: Mon Dec 13 17:22:26 UTC 2010
>
> Modified Files:
> src/share/mk: bsd.own.mk bsd.prog.mk
>
> Log Message:
> Define RUMPPRG, which is just like PROG, except it additionally
> builds a rump client with the name rump.${PROG}. The rump client
> is not installed suid/sgid by default even if BINMODE is defined.
Where was this discussed? Why are you renaming a variable that has
existed for ages to get it to work for your own purpose? Can't you get
the same behavior by adding a WANT_RUMP=yes flag in the Makefiles?
Joerg
Re: CVS commit: src/share/mk
On Tue Dec 14 2010 at 01:52:50 +0100, Joerg Sonnenberger wrote:
> On Mon, Dec 13, 2010 at 05:22:26PM +, Antti Kantee wrote:
> > Module Name:src
> > Committed By: pooka
> > Date: Mon Dec 13 17:22:26 UTC 2010
> >
> > Modified Files:
> > src/share/mk: bsd.own.mk bsd.prog.mk
> >
> > Log Message:
> > Define RUMPPRG, which is just like PROG, except it additionally
> > builds a rump client with the name rump.${PROG}. The rump client
> > is not installed suid/sgid by default even if BINMODE is defined.
>
> Where was this discussed? Why are you renaming a variable that has
> existed for ages to get it to work for your own purpose? Can't you get
> the same behavior by adding a WANT_RUMP=yes flag in the Makefiles?
I've received multiple proposals on how the variable should be used,
all different.
--
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/share/mk
On Sun, Jan 16, 2011 at 07:30:00PM +, Joerg Sonnenberger wrote: > Modified Files: > src/share/mk: sys.mk > > Log Message: > Alpha doesn't need -traditional-cpp for assembler. Shouldn't that logic be in bsd.own.mk and not sys.mk? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/share/mk
On Mon, Jan 17, 2011 at 05:11:13AM +, David Holland wrote: > On Sun, Jan 16, 2011 at 07:30:00PM +, Joerg Sonnenberger wrote: > > Modified Files: > >src/share/mk: sys.mk > > > > Log Message: > > Alpha doesn't need -traditional-cpp for assembler. > > Shouldn't that logic be in bsd.own.mk and not sys.mk? The .S rules are in sys.mk and it is supposed to be self-contained. bsd.dep.mk reuses the variable. Joerg
Re: CVS commit: src/share/mk
On Sat, Feb 12, 2011 at 07:42:46PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Feb 13 00:42:45 UTC 2011 > > Modified Files: > src/share/mk: bsd.prog.mk > > Log Message: > add saslc Thanks for looking after libsaslc, and the integration with postfix. This is neat stuff, and this mail is not meant to detract from all the hard work that anon, mateusz and yourself have put in on this, and is no criticism of saslc, but... I've been left wondering about POLA, and why we're adding LIB* definitions to bsd.prog.mk - it doesn't seem the right *.mk file for a start, and it also puts knowledge of libraries into a file that should be generic. Is there a better way that we can accomplish this? Regards, Alistair
Re: CVS commit: src/share/mk
On Sun, Feb 13, 2011 at 08:38:06AM +0100, Alistair Crooks wrote: > > Modified Files: > >src/share/mk: bsd.prog.mk > > > > Log Message: > > add saslc > > [...] > > I've been left wondering about POLA, and why we're adding LIB* > definitions to bsd.prog.mk - it doesn't seem the right *.mk file for a > start, and it also puts knowledge of libraries into a file that should > be generic. It looks like it's a list of libraries that exist and that this is how programs get linked against those libraries. It's not clear to me (given a casual inspection) why bsd.lib.mk doesn't need the same logic for libraries that are linked to other libraries, but it apparently doesn't. > Is there a better way that we can accomplish this? Probably. It looks like someone needs to take a machete to the make library :-/ -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/share/mk
On Mon, Jan 17, 2011 at 12:50:04PM +0100, Joerg Sonnenberger wrote: > > > Modified Files: > > > src/share/mk: sys.mk > > > > > > Log Message: > > > Alpha doesn't need -traditional-cpp for assembler. > > > > Shouldn't that logic be in bsd.own.mk and not sys.mk? > > The .S rules are in sys.mk and it is supposed to be self-contained. > bsd.dep.mk reuses the variable. The reason sys.mk is supposed to be self-contained is that it's always included by make; that is, it's not part of the NetBSD build system and is exposed to every program you build anywhere. bsd.own.mk, by contrast, is part of the NetBSD build system. Definitions that are applicable only to building NetBSD should be in bsd.own.mk, not sys.mk, and this I think is one of those. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/share/mk
On Mon, Mar 07, 2011 at 07:05:04PM +, Julio Merino wrote:
> Module Name: src
> Committed By: jmmv
> Date: Mon Mar 7 19:05:04 UTC 2011
>
> Modified Files:
> src/share/mk: bsd.prog.mk
>
> Log Message:
> Always convert PROG to its plural form independently of whether PROG_CXX
> is defined or not. From Garrett Cooper in private mail.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.260 -r1.261 src/share/mk/bsd.prog.mk
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
> Modified files:
>
> Index: src/share/mk/bsd.prog.mk
> diff -u src/share/mk/bsd.prog.mk:1.260 src/share/mk/bsd.prog.mk:1.261
> --- src/share/mk/bsd.prog.mk:1.260Sun Feb 20 20:16:01 2011
> +++ src/share/mk/bsd.prog.mk Mon Mar 7 19:05:03 2011
> @@ -1,4 +1,4 @@
> -#$NetBSD: bsd.prog.mk,v 1.260 2011/02/20 20:16:01 jmmv Exp $
> +#$NetBSD: bsd.prog.mk,v 1.261 2011/03/07 19:05:03 jmmv Exp $
> #@(#)bsd.prog.mk 8.2 (Berkeley) 4/2/94
>
> .ifndef HOSTPROG
> @@ -262,7 +262,8 @@
> .if !defined(RUMPPRG)
> . if defined(PROG_CXX) && !defined(PROGS_CXX)
> PROGS_CXX= ${PROG_CXX}
> -. elif defined(PROG) && !defined(PROGS)
> +. endif
> +. if defined(PROG) && !defined(PROGS)
> PROGS= ${PROG}
> . endif
> .endif
>
Now if PROG_CXX is defined, both PROGS and PROGS_CXX refer to
PROG_CXX. Thus the ".for _P in ${PROGS} ${PROGS_CXX}" loop runs
twice.
Re: CVS commit: src/share/mk
On 10.04.11 23:03, Joerg Sonnenberger wrote:
> Module Name: src
> Committed By: joerg
> Date: Sun Apr 10 21:03:17 UTC 2011
>
> Modified Files:
> src/share/mk: bsd.own.mk
>
> Log Message:
> Use ?: operator to determine when to add --sysroot. Unbreaks clang
> bootstrap.
>
[...]
>
> -CPPFLAGS+= ${HOSTPROG:U${HOSTLIB:U${DESTDIR:D--sysroot=${DESTDIR
> -LDFLAGS+=${HOSTPROG:U${HOSTLIB:U${DESTDIR:D--sysroot=${DESTDIR
> +CPPFLAGS+= ${!defined(HOSTPROG) && !defined(HOSTLIB) && defined(DESTDIR)
> :? --sysroot=${DESTDIR} :}
> +LDFLAGS+=${!defined(HOSTPROG) && !defined(HOSTLIB) && defined(DESTDIR)
> :? --sysroot=${DESTDIR} :}
> .endif # EXTERNAL_TOOLCHAIN
> # }
:? == ?: operator?
Christoph
Re: CVS commit: src/share/mk
On Sun, Apr 10, 2011 at 11:25:50PM +0200, Christoph Egger wrote:
> > [...] ${[...foo...] :? --sysroot=${DESTDIR} :}
^ ^
> :? == ?: operator?
no, see above.
--
David A. Holland
dholl...@netbsd.org
re: CVS commit: src/share/mk
> Module Name: src > Committed By: tron > Date: Sun Apr 17 12:54:23 UTC 2011 > > Modified Files: > src/share/mk: bsd.own.mk > > Log Message: > Don't use "--sysroot=/" for host builds as "nbhost-mkdep" doesn't > understand that option. This should unbreak tool builds. hmm, i haven't seen this problem. what failed for you? are you sure it was a completely clean build? we should fix nbhost-mkdep if it is broken, and revert this change. .mrg.
Re: CVS commit: src/share/mk
On Sun, Apr 17, 2011 at 11:34:26PM +1000, matthew green wrote: > > Log Message: > > Don't use "--sysroot=/" for host builds as "nbhost-mkdep" doesn't > > understand that option. This should unbreak tool builds. > > hmm, i haven't seen this problem. what failed for you? "./build -O /path/to/obj -u -U -j 8 -x distribution sets" under NetBSD/i386 5.99.49 > are you sure it was a completely clean build? Yes, tool and object directory were empty. > we should fix nbhost-mkdep if it is broken, and revert this change. Please go ahead. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/share/mk
On Sun, Apr 17, 2011 at 11:03:37AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun Apr 17 15:03:37 UTC 2011
>
> Modified Files:
> src/share/mk: bsd.own.mk
>
> Log Message:
> Revert previous, breaks builds completely (cd /usr/src/bin/test && make clean
> &&
> make)
You have now broken the "tools" build again:
===> build.sh command:./build.sh -O /export/scratch/tron/obj -u -U -x tools
===> build.sh started:Sun Apr 17 18:52:12 BST 2011
===> NetBSD version: 5.99.49
===> MACHINE: i386
===> MACHINE_ARCH:i386
===> Build platform: NetBSD 5.99.49 i386
===> HOST_SH: /bin/sh
===> No $TOOLDIR/bin/nbmake, needs building.
===> Bootstrapping nbmake
[...]
#create libelf/elf_begin.d
/src/tools/bin/nbhost-mkdep -f elf_begin.d -- --sysroot=/
-I/src/NetBSD-current/src/tools/libelf/../compat
-I/src/NetBSD-current/src/tools/libelf/../../external/bsd/libelf/dist
-I/src/tools/include/nbinclude -DLIBELF_TEST_HOOKS -DHAVE_NBTOOL_CONFIG_H=1
-D_FILE_OFFSET_BITS=64 -I/export/scratch/tron/obj/tools/compat
-I/src/tools/include
/src/NetBSD-current/src/tools/libelf/../../external/bsd/libelf/dist/elf_begin.c
/src/tools/bin/nbhost-mkdep: Unknown option: --sysroot=/
*** Failed target: elf_begin.d
*** Failed command: /src/tools/bin/nbhost-mkdep -f elf_begin.d -- --sysroot=/
-I/src/NetBSD-current/src/tools/libelf/../compat
-I/src/NetBSD-current/src/tools/libelf/../../external/bsd/libelf/dist
-I/src/tools/include/nbinclude -DLIBELF_TEST_HOOKS -DHAVE_NBTOOL_CONFIG_H=1
-D_FILE_OFFSET_BITS=64 -I/export/scratch/tron/obj/tools/compat
-I/src/tools/include
/src/NetBSD-current/src/tools/libelf/../../external/bsd/libelf/dist/elf_begin.c
*** Error code 1
Stop.
nbmake: stopped in /src/NetBSD-current/src/tools/libelf
*** Failed target: dependall-libelf
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift;
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/src/NetBSD-current/src/tools" ;; *) this="${dir}/";
real="/src/NetBSD-current/src/tools/${dir}" ;; esac; show=${this:-.}; echo
"${target} ===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/src/tools/bin/nbmake _THISDIR_="${this}" "$@" ${target}; }; _makedirtarget
libelf dependall
*** Error code 1
Stop.
nbmake: stopped in /src/NetBSD-current/src/tools
ERROR: Failed to make dependall in "tools"
*** BUILD ABORTED ***
Can you please fix that?
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/share/mk
On Sun, Apr 17, 2011 at 07:04:05PM +0100, Matthias Scheler wrote: > You have now broken the "tools" build again: > > ===> build.sh command:./build.sh -O /export/scratch/tron/obj -u -U -x > tools [...] Some testing revealed that this only happens if you "MKDTRACE" is set to "yes". So please try this command line: ./build.sh -V MKDTRACE=yes -O /where/ever/obj -u -U -x tools Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/share/mk
On Apr 17, 7:04pm, t...@zhadum.org.uk (Matthias Scheler) wrote: -- Subject: Re: CVS commit: src/share/mk | Can you please fix that? I made mkdep understand --sysroot but ignore it. christos
Re: CVS commit: src/share/mk
On Apr 17, 9:55pm, t...@zhadum.org.uk (Matthias Scheler) wrote: -- Subject: Re: CVS commit: src/share/mk | On Sun, Apr 17, 2011 at 07:04:05PM +0100, Matthias Scheler wrote: | > You have now broken the "tools" build again: | > | > ===> build.sh command:./build.sh -O /export/scratch/tron/obj -u -U -x tools | [...] | | Some testing revealed that this only happens if you "MKDTRACE" is | set to "yes". So please try this command line: | | ./build.sh -V MKDTRACE=yes -O /where/ever/obj -u -U -x tools This would suggest that the dtrace makefiles are broken... christos
Re: CVS commit: src/share/mk
On Sat, Apr 16, 2011 at 05:41:25PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat Apr 16 21:41:25 UTC 2011 > > Modified Files: > src/share/mk: bsd.own.mk > > Log Message: > Simplify and correct (previous did not work for !defined(DESTDIR) You are doing tool builds without DESTDIR? Joerg
Re: CVS commit: src/share/mk
On Sat, Apr 16, 2011 at 06:45:23PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sat Apr 16 22:45:23 UTC 2011 > > Modified Files: > src/share/mk: bsd.own.mk > > Log Message: > Need --sysroot=/ otherwise ld does not find crt0.o and friends. What exactly are you doing? This sounds very, very wrong. Joerg
Re: CVS commit: src/share/mk
Please back this out. I have a proper patch for this on tech-toolchain. Joerg On Wed, May 18, 2011 at 01:08:15PM +, Adam Ciarcinski wrote: > Module Name: src > Committed By: adam > Date: Wed May 18 13:08:14 UTC 2011 > > Modified Files: > src/share/mk: bsd.own.mk > > Log Message: > Add support for LLVM/Clang > > > To generate a diff of this commit: > cvs rdiff -u -r1.664 -r1.665 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. >
Re: CVS commit: src/share/mk
Done. Please, commit your patch, or I won't be able to enjoy Clang. ;) Cheers, Adam > Please back this out. I have a proper patch for this on tech-toolchain. > > Joerg > > On Wed, May 18, 2011 at 01:08:15PM +, Adam Ciarcinski wrote: >> Module Name: src >> Committed By:adam >> Date:Wed May 18 13:08:14 UTC 2011 >> >> Modified Files: >> src/share/mk: bsd.own.mk >> >> Log Message: >> Add support for LLVM/Clang >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.664 -r1.665 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. >>
Re: CVS commit: src/share/mk
On Sun, 11 Sep 2011, Marc Balmer wrote: Log Message: Install new shiny bsd.clean.mk Thanks. I updated the set lists. --apb (Alan Barrett)
Re: CVS commit: src/share/mk
On Sun, 16 Oct 2011, Marc Balmer wrote: > Modified Files: > src/share/mk: bsd.lua.mk > > Log Message: > Uncomment LUA_DPLIBS processing, but do not auto-include liblua.so, > under the assumption that programs that load Lua modules already have > loaded it. Regarding this (which I have discussed with Marc off-list previously), I think a Lua module should always depend on liblua.so as there will be calls to functions from there, though I guess Marc is correct that the binary loading the module should have been linked with it anyway. So, is this enough? What if the binary is statically linked with the Lua interpreter, or if it was linked against a different version of lualib.so? Do the symbols in the loaded module get resolved correctly? This comes up really because Marc found it a problem to actually build the modules, as the dependency is taken from the OBJDIR, not the DESTDIR (I took this concept from bsd.lib.mk, it is the same there), so just building a module (or a library, see eg libmenu) means you must build the dependencies first rather than being able to use the host (DESTDIR) versions.. iain
Re: CVS commit: src/share/mk
On Mon, Oct 17, 2011 at 07:07:08PM +0100, Iain Hibbert wrote: > Regarding this (which I have discussed with Marc off-list previously), I > think a Lua module should always depend on liblua.so as there will be > calls to functions from there, though I guess Marc is correct that the > binary loading the module should have been linked with it anyway. It can make a difference in the order libraries are scanned. As such, explicitly linking is going to be faster and more robust. Joerg
Re: CVS commit: src/share/mk
On Fri, Aug 10, 2012 at 04:34:23PM +, Joerg Sonnenberger wrote: > Modified Files: > src/share/mk: bsd.kmodule.mk > > Log Message: > Remove effectively tautological condition. I object to this sort of change. There are a number of other compilers we might want to try sometime; all you're doing is adding to the amount of work that takes. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/share/mk
On Mon, Aug 13, 2012 at 08:55:33PM +, David Holland wrote: > On Fri, Aug 10, 2012 at 04:34:23PM +, Joerg Sonnenberger wrote: > > Modified Files: > >src/share/mk: bsd.kmodule.mk > > > > Log Message: > > Remove effectively tautological condition. > > I object to this sort of change. There are a number of other compilers > we might want to try sometime; all you're doing is adding to the > amount of work that takes. Given the state of most of the conditions we had in the tree, it is not a regression. If you have a compiler that doesn't provide most of the GCC command line, you will have so much things to change that this is irrelevant. Joerg
Re: CVS commit: src/share/mk
On Tue, Aug 14, 2012 at 03:48:19PM +0200, Joerg Sonnenberger wrote: > On Mon, Aug 13, 2012 at 08:55:33PM +, David Holland wrote: > > On Fri, Aug 10, 2012 at 04:34:23PM +, Joerg Sonnenberger wrote: > > > Modified Files: > > > src/share/mk: bsd.kmodule.mk > > > > > > Log Message: > > > Remove effectively tautological condition. > > > > I object to this sort of change. There are a number of other compilers > > we might want to try sometime; all you're doing is adding to the > > amount of work that takes. > > Given the state of most of the conditions we had in the tree, it is not > a regression. If you have a compiler that doesn't provide most of the > GCC command line, you will have so much things to change that this is > irrelevant. Perhaps so; all the same, it's creating extra work for no reason. I'm not going to demand you revert the changes you've already made, but please don't do it any more. Perhaps we should create a new set of make variables called HIDE_WARNINGS_* for the common cases that appear in these conditionals, since there's only a handful of them that repeat over and over again. Then the conditional logic itself can be centralized. -- David A. Holland dholl...@netbsd.org
re: CVS commit: src/share/mk
> Module Name: src > Committed By: pooka > Date: Mon Dec 10 20:58:55 UTC 2012 > > Modified Files: > src/share/mk: bsd.gcc.mk > > Log Message: > Deal with crti and crtn not present in some EXTERNAL_TOOLCHAIN's. Also, > handle "missing" crtstuff internally instead of depending on external > intervention. what is this change for? using sed here is wrong, irrespective of the comment reason you've given. if TOOL_SED isn't available, we shouldn't even be processing this file yet. that seems like the fix you should look for here. what is this EXTERNAL_TOOLCHAIN you're using? i'm totally at a loss what this change is useful for besides re-adding a host dependancy on sed. .mrg. ps: you didn't quote periods in your sed expressions.
Re: CVS commit: src/share/mk
On 11.12.2012 00:25, matthew green wrote: Module Name:src Committed By: pooka Date: Mon Dec 10 20:58:55 UTC 2012 Modified Files: src/share/mk: bsd.gcc.mk Log Message: Deal with crti and crtn not present in some EXTERNAL_TOOLCHAIN's. Also, handle "missing" crtstuff internally instead of depending on external intervention. what is this change for? So that you don't get bogus dependencies. using sed here is wrong, irrespective of the comment reason you've given. if TOOL_SED isn't available, we shouldn't even be processing this file yet. that seems like the fix you should look for here. If using sed here is wrong, then using sed instead of TOOL_SED in the multiple configure scripts under src/tools is wrong too. Do you want to fix those first? what is this EXTERNAL_TOOLCHAIN you're using? i'm totally at a loss what this change is useful for besides re-adding a host dependancy on sed. The solaris/cygwin toolchains, e.g.: $ cc --print-file-name=crtbegin.o /usr/local/lib/gcc/sparc-sun-solaris2.10/4.4.4/crtbegin.o $ cc --print-file-name=crtbeginS.o crtbeginS.o
re: CVS commit: src/share/mk
> On 11.12.2012 00:25, matthew green wrote: > >> Module Name: src > >> Committed By: pooka > >> Date: Mon Dec 10 20:58:55 UTC 2012 > >> > >> Modified Files: > >>src/share/mk: bsd.gcc.mk > >> > >> Log Message: > >> Deal with crti and crtn not present in some EXTERNAL_TOOLCHAIN's. Also, > >> handle "missing" crtstuff internally instead of depending on external > >> intervention. > > > > what is this change for? > > So that you don't get bogus dependencies. can you explain exactly what you're doing to need this? > > using sed here is wrong, irrespective of the comment reason you've > > given. if TOOL_SED isn't available, we shouldn't even be processing > > this file yet. that seems like the fix you should look for here. > > If using sed here is wrong, then using sed instead of TOOL_SED in the > multiple configure scripts under src/tools is wrong too. Do you want to > fix those first? that's not a valid argument. src/tools/ configure scripts, once HOST_SED is available, *should* be using it. but those are configure scripts whose whole purpose is to be portable. your change is to a netbsd-specific part of the build, that shouldn't be used until HOST_SED is available. if bsd.gcc.mk is being used too early, please fix that. > > what is this EXTERNAL_TOOLCHAIN you're using? i'm totally at a loss > > what this change is useful for besides re-adding a host dependancy > > on sed. > > The solaris/cygwin toolchains, e.g.: > > $ cc --print-file-name=crtbegin.o > /usr/local/lib/gcc/sparc-sun-solaris2.10/4.4.4/crtbegin.o > $ cc --print-file-name=crtbeginS.o > crtbeginS.o OK, so instead of making poor changes to our bsd*.mk can you please revert this change and start a discussion on tech-toolchain about the right way to fix this? thanks. .mrg.
Re: CVS commit: src/share/mk
On Tue, Dec 11, 2012 at 09:25:38AM +1100, matthew green wrote: > > > Module Name:src > > Committed By: pooka > > Date: Mon Dec 10 20:58:55 UTC 2012 > > > > Modified Files: > > src/share/mk: bsd.gcc.mk > > > > Log Message: > > Deal with crti and crtn not present in some EXTERNAL_TOOLCHAIN's. Also, > > handle "missing" crtstuff internally instead of depending on external > > intervention. > > what is this change for? > > using sed here is wrong, irrespective of the comment reason you've > given. if TOOL_SED isn't available, we shouldn't even be processing > this file yet. that seems like the fix you should look for here. > > what is this EXTERNAL_TOOLCHAIN you're using? i'm totally at a loss > what this change is useful for besides re-adding a host dependancy > on sed. It would be better to use make conditionals to fix the strings. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/share/mk
On Mon, 10 Dec 2012, Antti Kantee wrote:
+# If the toolchain does not know about a file, --print-file-name echoes
+# the input file name (why??). In that case we want an empty string for
+# dependencies to work correctly. Note: do _not_ use TOOL_SED here because
+# this file is used before TOOL_SED is built.
It's probably a bug if bsd.gcc.mk is used before TOOL_SED is
built. However, you have to .include before you try
to use any of its variables in a "!=" line.
+_GCC_CRTBEGINS!= ${CC} --print-file-name=crtbeginS.o \
+ | sed 's|^crtbeginS.o$$||'
You can remove the dependency on sed by using make :C/// variable
modifiers, like this (untested):
_GCC_CRTBEGINS!=${CC} --print-file-name=crtbeginS.o
_GCC_CRTENDS!= ${CC} --print-file-name=crtendS.o
_GCC_CRTI!= ${CC} --print-file-name=crti.o
_GCC_CRTN!= ${CC} --print-file-name=crtn.o
.for v in _GCC_CRTBEGINS _GCC_CRTENDS _GCC_CRTI _GCC_CRTN
# If the value does not contain '/' then replace it with the empty string
${v} := ${${v}:C,^[^/]*$,,}
.endfor
--apb (Alan Barrett)
Re: CVS commit: src/share/mk
"Christos Zoulas"
writes:
> Module Name: src
> Committed By: christos
> Date: Thu Jan 17 15:42:59 UTC 2013
>
> Modified Files:
> src/share/mk: bsd.prog.mk
>
> Log Message:
> Now that we have separate debug sets, add -g if ${MKDEBUG} is set for
> program builds since we don't need to install that symbol files.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.278 -r1.279 src/share/mk/bsd.prog.mk
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>
> Modified files:
>
>
> Index: src/share/mk/bsd.prog.mk
> diff -u src/share/mk/bsd.prog.mk:1.278 src/share/mk/bsd.prog.mk:1.279
> --- src/share/mk/bsd.prog.mk:1.278Fri Aug 24 16:26:24 2012
> +++ src/share/mk/bsd.prog.mk Thu Jan 17 10:42:59 2013
> @@ -1,4 +1,4 @@
> -#$NetBSD: bsd.prog.mk,v 1.278 2012/08/24 20:26:24 jmmv Exp $
> +#$NetBSD: bsd.prog.mk,v 1.279 2013/01/17 15:42:59 christos Exp $
> #@(#)bsd.prog.mk 8.2 (Berkeley) 4/2/94
>
> .ifndef HOSTPROG
> @@ -49,6 +49,9 @@ LDFLAGS+= ${PIE_LDFLAGS}
> .endif
>
> CFLAGS+= ${COPTS}
> +.if defined(MKDEBUG) && (${MKDEBUG} != "no")
> +CFLAGS+= -g
> +.endif
> OBJCFLAGS+= ${OBJCOPTS}
> MKDEP_SUFFIXES?= .o .ln
Well...
What about "DBG"?
Now it isn't clear what the difference between DBG, COPTS, and CFLAGS is
at all.
--
HE CE3OH...
Re: CVS commit: src/share/mk
In article <87fw1vob1m@inbox.ru>, Aleksej Saushev wrote:
>"Christos Zoulas"
>> +.endif
>> OBJCFLAGS+= ${OBJCOPTS}
>> MKDEP_SUFFIXES?=.o .ln
>
>Well...
>What about "DBG"?
>
>Now it isn't clear what the difference between DBG, COPTS, and CFLAGS is
>at all.
We cannot use DBG here because it is used with ?= in sys.mk. MKFOO
variables are not available in sys.mk.
christos
Re: CVS commit: src/share/mk
On Wed, Mar 20, 2013 at 09:48:15PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Thu Mar 21 01:48:15 UTC 2013 > > Modified Files: > src/share/mk: bsd.man.mk > > Log Message: > handle NOMANDOC in the html case too Please revert. The HTML backend of groff is completely broken and useless. Joerg
Re: CVS commit: src/share/mk
In article <20130321052513.gb4...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Wed, Mar 20, 2013 at 09:48:15PM -0400, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Thu Mar 21 01:48:15 UTC 2013 >> >> Modified Files: >> src/share/mk: bsd.man.mk >> >> Log Message: >> handle NOMANDOC in the html case too > >Please revert. The HTML backend of groff is completely broken and >useless. NOMANDOC should mean exactly that; doing it for 1/2 the conversion is at least unexpected. I did view the generated html page and it looked fine with me. christos
Re: CVS commit: src/share/mk
On 04/11/13 02:27, Christos Zoulas wrote:
Index: src/share/mk/bsd.lib.mk
diff -u src/share/mk/bsd.lib.mk:1.333 src/share/mk/bsd.lib.mk:1.334
--- src/share/mk/bsd.lib.mk:1.333 Thu Apr 4 17:15:15 2013
+++ src/share/mk/bsd.lib.mk Wed Apr 10 21:27:47 2013
@@ -1,4 +1,4 @@
-# $NetBSD: bsd.lib.mk,v 1.333 2013/04/04 21:15:15 christos Exp $
+# $NetBSD: bsd.lib.mk,v 1.334 2013/04/11 01:27:47 christos Exp $
# @(#)bsd.lib.mk 8.3 (Berkeley) 4/22/94
.include
@@ -444,6 +444,7 @@ _DEST.LIB:=${DESTDIR}${LIBDIR}
_DEST.OBJ:=${DESTDIR}${_LIBSODIR}
_DEST.LINT:=${DESTDIR}${LINTLIBDIR}
_DEST.DEBUG:=${DESTDIR}${DEBUGDIR}${LIBDIR}
+_DEST.ODEBUG:=${DESTDIR}${DEBUGDIR}${_LIBSODIR}
.if defined(LIB) # {
.if (${MKPIC} == "no" || (defined(LDSTATIC) && ${LDSTATIC} != "") \
@@ -839,6 +840,10 @@ ${_DEST.DEBUG}/${_LIB.so.debug}: ${_LIB.
${_MKTARGET_INSTALL}
${INSTALL_FILE} -o ${DEBUGOWN} -g ${DEBUGGRP} -m ${DEBUGMODE} \
${.ALLSRC} ${.TARGET}
+.if ${_LIBSODIR} != ${LIBDIR}
+ ${INSTALL_SYMLINK} -l r ${_DEST.DEBUG}/${_LIB.so.debug} \
+ ${_DEST.ODEBUG}/${_LIB.so.debug}
+.endif
.endif
.if ${MKLINT} != "no" && !empty(LOBJS)
Does it work? :)
Maybe change the log message?
Nick
Re: CVS commit: src/share/mk
On Apr 11, 11:29am, sk...@netbsd.org (Nick Hudson) wrote: -- Subject: Re: CVS commit: src/share/mk | Does it work? :) Yes, for me. | Maybe change the log message? I already did. christos
Re: CVS commit: src/share/mk
On Fri, May 03, 2013 at 03:55:22PM +, Matt Thomas wrote:
> Module Name: src
> Committed By: matt
> Date: Fri May 3 15:55:22 UTC 2013
>
> Modified Files:
> src/share/mk: bsd.own.mk
>
> Log Message:
> Use !empty(MACHINE_ARCH:Mearm*) instead of ${MACHINE_ARCH:Mearm*} != ""
Any reason?
Make finds it much harder to parse empty().
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src/share/mk
In article <20130503174230.gp24...@snowdrop.l8s.co.uk>,
David Laight wrote:
>On Fri, May 03, 2013 at 03:55:22PM +, Matt Thomas wrote:
>> Module Name: src
>> Committed By:matt
>> Date:Fri May 3 15:55:22 UTC 2013
>>
>> Modified Files:
>> src/share/mk: bsd.own.mk
>>
>> Log Message:
>> Use !empty(MACHINE_ARCH:Mearm*) instead of ${MACHINE_ARCH:Mearm*} != ""
>
>Any reason?
>Make finds it much harder to parse empty().
make finds it? how so? It has to do more work to parse the second form,
plus writing the second form is ambiguous. does the LHS need quoting or
not. Why? Will single quotes work too?
christos
Re: CVS commit: src/share/mk
On Fri, May 03, 2013 at 06:42:30PM +0100, David Laight wrote:
> On Fri, May 03, 2013 at 03:55:22PM +, Matt Thomas wrote:
> > Module Name: src
> > Committed By: matt
> > Date: Fri May 3 15:55:22 UTC 2013
> >
> > Modified Files:
> >src/share/mk: bsd.own.mk
> >
> > Log Message:
> > Use !empty(MACHINE_ARCH:Mearm*) instead of ${MACHINE_ARCH:Mearm*} != ""
>
> Any reason?
> Make finds it much harder to parse empty().
:-?
--
David A. Holland
dholl...@netbsd.org
re: CVS commit: src/share/mk
> Module Name: src
> Committed By: matt
> Date: Thu Dec 5 22:51:08 UTC 2013
>
> Modified Files:
> src/share/mk: bsd.own.mk
>
> Log Message:
> Add MACHINES.${MACHINE_CPU} values.
cool. this should be useful. one update:
- you can build sparc64 as sparc.
and can you mention this in bsd.README?
Re: CVS commit: src/share/mk
On Jan 21, 2014, at 5:40 PM, Matt Thomas wrote: > Module Name: src > Committed By: matt > Date: Tue Jan 21 16:40:24 UTC 2014 > > Modified Files: > src/share/mk: bsd.own.mk > > Log Message: > Make MKGCCCMDS default mirror MKGCC. (if MKGCC is no, MKGCCCMDS must be no). This breaks all builds as MKGCCCMDS is now missing from the set list print controls. See distrib/sets/mkvars.mk, target mkvars -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: CVS commit: src/share/mk
On Jan 22, 2014, at 7:19 AM, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Jan 22 15:19:05 UTC 2014 > > Modified Files: > src/share/mk: bsd.klinks.mk > > Log Message: > For now, ignore errors from creating klinks. This is racy and you can get > it to trigger in 1/4 of the builds with -j 40 on a 24 processor box. Typical > error is: > >ln: machine/include: File exists >*** Failed target: .BEGIN >*** Failed command: rm -f machine && ln -s > /p/netbsd/cvsroot/src/sys/arch/vax/include machine >*** Error code 1 >Stop. > > Another approach to fixing this is to create a lockfile or adding other flags > to ln to change its behavior. I always wondered why we don't use ln -sf and avoid the race.
Re: CVS commit: src/share/mk
On Jan 22, 7:29am, m...@3am-software.com (Matt Thomas) wrote: -- Subject: Re: CVS commit: src/share/mk | I always wondered why we don't use ln -sf=20 | and avoid the race. That does not work because if the destnation is a directory it will try to link in the destination directory... (I tried). This is why I suggested that it needs to be done differently. christos
Re: CVS commit: src/share/mk
Date: Wed, 22 Jan 2014 13:15:44 -0500 From: chris...@zoulas.com (Christos Zoulas) On Jan 22, 7:29am, m...@3am-software.com (Matt Thomas) wrote: -- Subject: Re: CVS commit: src/share/mk | I always wondered why we don't use ln -sf | and avoid the race. That does not work because if the destnation is a directory it will try to link in the destination directory... (I tried). This is why I suggested that it needs to be done differently. ln -sfh? As an aside, it would be nice if there were an easy way to create a symlink at a temporary location and rename it over the permanent one. `ln -sfh' will unlink instead, and mv(1) is too smart for its own good about directories to be able to rename over a symlink reliably...
Re: CVS commit: src/share/mk
On Jan 23, 3:11am, campbell+netbsd-source-change...@mumble.net (Taylor R Campbell) wrote: -- Subject: Re: CVS commit: src/share/mk |Date: Wed, 22 Jan 2014 13:15:44 -0500 |From: chris...@zoulas.com (Christos Zoulas) | |On Jan 22, 7:29am, m...@3am-software.com (Matt Thomas) wrote: |-- Subject: Re: CVS commit: src/share/mk | || I always wondered why we don't use ln -sf || and avoid the race. | |That does not work because if the destnation is a directory it will |try to link in the destination directory... (I tried). This is why |I suggested that it needs to be done differently. | | ln -sfh? | | As an aside, it would be nice if there were an easy way to create a | symlink at a temporary location and rename it over the permanent one. | `ln -sfh' will unlink instead, and mv(1) is too smart for its own good | about directories to be able to rename over a symlink reliably... Yes perhaps that will work. christos
Re: CVS commit: src/share/mk
I wonder if "ln -sfh" is portable? On Thu, Jan 23, 2014 at 12:23 PM, Christos Zoulas wrote: > On Jan 23, 3:11am, campbell+netbsd-source-change...@mumble.net (Taylor R > Campbell) wrote: > -- Subject: Re: CVS commit: src/share/mk > > |Date: Wed, 22 Jan 2014 13:15:44 -0500 > |From: chris...@zoulas.com (Christos Zoulas) > | > |On Jan 22, 7:29am, m...@3am-software.com (Matt Thomas) wrote: > |-- Subject: Re: CVS commit: src/share/mk > | > || I always wondered why we don't use ln -sf > || and avoid the race. > | > |That does not work because if the destnation is a directory it will > |try to link in the destination directory... (I tried). This is why > |I suggested that it needs to be done differently. > | > | ln -sfh? > | > | As an aside, it would be nice if there were an easy way to create a > | symlink at a temporary location and rename it over the permanent one. > | `ln -sfh' will unlink instead, and mv(1) is too smart for its own good > | about directories to be able to rename over a symlink reliably... > > > Yes perhaps that will work. > > christos
Re: CVS commit: src/share/mk
On Jan 23, 12:59pm, uebay...@gmail.com (Masao Uebayashi) wrote:
-- Subject: Re: CVS commit: src/share/mk
| I wonder if "ln -sfh" is portable?
I smell ${TOOL_LN}.
christos
Re: CVS commit: src/share/mk
On Wed, 22 Jan 2014, Christos Zoulas wrote: On Jan 22, 7:29am, m...@3am-software.com (Matt Thomas) wrote: -- Subject: Re: CVS commit: src/share/mk | I always wondered why we don't use ln -sf=20 | and avoid the race. That does not work because if the destnation is a directory it will try to link in the destination directory... (I tried). This is why I suggested that it needs to be done differently. In the common case, all this linking is happening in an OBJDIR which either started off empty, or started off with the correct symlinks. It might be possible to detect this common case and arrange for it to be race-free. I don't think "ln -sf" is so bad. The first time, you get the desired symlink: /dirname/linkname -> destination then the second time, if you lose the race, you get a useless and mostly harmless extra link: /dirname/destination/destination -> destination My tests suggest that the third time, and every other time you run "ln -sf destination /dirname/linkname", nothing really changes. /dirname/destination/destination might be deleted and re-created, but (at least on NetBSD and Linux) nothing worse happens. If the extra link is offensive, then just delete it, making the entire sequence like this: # remove old symlink rm -f /dirname/linkname # create desired new symlink, # or create bogus extra link (if we lose the race) ln -sf destination /dirname/linkname # remove bogus extra link (if it exists) rm -f /dirname/destination/destination "ln -sfh" is not portable, so we can't use that. --apb (Alan Barrett)
Re: CVS commit: src/share/mk
On Tue, 21 Jan 2014, Matt Thomas wrote: Module Name:src Committed By: matt Date: Tue Jan 21 16:40:24 UTC 2014 Modified Files: src/share/mk: bsd.own.mk Log Message: Make MKGCCCMDS default mirror MKGCC. (if MKGCC is no, MKGCCCMDS must be no). If that's true, then please adjust bsd.README to say so. Currently, they are documented as being independent (but there seem to be some accidental yes/no inversions in the documentation). --apb (Alan Barrett)
Re: CVS commit: src/share/mk
Date: Thu, 23 Jan 2014 03:11:14 + From: Taylor R Campbell Date: Wed, 22 Jan 2014 13:15:44 -0500 From: chris...@zoulas.com (Christos Zoulas) On Jan 22, 7:29am, m...@3am-software.com (Matt Thomas) wrote: -- Subject: Re: CVS commit: src/share/mk | I always wondered why we don't use ln -sf | and avoid the race. That does not work because if the destnation is a directory it will try to link in the destination directory... (I tried). This is why I suggested that it needs to be done differently. ln -sfh? As an aside, it would be nice if there were an easy way to create a symlink at a temporary location and rename it over the permanent one. `ln -sfh' will unlink instead, and mv(1) is too smart for its own good about directories to be able to rename over a symlink reliably... Disregard me -- `ln -sfh' is just as bad as the other race precisely because of the unlink/symlink sequence, and `-h' is not POSIX to boot. If we do add a TOOL_LN, we ought to implement a symlink-to-temporary rename-to-permanent operation so that it actually doesn't race.
Re: CVS commit: src/share/mk
Is this all about symlink-to-directory in an OBJDIR, right? My theory is that directory creation in OBJDIR is all wrong... Kernel build *should* include static headers in $DESTDIR (#include ) or generated headers (#include "foo.h") IMO.
Re: CVS commit: src/share/mk
Sorry that I was lost, but I still believe that creating-directories-as-make-target is to avoid. Is there any counter-example (use case) where it should be there? On Fri, Jan 24, 2014 at 1:30 AM, Izumi Tsutsui wrote: >> Is this all about symlink-to-directory in an OBJDIR, right? My theory >> is that directory creation in OBJDIR is all wrong... >> >> Kernel build *should* include static headers in $DESTDIR (#include >> ) or generated headers (#include "foo.h") IMO. > > is used only for standalone programs > and it should not require installed DESTDIR. > > For kernel builds, config(1) creates symlinks in compile dirs. > > --- > Izumi Tsutsui
Re: CVS commit: src/share/mk
> Is this all about symlink-to-directory in an OBJDIR, right? My theory > is that directory creation in OBJDIR is all wrong... > > Kernel build *should* include static headers in $DESTDIR (#include > ) or generated headers (#include "foo.h") IMO. is used only for standalone programs and it should not require installed DESTDIR. For kernel builds, config(1) creates symlinks in compile dirs. --- Izumi Tsutsui
re: CVS commit: src/share/mk
> Module Name: src
> Committed By: christos
> Date: Wed Jan 22 15:19:05 UTC 2014
>
> Modified Files:
> src/share/mk: bsd.klinks.mk
>
> Log Message:
> For now, ignore errors from creating klinks. This is racy and you can get
> it to trigger in 1/4 of the builds with -j 40 on a 24 processor box. Typical
> error is:
>
> ln: machine/include: File exists
> *** Failed target: .BEGIN
> *** Failed command: rm -f machine && ln -s
> /p/netbsd/cvsroot/src/sys/arch/vax/include machine
> *** Error code 1
> Stop.
>
> Another approach to fixing this is to create a lockfile or adding other flags
> to ln to change its behavior.
make ${SRCS} depend upon machine? ie, fix this by fixing the
dependancies?
.mrg.
re: CVS commit: src/share/mk
> Is this all about symlink-to-directory in an OBJDIR, right? My theory > is that directory creation in OBJDIR is all wrong... > > Kernel build *should* include static headers in $DESTDIR (#include > ) or generated headers (#include "foo.h") IMO. the kernel build 100% does not and should not depend upon $DESTDIR. .mrg.
Re: CVS commit: src/share/mk
How about kernel modules? On Fri, Jan 24, 2014 at 1:00 PM, matthew green wrote: > >> Is this all about symlink-to-directory in an OBJDIR, right? My theory >> is that directory creation in OBJDIR is all wrong... >> >> Kernel build *should* include static headers in $DESTDIR (#include >> ) or generated headers (#include "foo.h") IMO. > > the kernel build 100% does not and should not depend upon $DESTDIR. > > > .mrg.
re: CVS commit: src/share/mk
> How about kernel modules? exactly the same. our userland does not have anything useful for building kernel code. you _need_ the kernel source tree, and it is bascially self-contained in src/sys (sans the src/common problem we haven't fixed yet, and config(1).) this is very much by design. > On Fri, Jan 24, 2014 at 1:00 PM, matthew green wrote: > > > >> Is this all about symlink-to-directory in an OBJDIR, right? My theory > >> is that directory creation in OBJDIR is all wrong... > >> > >> Kernel build *should* include static headers in $DESTDIR (#include > >> ) or generated headers (#include "foo.h") IMO. > > > > the kernel build 100% does not and should not depend upon $DESTDIR. > > > > > > .mrg. .mrg.
