> if (hscroll || vscroll) {
> xf86Msg(X_WARNING, "%s: hscroll=%d, vscroll=%d\n",
> pInfo->name, hscroll, vscroll);
[ ... ]
> This touchpad method is not supported by the xf86-input-mouse driver so
> with that one the touchpad does
> On Mon 05 Feb 2024 at 10:18:09 +1100, matthew green wrote:
> > perhaps convert into a DBG(4, ...)?
>
> On Mon 05 Feb 2024 at 02:20:25 +0300, Valery Ushakov wrote:
> > May be make it reported only once, so that the message is still there
> > in the log, but it's
> Unfortunately there was no core dump.
this is almost certainly because /var/chroot/named is not writeable
by user named, which is on purpose.
you can set the corefile path for this process after it starts using
sysctl proc.$pid.corename. i think setting to "/var/tmp/%n.core"
should allow it to
actually, i found a core file in /var/chroot/named/etc/namedb/named.core.
my build is missing debug info so i don't have a good idea what.
.mrg.
this appears to be a badly aligned structure issue. i can reproduce
it by doing "anita interact" with any recent sparc .iso, editing the
named.conf to start, starting named, and doing 'dig ns netbsd.org'
would trigger the crash.
the stack trace is:
(gdb) bt
#0 ns__client_request (handle=0xeb02d
ah. the problem is that struct isc_nmhandle grew a pointer member,
adding 4 bytes to the struct size, and it uses C99 [] variable array
for the final member, which is later assigned to other pointers, and
this memory was now only 4-byte aligned. this hack patch works to
stop named crashing for me
Paul Goyette writes:
> On Tue, 5 Mar 2024, Paul Goyette wrote:
>
> > I _think_ it will work correctly if I modify fstab to refer to
> > NAME=Builds instead of ccd0. I will update here after I confirm.
>
> Yes this seems to work.
this is very much preferred. "ccd0" is the device i suspect if
you
Paul Goyette writes:
> Does anyone have an example of how to configure raid0 on a GPT disk?
these are my notes i refer to every so often:
https://www.netbsd.org/~mrg/gpt-raid-setup.txt
it's gpt on each with type raid, which gives you dkN @ diskN,
you then create a raid with those dkNs, and then
hiya.
the new compat32 sets rearrangement has broken the GCC 12 build,
due to dropping "gcc=10" tag in some places. that's a minor issue,
and i'll fix that soon (though having looked closer at the first
"grep -r" output below, i see most of these are affected. i'll
just initially be fixing arm6
this might be the same as
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57153
it's the same faulting function and similar offset...
.mrg.
nia writes:
> The ThinkPad A485 looks pretty interesting for use with NetBSD.
[ ... ]
> - AMD Radeon Vega 6, 8 or 10
>
> Usually I prefer the smaller X series, but they've made them
> non-upgradable and harder to repair...
>
> ethernet is re0, this is different from the intel models that are
[ ...
hi folks.
just a heads up that i plan to switch most ports over to GCC 12
in the coming week.
at least, arm64, x86, sparc*, ia64, and riscv targets very soon,
with arm32 and alpha probably soon after. more testing needed
for m68k, ppc, mips, and hppa. vax needs the gcc12 version of
the Kalvis
--- Blind-Carbon-Copy
to: Jan-Benedict Glaw
cc: port-...@netbsd.org
subject: re: HEADS UP: plan to switch many ports over to GCC 12 soon
in-reply-to: <20240610040023.gd16...@lug-owl.de>
from: matthew green
organisation: people's front against (bozotic) www (softwar foundati
> Yesterday I did two builds from the same source tree - two because the first
> one failed:
>
> --- includes-crypto/external ---
> *** Failed target: /usr/obj/amd64.gcc.20240613/usr/include/krb5/ocsp_asn1.h
> *** In directory: /usr/src/crypto/external/bsd/heimdal/lib/libhx509
> *** Failed command
matthew green writes:
> at least, arm64, x86, sparc*, ia64, and riscv targets very soon,
> with arm32 and alpha probably soon after. more testing needed
i have switched all these ports over to GCC 12.
enjoy and send-pr or email tech-toolchain@ for any issues.
thanks.
.mrg.
NetBSD Test Fixture writes:
> --- aes_via.o ---
> In file included from
> /tmp/build/2024.06.15.20.36.38-i386/src/sys/sys/systm.h:648,
> from
> /tmp/build/2024.06.15.20.36.38-i386/src/sys/crypto/aes/arch/x86/aes_via.c:35:
>
> /tmp/build/2024.06.15.20.36.38-i386/s
both reported issues (bracket, pgoyette) are with a xen kernel,
and i see it may end up with non-std-x86 values of MACHINE and/or
MACHINE_ARCH in some cases, but why i'm not seeing it is confusing
me quite a bit here.
src/sys> grep ^machine arch/i386/conf/std.xen
machine xen i386 x86
this *
OK, this should be fixed now at bsd.own.mk 1.1378.
the problem was that for the xen kernel builds, MACHINE=xen,
and the bsd.own.mk snippet was checking for "i386" and "amd64",
and not "xen". i was able to trigger the failure in a tree
using an empty mk.conf, still not sure why i didn't see it in
Chavdar Ivanov writes:
> # compile INSTALL_XEN3_DOMU/aes_ni.o
[ ... ]
> [-Werror=stringop-overread]
this indicates you're still seeing the thing that should be fixed with
bsd.own.mk 1.1379?
.mrg.
Thomas Klausner writes:
> Hi!
>
> Yesterday I did two builds from the same source tree - two because the first
> one failed:
>
> --- includes-crypto/external ---
> *** Failed target: /usr/obj/amd64.gcc.20240613/usr/include/krb5/ocsp_asn1.h
i'm not sure i can see a case where these header files ar
matthew green writes:
> matthew green writes:
> > at least, arm64, x86, sparc*, ia64, and riscv targets very soon,
> > with arm32 and alpha probably soon after. more testing needed
>
> i have switched all these ports over to GCC 12.
>
> enjoy and send-pr or email tec
> On Sun, 2024-06-30 at 09:44 +1000, matthew green wrote:
> > sh3 may be problematic,
>
> I can almost certainly test sh3. I should even be able to make a new
> bootable disk for an end to end test.
oh the problem is it's broken -- rin@ could talk more about it,
i'
> -size_t count = from_st->st_size;
> #if defined _GLIBCXX_USE_SENDFILE && ! defined _GLIBCXX_FILESYSTEM_IS_WINDOWS
> +size_t count = from_st->st_size;
that looks right to me. it works and i commited it.
thanks! and sorry for the breakage.
.mrg.
Rhialto writes:
> Does the assembler also get updated with this? I'm asking because I
> noticed when compiling pkgsrc package libdeflate-1.20 with gcc12 (from
> pkgsrc) that the compiler generates vpdpbusd instructions (amd64) but
> the assembler doesn't know those:
>
> [ 55%] Building C object CMa
Robert Swindells writes:
>
> >> -size_t count = from_st->st_size;
> >> #if defined _GLIBCXX_USE_SENDFILE && ! defined
> >> _GLIBCXX_FILESYSTEM_IS_WINDOWS
> >> +size_t count = from_st->st_size;
> >
> > that looks right to me. it works and i commited it.
>
> I didn't think we had sendfile
> install ===> tools/binutils
> /bin/sh
> /home/sysbuild/src/tools/binutils/../../external/gpl3/binutils/dist/mkinstalldirs
this looks like you're using new binutils?
can you confirm that you have HAVE_BINUTILS=239? it should be
using binutils.old for now.
christos did commit a couple of fixes
> > > /bin/sh
> > > /home/sysbuild/src/tools/binutils/../../external/gpl3/binutils/dist/mkinstalldirs
> >
> > this looks like you're using new binutils?
> >
> > can you confirm that you have HAVE_BINUTILS=239? it should be
> > using binutils.old for now.
>
> I do not have this defined anywhere, a
> > m68000 doesn't yet build fully,
>
> Only libasan is currently broken. With attached patch, I've
> confirmed libasan successfully builds, and system boots
> multiuser on TME.
>
> I've never tested asan on sun2, as it does not work anyway.
> Also, affects of this patch for other m68k ports are no
Chavdar Ivanov writes:
> Hi,
>
> I am repeatedly getting:
> # compile libLLVMAMDGPUCodeGen/SILateBranchLowering.pico
this one should be worked around now. GCC 12.4 more whiney on arm64?
.mrg.
> kern_assert() at __x86_indirect_thunk_rax
> fd_putfile() at fd_putfile+0x1e2
> fd_nameiat.constprop.0() at fd_nameiat.constprop.0+0x3f
> do_sys_mkdirat() at do_sys_mkdirat+0xa5
please try again after vfs_syscalls.c 1.565.
thanks.
.mrg.
Thomas Klausner writes:
> Hi!
>
> postinstall check on my system complains
> ...
> fontconfig check:
> Broken fontconfig configuration found; please delete these files:
> [ 10-sub-pixel-rgb.conf]
> ...
>
> but can't fix the problem:
> # postinstall fix fontconfig
> Source directory:
> I needed to ifconfig up the interface being used by hostapd, once I did
don't feel bad. i don't understand the rules about when things are
up or not by default and it seems that this problem happens about
every 5 years for me...
.mrg.
hi folks.
this is a warning that builds might fail due to the updated mpc
and mpfr sources i've imported. you might need to clean both
the tools and normal build dirs for them.
please send-pr or send me email if you see issues. thanks!
.mrg.
> --- toom53_mul.o ---
> /archive/foreign/src/external/lgpl3/gmp/lib/libgmp/../../dist/mpn/generic/toom53_mul.c:102:52:
> error: '&' within '|' [-Werror,-Wbitwise-op-parentheses]
> flags = (enum toom7_flags) (flags | toom7_w1_neg & mpn_toom_eval_pm2 (as2,
> asm2, 4, ap, n, s, gp));
>
> This is in particular a sudden inability to build NetBSD-current from source.
could you be more explicit about what is failing? there
shouldn't be any issues remaining, but some types of
failure modes require cleaning out your build/obj trees,
and won't go away with any amount of cvs update.
> Last failure was on gmp, which later built successfully as a dependency from
> pkgsrc.
ah, i see the confusion here.
my post was *only* about the in-tree gmp/mpfr/mpc that we use
for the in-tree gcc and for building netbsd, and has nothing
to do with the versions in pkgsrc. i don't maintain
i've started upgrading our GCC to 4.8.5. while i don't expect anything
to fail in the mean time, it might. please file a PR or contact me
directly if you notice any new problems.
i also expect to begin looking at GCC 5.1 when 5.1.1 is released, which
may be soon, but unknown to me as yet.
.mr
> Now, whenever the system is up for a few days, and I didn't think of
> restarting firefox for a while, it eventually crashes with:
> > panic: kernel diagnostic assertion "((mutex->wwm_state != WW_OWNED) ||
> > (mutex->wwm_u.owner != curlwp))" failed: file
> > "/usr/src/sys/external/bsd/drm2/l
> I've been offering the attached patch to try to debug the source of
> the problem before the symptom you described happens. I haven't
> gotten any diagnostics back from anyone yet. If you can, please try
> it out and let me know.
i've got this running on my laptop but i'm not using it very he
hi folks.
just a quick status update.
those of you watching source-changes may notice that we recently got the
nouveaudrm driver able to attach a text console.
starting X crashes, but it's at a point you can either use the text console
or help debug the crash :-) you'll need the very latest -c
hi folks.
i've changed the default for GCC for amd64 and i386 to GCC 5.3. this
will need clean obj to properly build, and it's best to do a full cleandir
anyway to get all objects rebuilt with the new compiler.
please send-pr any problems. thanks!
.mrg.
can you try building lib/csu/ with -O1 and see if that works?
you'll have to relink all the apps/shlibs, but an update build
should do this properly. just run a make clean in lib/csu,
revert lib/csu/common/Makefile.inc to rev 1.31, and build the
world again..
thanks.
.mrg.
Thor Lancelot Simon writes:
> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote:
> >
> > >2) /usr/bin/cc:
> > >Undefined symbols for architecture x86_64: "_iconv"
> > >in external/gpl3/gcc/usr.bin/backend
> >
> > This should be in libc.
>
> For what value of "should"? _ic
> I've been trying to find when this breakage occurred,
it happened when your port switched to GCC 5. sorry :-)
.mrg.
hi folks.
i've gotten native xorg server updated to 1.18.4 and working for me
on i386, amd64 and shark. more testing is needed.
to test, simply pass -V HAVE_XORG_SERVER_VER=118 to build.sh or set
it in mk.conf.
if you'd like to test, i recommend having a completely clean obj
and destdir for it
> nbmake[13]: nbmake[13]: don't know how to make
> /usr/obj/external/mit/xorg/server/xorg-server/glamor/libglamor.a. Stop
ah, this is a simple ordering issue i had missed due to manually
building this once..
please try with external/mit/xorg/server/xorg-server/Makefile rev 1.27.
thanks for test
FWIW, i've now successfully tested xorg-server 1.18 on:
shark (wsfb)
sparc64 (mach64)
ofppc (radeon 9250)
x86 (32/64bit) (radeonhd R7 240, 6450, 4670, nvidia 440.)
and i've confirmed that macppc builds with sets.
.mrg.
> > nbmake[9]: nbmake[9]: don't know how to make ftcolor.h. Stop
that sounds like you are mixing old xsrc and -current src.
can you confirm your xsrc is up to date?
.mrg.
Patrick Welche writes:
> I see in
>
> http://mail-index.netbsd.org/port-amd64/2019/12/26/msg003110.html
>
> i915drmkms0 at pci0 dev 2 function 0: Intel UHD Graphics 620 (GT2) (rev.
> 0x07)
>
> but I have a laptop here which has
>
> genfb0 at pci0 dev 2 function 0: Intel UHD Graphics 620
> File wasn't installed ?
> --
> ./usr/share/man/html9/rw_lock_op.html
> ./usr/share/man/man9/rw_lock_op.9
> end of 2 missing files ==
i have a fix for this in testing, hopefully commiting soon.
.mrg.
i'm not sure if this patch is right, but i'm reasonably confident
it is and it fixes the build breakage i'm seeing:
https://www.netbsd.org/~mrg/lfs.buildfix.diff
.mrg.
i can confirm i see this also. so, glamor has the same
problem with GL on older radeon as it does radeonsi,
where glamor is needed for other accel (eg, it still has
other drm-based features like Xvideo, and runs faster
for general moving windows ops.)
i'll see about disabling glamor default for n
> I frequently leave "systat vm" running in a tmux window and regularly
> get the "can't get buffers:" warning. I was curious enough that I
> believe the attached patch will likely prevent it. Diff is against the
> netbsd-9 branch, but it should apply cleanly against head.
i've also seen this occa
hi folks.
here are a few build benchmark tests on an amd ryzen 3950x
system, to see the cumulative effect of the various fixes we've
seen since netbsd-9, for this 16 core/ 32 thread CPU, 64GB of
ram, separate nvme ssd for src & obj.
below has a full summary, but the highlights:
- building kern
hi folks.
i'm in the process of updating GCC to 8.4, so for the ports
using GCC 8.3 you may need to clean the tools and gcc parts
of the tree to successfully build.
.mrg.
Robert Swindells writes:
>
> Is anyone else having problems doing a clean build ?
>
> It is stopping for me in src/lib/libtelnet with this:
>
> #create libtelnet/sra.d
> CC=/u8/build/aarch64-tools/bin/aarch64--netbsd-gcc
> /u8/build/aarch64-tools/bin/n
> bmkdep -f sra.d.tmp -- -std=gnu9
Jason Thorpe writes:
> Is anyone currently using fxp(4) successfully? I am having trouble with =
> link stability on a new-in-box i82559 card, but on a non-x86 platform.
i've used it on alpha fairly recently.
.mrg.
Thomas Klausner writes:
> Here's a version with less warnings:
>
> int a;
> struct b {
> char c;
> void *d;
> };
> struct b e() {
> struct b f[] = {{}, "", f, a};
> }
>
> Don't forget to use -fstack-check.
FWIW, this fails in both unpatched GCC 8.3.0 and 8.4.0 for
netbsd/amd64. ... and sa
Andrew Doran writes:
> Doesn't show up in Opengrok, maybe it dislikes rump. Already fixed.
opengrok is missing massive portions of src, please don't
rely upon it to find "all" of anything.
... or can we have it fixed please? :)
(grep -r across 'src' is really fast on a modern system when
it's
welcome back! :-)
> * X (modular) segfaults from the beginning (GENERIC_ALSR) for intel(4), but
> works fine when "UXA" is set for "AccelMethod" in xorg.conf(5).
this one is fairly well known at this point. we've been
reducing the platforms that default to SNA since -9 came
out... there's also
> That and find the part of the code that checks for the card type to
> disable ignoring R200 and below.
sys/external/bsd/drm2/radeon/radeon_pci.c:bool radeon_pci_ignore_r100_r200 =
true;
is where it's implemented.
.mrg.
hi folks.
after sufficient testing, both alpha and vax have been switched
to GCC 8 as the default compiler in -current.
please send-pr or email current-users about issues.
thanks!
.mrg.
Christos Zoulas writes:
>
> Hello folks,
>
> I've renamed blacklist to blocklist, so if you are currently using it,
> you should rename things accordingly:
>
> - rc.conf variable
> - /var/db/blacklist.db file
> - npf table name
>
> Apologies for the inconvenience,
thank you.
the discussion here is pretty disappointing.
christos can name his software as he likes. if you don't like
it then don't use it, but don't tell him what he can do with
his own code.
if you'd written blocklist you'd have a voice in naming it.
.mrg.
Martin Husemann writes:
> On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote:
> > Replacing malloc is just as invalid from a strict standard compliance
> > perspective, so *shrug*
>
> Why is that?
>
> We have e.g. shells/standalone-tcsh that does it. Is it broken now?
it was, yes
hi folks.
in a test that didn't change the contents of the tree, but
did change the timestamps, we're hitting cases where
gengtype-lex.c is newer than gengtype-lex.l, and the build
tries to write the updated .c file back into the (possibly
r/o) source tree.
to work around this and to follow our
"John D. Baker" writes:
> Since mips-ee/R5900 support returned to GCC, I've made a point to build
> distribution and sets for playstation2. Recent changes to crash(8)
> and/or mips MD sources causes building crash(8) to fail with:
this should be fixed now. thanks for pointing it out.
.mrg.
> /build/netbsd-compat/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/netbsd.h:54:10:
> fatal error: bfd.h: No such file or directory
> #include "bfd.h"
>^~~
do you have a bfd.h lying around somewhere it shouldn't? check
your source tree for extra files? eg 'cvs u
hi folks.
i've switched x86 and arm to GCC 9. several others are liking
to switch soon, and they will all likely need clean builds to
be stable.
please send email here or to me or send-pr for problems.
thanks!
.mrg.
> Would -r flag in build.sh command be sufficient to ensure a clean build?
>
> Something like
> ===> build.sh command:./build.sh -m amd64 -B nb899-20190723 -M ../obj -T
> ../tooldir -r -U distribution kernel=SANDY7
this is probably good enough.
-r removes tooldir and destdir. the lack of -
> In file included from
> usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
> /libstdc++-v3/src/c++17/fs_dir.cc:29:10: fatal error:
> bits/largefile-config.h: No such file or directory
>29 | #include
> | ^
my fault, but this sho
nia writes:
> getting this a lot whenever my laptop recovers from suspend.
>
> was it intended?
>
> should my laptop not be using TSC as the default timecounter?
this is the x86 specific message. the generic one is limited
to once-per-boot.
i recommend rate or single-use limiting it similarly.
Nikita Gillmann writes:
> This is with a recent checkout after gcc9 import. If no one can
> reproduce this, what can I do?
OK, i see the problem -- should be fixed with
external/gpl3/gcc/lib/libsupc++/Makefile.common rev 1.19
.mrg.
> > > In file included from
> > > usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
> > > /libstdc++-v3/src/c++17/fs_dir.cc:29:10: fatal error:
> > > bits/largefile-config.h: No such file or directory
> > >29 | #include
> > > | ^
Chavdar Ivanov writes:
> /home/sysbuild/src/usr.sbin/crash/../../sys/arch/amd64/amd64/db_disasm.c:41:
> /home/sysbuild/src/usr.sbin/crash/../../sys/sys/ksyms.h:147:1: error:
> unknown type name 'bool'
> 147 | bool ksyms_available(void);
> | ^~~~
should be fixed now. make sure you have sys
hi folks.
i've updated the gMP sub-components mpc and mpfr to their
latest versions, and will be doing gmp itself in the near
future.
at least mpfr will need a clean build to avoid problems,
and that's in both tools and external/lgpl3/mpfr.
.mrg.
hi Sunil,
thanks for the patch. i meant to reply earlier.
can you explain why you want to enable the old ssl/tls
variants that we know are insecure?
i don't know that i want to have an option to enable
them without a special compile, but i'm willing to be
convinced.
thanks.
.mrg.
this looks much better. if someone doesn't beat me too it, i'll
merge this in soon.
thanks!
.mrg.
> manual xkeyboard-config.7 matches @.*@, probably missing updates
> *** [xkeyboard-config.7] Error code 1
hmm, i thought i commited this fix for this.. but nope, i
only had it sitting in my tree.
please try again with
src/external/mit/xorg/lib/xkeyboard-config/Makefile 1.14
.mrg.
matthew green writes:
> > manual xkeyboard-config.7 matches @.*@, probably missing updates
> > *** [xkeyboard-config.7] Error code 1
>
> hmm, i thought i commited this fix for this.. but nope, i
> only had it sitting in my tree.
>
> please try again with
> src/e
hi folks.
this is an update on my previous testing. i've excluded
amd64 release builds from this set, takes too long ;)
link at the bottom is the raw data, i've not tabulated it
more than this this time. sorry. summary has the more
interesting details.
new summary:
- WOW. i mean. *WOW*.
> On Sat, Nov 07, 2020 at 06:12:34PM +1100, matthew green wrote:
> > this is an update on my previous testing. i've excluded
> > amd64 release builds from this set, takes too long ;)
>
> Indeed remarkable! I assume you build the same source tree on the various
&
> On 10.11.2020 09:19, matthew green wrote:
> > there was not nearly enough discussion for this and i object
> > quite strongly about this. please revert immediately and
> > begin a real discussion.
>
> Revert MKCATPAGES change?
yes, all of it. your proposal was n
nice. LGTM.
.mrg.
Yorick Hardy writes:
> Dear current-users,
>
> Happy new year!
happy new year yorick! and everyone.
> [ 659.839003] usbd_create_xfer() at netbsd:usbd_create_xfer+0x186
> [ 659.849001] usbd_open_pipe_intr() at netbsd:usbd_open_pipe_intr+0x74
> [ 659.849001] uhidev_open() at netbsd:uhidev_ope
radeondrm does not support any modern graphics card, and
we don't have a working amdgpu driver yet (last i tried,
it hung at boot and i did not have a serial console setup
to test with yet.)
you can have almost OK stuff with the vesa driver. maybe
wsfb also can work.
we're working (slower than h
> Joerg thinks that this is an nfs issue (a bug with nfs giving incorrect data).
even if true, tar shouldn't *core dump*. is there a path
to RCE here some where? it's clearly overwriting pointers
with strings, so unless someone can clearly show there is
no code exec vector here, it seems potenti
> In this particular example server it's in a Dell R510 with a pair of
> 6-core E5645 CPUs that "cpuid" shows the following for (in the dom0):
this is a westmere-ep CPU, which does not support rdseed
or rdrand. rdrand appeared in ivybridge (2 generations
later, with sandybridge in the middle.)
> >> and one more
> >>
> >> __sigaction_sigtramp(SIGILL...)
> >>
> >> Then, at the end:
> >>
> >> PSIG SIGILL SIG_DFL: code=ILL_ILLOPC, addr=0xedccbdf0, trap=2)
>
> Program was terminated due to an illegal opcode being detected in
> the gcm_ghash_4bit() assembly function:
yes. John, can you,
> Different to other asm code that e.g. properly detetects various VIS
> instructions that may or may not be available on the current CPU, the code
> in ghash-sparcv9.pl is plain sparcv9 code and can not be enabled for our
> sparc builds.
>
> Christos, can you disable all "modes" asm and request pu
Martin Husemann writes:
> On Sat, Apr 10, 2021 at 08:38:39AM +1000, matthew green wrote:
> > for a quick fix, this is OK, but long term, these are built
> > for sparc64 compat32 as well, and benefit from having this
> > code in place.
>
> I have seen that
Martin Husemann writes:
> On Sat, Apr 10, 2021 at 04:12:55PM +1000, matthew green wrote:
> > Martin Husemann writes:
> > > On Sat, Apr 10, 2021 at 08:38:39AM +1000, matthew green wrote:
> > > > for a quick fix, this is OK, but long term, these are built
> > &
Martin Husemann writes:
> On Sun, Apr 11, 2021 at 10:37:21AM +1000, matthew green wrote:
> > > How can you invoke a make to test this (besides a full build.sh and adding
> > > some output to the makefiles)?
> > > Or: can you just fix and request pullup ;-)
> &
hi folks.
(please reply privately to this spams-many-lists message, and
i will keep src/external/gpl3/gcc/README.gcc10 updated with
the latest status.)
i've just commited the final parts that make most platforms build
(and many run) with GCC 10 as the system compiler.
i've tested these systems
hi folks.
i've switched the alpha, amd64, sparc*, riscv*, ia64, and vax ports
have all been switched to GCC 10.
please send-pr or send email here about problems you encounter.
thanks.
.mrg.
"Thomas Mueller" writes:
> > i've switched the alpha, amd64, sparc*, riscv*, ia64, and vax ports
> > have all been switched to GCC 10.
>
> > please send-pr or send email here about problems you encounter.
>
> > thanks.
>
>
> > .mrg.
>
> What about the i386 port?
see RE
> > - build.sh with no -u (update), and set -V HAVE-GCC=10 as a
> >option. this ensures that everything is actually rebuilt
> >with the new compiler.
>
> I'm guessing that should be "-V HAVE_GCC=10", but even so I just can't
yup!
> get this to build. I always get the message "cc: error:
i saw a report that netbsd-8 can't be built on -current but i'm
not finding it right now.
i can confirm this is the case. you can work around the GCC 10
inspired issues for now with eg:
./build.sh -V HOST_CFLAGS='-fcommon -O2'
but then there is a -current regex vs -8 file magic regex issue.
matthew green writes:
> i saw a report that netbsd-8 can't be built on -current but i'm
> not finding it right now.
>
> i can confirm this is the case. you can work around the GCC 10
> inspired issues for now with eg:
>
>./build.sh -V HOST_CFLAGS='-fc
> Here (or pkgsrc-users?) seems ok. But my question would be if cgal
> documents that it needs a C++11 compiler, in which case this change is
> right regardless, or if it's supposed to be ok with C++03, in which case
> maybe something else is wrong.
the release notes from 2017 say that demos requ
1 - 100 of 294 matches
Mail list logo
