Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 28 May 2016 at 14:30, Mark Millard wrote: > On 2016-May-28, at 12:03 PM, Adrian Chadd wrote: > >> [snip] >> >> hi, >> >> please don't patch the ports compiler assumptions about things like >> this. We should be targeting external toolchains on OSes (eg macosx) >> where it

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 5/28/2016 12:03 PM, Adrian Chadd wrote: > [snip] I beg of you to *stop* snipping all context. > > hi, > > please don't patch the ports compiler assumptions about things like I said it was not right, and was an experiment. > this. We should be targeting external toolchains on OSes (eg

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-May-28, at 12:03 PM, Adrian Chadd wrote: > [snip] > > hi, > > please don't patch the ports compiler assumptions about things like > this. We should be targeting external toolchains on OSes (eg macosx) > where it may already generate freebsd binaries and as such we should > be calling

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[snip] hi, please don't patch the ports compiler assumptions about things like this. We should be targeting external toolchains on OSes (eg macosx) where it may already generate freebsd binaries and as such we should be calling the compiler/linker with all the flags it needs. Having a patched

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Top post of failure to get rid of /usr/local/include from devel/powerpc64-gcc search list.] I have tried: > # svnlite diff /usr/ports/devel/powerpc64-gcc/ > Index: /usr/ports/devel/powerpc64-gcc/Makefile > === > ---

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

--with-local-prefix=/usr was insufficient to avoid /usr/local/include in the search list in powerpc64-gcc: > ignoring duplicate directory > "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include" > ignoring nonexistent directory >

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-May-27, at 7:04 PM, Mark Millard wrote: > FYI. . . > > I expect that building gcc49 with: > > + --with-local-prefix=/usr \ > > will help with system build activities via gcc49/g++49 by avoiding > /usr/local/include interfering. > > But I also expect that various port

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

FYI. . . I expect that building gcc49 with: + --with-local-prefix=/usr \ will help with system build activities via gcc49/g++49 by avoiding /usr/local/include interfering. But I also expect that various port builds based on that same gcc49/g++49 will have problems from not

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 5/27/2016 5:15 PM, Mark Millard wrote: > + --with-local-prefix=/usr/include \ > > looks wrong to me. The default is not /usr/local/include but just /usr/local > . Quoting https://gcc.gnu.org/install/configure.html : > > --with-local-prefix=dirname > Specify the installation

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-May-27, at 4:48 PM, Bryan Drewery wrote: > On 3/31/2016 8:33 PM, Mark Millard wrote: >> I appears that C++ needs its own override for where to find C++ header >> before looking in the gcc49 specific places. > > Yes, the hacks for that are builtin already. Passing C_INCLUDE_PATH and >

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 3/31/2016 8:33 PM, Mark Millard wrote: > I appears that C++ needs its own override for where to find C++ header before > looking in the gcc49 specific places. Yes, the hacks for that are builtin already. Passing C_INCLUDE_PATH and others may break it. > These sorts of odd, hard to avoid

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-Apr-2, at 3:59 PM, Mark Millard wrote: > [My testing for the likes of the below does not yet extend outside powerpc64 > contexts.] > > For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc use with, > say, gcc49 materials as the so-called "host" compiler tools I have not

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[My testing for the likes of the below does not yet extend outside powerpc64 contexts.] For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc use with, say, gcc49 materials as the so-called "host" compiler tools I have not yet found a way around using the workaround: > # ls -l

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc has for the default include search places:] powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in /usr/local/include before /usr/include : see below. > # portmaster --list-origins > . . . > devel/powerpc64-xtoolchain-gcc > . .

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric wrote: > On 01 Apr 2016, at 00:44, Warner Losh wrote: > > > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery > wrote: > >> I didn't realize the ports compiler was defaulting /usr/local/include

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 01 Apr 2016, at 00:44, Warner Losh wrote: > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery wrote: >> I didn't realize the ports compiler was defaulting /usr/local/include >> into the search path now. It does not have /usr/local/lib in the >> default

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-Mar-31, at 8:14 PM, Mark Millard wrote: > > On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > >> This should be fine with my fix too. >> >> Trying add this to your make.conf for now: >> >> CFLAGS.gcc+= -isystem /usr/include > > [Context note: I normally use: > >>

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > This should be fine with my fix too. > > Trying add this to your make.conf for now: > > CFLAGS.gcc+= -isystem /usr/include [Context note: I normally use: > WITHOUT_CROSS_COMPILER= > # > WITH_FAST_DEPEND= > WITH_LIBCPLUSPLUS= > WITH_BOOT= >

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > This should be fine with my fix too. > > Trying add this to your make.conf for now: > > CFLAGS.gcc+= -isystem /usr/include I'll try that. But just FYI: here are the lists of files from gcc49 that having /usr/include

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 3/31/16 4:42 PM, Mark Millard wrote: > On 2016-Mar-31, at 3:34 PM, Bryan Drewery wrote: >> > #include "..." search starts here: >> > #include <...> search starts here: >> > /usr/local/lib/gcc49/include/c++/ >> > /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 >> >

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 2016-Mar-31, at 3:34 PM, Bryan Drewery wrote: > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc49/include/c++/ > /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 > /usr/local/lib/gcc49/include/c++//backward >

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

> On Mar 31, 2016, at 4:34 PM, Bryan Drewery wrote: > I didn't realize the ports compiler was defaulting /usr/local/include > into the search path now. It does not have /usr/local/lib in the > default library path as far as I can tell. It's also broken for its > -rpath

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 3/31/16 3:02 PM, Mark Millard wrote: >> > We likely just need to prioritize /usr/include over /usr/local/include >> > for these phases, which gcc49 may have backwards since it has its prefix >> > set to /usr/local from the ports build. Yup this is the problem with using the ports compiler as

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

> On 2016-Mar-31, at 2:32 PM, Bryan Drewery wrote: > > On 3/31/16 2:23 PM, Mark Millard wrote: >> I use the likes of: >> # diff -rq /usr/include /usr/local/include | grep "^Files " >> to find what to rename for the duration of the system builds. >> >> An example of what happens without

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 3/31/16 2:23 PM, Mark Millard wrote: > I use the likes of: > >> > # diff -rq /usr/include /usr/local/include | grep "^Files " > to find what to rename for the duration of the system builds. > > An example of what happens without the renames is below but I first note the > use of the name

svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

Recent changes have been trying to make things like powerpc64-xtoolchain-gcc/powerpc64-gcc work better for buildworld/buildkernel. I happen to do this on a powerpc64 context so the "cross build" is actually self-hosted. No gcc 4.2.1 is present and clang 3.8.0 and before have code generation

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

The src.conf that I listed in the original message included the line: > X_COMPILER_TYPE=gcc So I'd already done that. Other suggestions? === Mark Millard markmi at dsl-only.net On 2016-Mar-31, at 2:26 PM, Bryan Drewery wrote: On 3/31/16 2:23 PM, Mark Millard wrote: >

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

On 3/31/16 2:23 PM, Mark Millard wrote: > Should there be xtoolchain usage notes about avoiding /usr/local/include name > conflicts and/or about how to assign CC/CXX/XCC/XCXX? > > As long as I use gcc49 tools for CC and CXX I still must do things like > renaming files in /usr/local/include to

Still problems with ATAPI

(dmesg.boot attached) ATAng will no longer recognize the DVD-ROM device on ata1-master. This is without atapicam. The CD-RW drive at ata1-slave is OK, and is being assigned to acd0 now. Incidentally, when did the hw.ata.* sysctls change? Copyright (c) 1992-2003 The FreeBSD Project.

Re: Still problems with ATAPI

It seems Conrad J. Sabatier wrote: ATAng will no longer recognize the DVD-ROM device on ata1-master. This is without atapicam. The CD-RW drive at ata1-slave is OK, and is being assigned to acd0 now. OK, from you dmesg: ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0xd0

Still problems with ULE

I gave ULE another try just now, following your recent commits, and I'm seeing even worse problems: At boot time when the X server is loading, disk activity occurs briefly about once every 2 seconds; the mouse is active briefly at the same time, and nothing much else happens for about a minute

Re: Still problems with ULE

On Mon, 10 Feb 2003, Kris Kennaway wrote: I gave ULE another try just now, following your recent commits, and I'm seeing even worse problems: At boot time when the X server is loading, disk activity occurs briefly about once every 2 seconds; the mouse is active briefly at the same time, and

Re: Still problems with ULE

On 2003-02-10 20:36 +, Jeff Roberson wrote: On Mon, 10 Feb 2003, Kris Kennaway wrote: I gave ULE another try just now, following your recent commits, and I'm seeing even worse problems: At boot time when the X server is loading, disk activity occurs briefly about once every 2

Re: Still problems with ULE

On Mon, Feb 10, 2003 at 08:36:50PM -0500, Jeff Roberson wrote: Very weird. Is this on UP or SMP? This is on UP. I can still break into DDB, so let me know if you want me to run console tests (no serial console though). Kris msg52192/pgp0.pgp Description: PGP signature

Re: Still problems with PCCARD NICs

Hi ! I have the same problem with my Xircom CreditCard 10/100 Ethernet on FreeBSD 5.0 release that also uses the xe driver. The computer is a Dell inspiron 7500. If you have reached a solution please let me know. my boot -v message is attached: /Dan Jan 21 14:16:35 firebat kernel: Copyright (c)

still problems

I cvsupped to RELENG_5_0 I try to compile a kernel: linking kernel.debug udbp.o: In function `udbp_attach': /admins/src/sys/dev/usb/udbp.c:358: undefined reference to `ng_newtype' /admins/src/sys/dev/usb/udbp.c:364: undefined reference to `ng_make_node_common' /admins/src/sys/dev/usb/udbp.c:367:

Re: still problems

Forgoet it, I'm double stupid, I just read the udbp man page :) it requires options NETGRAPH. doh! On Sat, 18 Jan 2003, Trish Lynch wrote: I cvsupped to RELENG_5_0 I try to compile a kernel: linking kernel.debug udbp.o: In function `udbp_attach': /admins/src/sys/dev/usb/udbp.c:358:

Re: Still problems with PCCARD NICs

In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : 2. 3Com 3c905. this is a cardbus card? : # ifconfig xl0 mediaopt 100baseTX : ifconfig: SIOCSIFMEDIA: Device not configured User error: You must specify media if you are going to specify media opt.

Re: Still problems with PCCARD NICs

Date: Mon, 13 Jan 2003 11:24:14 +1030 From: Greg 'groggy' Lehey [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] I haven't done much with PCCARD on -CURRENT lately. Last time I tried, a couple of months ago, I got repeated freezes on the two 100 Mb/s NICs I have. I've just built a kernel as

Still problems with PCCARD NICs

I haven't done much with PCCARD on -CURRENT lately. Last time I tried, a couple of months ago, I got repeated freezes on the two 100 Mb/s NICs I have. I've just built a kernel as of about 30 hours ago, and I find: 1. Xircom RealPort RE-100 (xe driver). Comes up with unidentified media.

Re: Still problems with PCCARD NICs

On Sun, 2003-01-12 at 18:54, Greg 'groggy' Lehey wrote: I haven't done much with PCCARD on -CURRENT lately. Last time I tried, a couple of months ago, I got repeated freezes on the two 100 Mb/s NICs I have. I've just built a kernel as of about 30 hours ago, and I find: 2. 3Com 3c905.

Re: Still problems with latest ATA

It seems Kris Kennaway wrote: My CDROM still refuses to work with cdcontrol, although the 30-seconds of kernel spinning is now fixed. Trying to play a track gives: acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 I'll bet this drive doesn't support PLAY_BIG but only PLAY_MSF. The

Re: Still problems with latest ATA

On Sun, 30 Jan 2000, Soren Schmidt wrote: Trying to play a track gives: acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 I'll bet this drive doesn't support PLAY_BIG but only PLAY_MSF. The problem here is that PLAY_MSF's parameters are either in binary or in BCD, but you dont

Re: Still problems with latest ATA

It seems Kris Kennaway wrote: On Sun, 30 Jan 2000, Soren Schmidt wrote: Trying to play a track gives: acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 I'll bet this drive doesn't support PLAY_BIG but only PLAY_MSF. The problem here is that PLAY_MSF's parameters are

Still problems with latest ATA

My CDROM still refuses to work with cdcontrol, although the 30-seconds of kernel spinning is now fixed. Trying to play a track gives: acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 One of my WDC's still falls back to PIO mode at boot time (see previous messages, nothing has changed).