Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
From: Jaromír Doleček I very strongly object to against anything appeasing any SJW or PC trolls, and I'm against removing those quotes. Took this thread long enough to play "those evul Ess Jay DoubleUs" card. Good hint that I can ignore the rest, but in any case. Any time I see someone use "SJW", which has completely lost its original meaning, I substitute with: "Nobody would be willing to make accommodations for me if I were truly hurt or offended by something, so why should I make accommodations for others?" Ditto with the person who _very_ helpfully told Maya to "grow some balls". History needs to be remembered, and learnt from. Facts need to be told and faced. Great, do it in a freakin museum or a history textbook, not within the data files of a Unix program. It is a great threat to our modern society that certain groups of people today are so intent on silencing dissent or unconfortable voices. People don't live in a vacuum. Having good technical or orator skills does not insulate someone from criticism for abhorrent views. And Hitler's actions in life especially cannot be written off as a difference in opinion, dissent, or otherwise up for debate. The implications of his quotes matter. And if you agree w/ that, see previous paragraph. -- William D. Jones thor0...@comcast.net
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
I think you may better understand it if you consider that "Hitler was bad" is always the default context, regardless of whatever the isolated quote from him is. Apparently not, which is why I've seen multiple people in this thread say he was a brilliant orator and "more/better quotes from him should be in the db". You can argue that's objectively correct; he was manipulative and knew how to get others to do his bidding. But again, a silly Unix program is not the place to bring attention to this fact. I don't see how "Well, he said some interesting/quotable things" or "his artwork was interesting" is anything but a _distraction_ from the fact he was a horrible human being. Nor do I see how either of those factoids carry anywhere near as much weight about his character as his actions in life. So I can't really blame those that are, have been and will be offended. -- William D. Jones thor0...@comcast.net
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
Seriously, if you don't know who Hitler was and why quotes from him should be seen in a certain perspective, you should take a lesson on modern world history and not run around being offended. It's not about being offended, it's about normalizing/trivializing his impact. Evidence: Clearly, little thought was put into whether these quotes belong in a silly Unix program, rather than history textbooks or museums which are equipped to temper the intended impact of the Nazi party. -Original Message- From: Joerg Sonnenberger Sent: Saturday, November 18, 2017 12:23 PM To: current-users@NetBSD.org Subject: Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735] On Sat, Nov 18, 2017 at 01:21:25PM +0100, Rhialto wrote: I checked our fortune cookies database, and I was appalled to notice that we do have the same quotes there. Apart from those quotes being wholly inappropriate in a list of funny quotes, they are probably illegal in Germany (where I now happen to live). I don't get why someone would be appalled by many of them. There is certainly nothing illegal about them, even here in Germany. Seriously, if you don't know who Hitler was and why quotes from him should be seen in a certain perspective, you should take a lesson on modern world history and not run around being offended. I hereby propose to remove them (but not remove all fortunes). I find myself strongly objecting to that. Joerg -- William D. Jones thor0...@comcast.net
Re: Booting BSD on a libreboot system - documentation needed
Although, I'm ill-equipped to work on this, I am also curious about BSD support for libreboot. What is blocking EFI support? -Original Message- From: Swift Griggs Sent: Friday, September 30, 2016 5:42 PM To: Leah Rowe Cc: current-users@NetBSD.org Subject: Re: Booting BSD on a libreboot system - documentation needed On Fri, 30 Sep 2016, Leah Rowe wrote: Libreboot is a free/opensource BIOS/UEFI implementation/replacement. GNU/Linux is supported well, but people have recently started figuring out how to boot BSD. Very cool. I for one will check it out. If I'm not mistaken, NetBSD's bootloader doesn't yet support EFI. It sounds like it's somewhat less jiggery-pokery than an MBR bootloader. Plus it just uses a regular FAT32 file system. I'm sure there are difficulties I'm not aware of, but I'm hoping for good things, soon. -Swift -- William D. Jones thor0...@comcast.net
Traversing the NetBSD Makefile Build System
As part of an experiment, I wish to play around with certain MAKECONF
variables that change how NetBSD is built on a cross host (particularly
EXTERNAL_TOOLCHAIN). I figure it would be a good idea to figure out how the
Makefile framework works and how targets are chosen. However, I've run into
a wall that likely has a simple solution I'm overlooking. Perhaps someone
can alleviate my confusion
I'm starting with the tools directory: the top-level Makefile cds into tools
using the MAKEDIRTARGET defined in bsd.own.mk. In the tools directory, the
default target is build_install. build_install is defined in
bsd.build_install.mk. This is where I run into issues. From what I
understand, build_install will take all subdirectories defined using
${SUBDIR}, split them into groups separated by wait commands (though it
looks like the .WAITs are filtered out), and then executes $MAKEDIRTARGET
using the current directory as the destination of cd, and dependall-*
(where * is a directory name) as the target.
I cannot find where dependall-* is actually defined for each set of tools to
build. How does build_install know to traverse into subdirectories and
actually build each executable then?
As always, thanks in advance for any help.
Sincerely,
--
William D. Jones
thor0...@comcast.net
Compiling NetBSD using PCC- Round 2
../destdir/i386-pcc -R ../releasedir/i386-pcc tools kernel=GENERIC release As always, thanks in advance for any help! Sincerely, -- William D. Jones thor0...@comcast.net
Compiling NetBSD using PCC- Round 2
MKPCC=yes MKGCC=no HAVE_LIBGCC=no HAVE_GCC=0 #Define if MKGCC=no HAVE_PCC=1 MKCXX=no ./build.sh -m i386 -U -O ../objdir/i386-pcc -T ../tools/pcc -D ../destdir/i386-pcc -R ../releasedir/i386-pcc tools kernel=GENERIC release As always, thanks in advance for any help! Sincerely, -- William D. Jones thor0...@comcast.net
Patch Submitting Ettiquite
Hello all, Sooner or later, I should have a patch to submit to the NetBSD source tree- for an old driver that relatively few people care about (but is meant as an exercise for writing a driver, possibly adding more esoteric hardware). From reading https://www.netbsd.org/contrib/#submit-new-code, the procedure seems to be to submit a problem report. On the mailing list, however, I've seen people submit/try patches using diffs either as attachments or directly in email messages. This seems to make sense because more people (besides kernel developers) are likely to see the patch sooner and either give feedback or try the patch. I'm not sure whether those who posts diffs to the mailing list also post diffs as problem reports, but I assume that's dependent on the size of the change. Is it okay to send/notify patches sent as a problem report to current-users (or the relevant port) as well? Again, just want to make sure before I send *any* patch- not just one for esoteric hardware! :) Sincerely, -- William D. Jones thor0...@comcast.net
Re: Bug in nvi: Adding Tags to the stack, removing, then re-adding causes Segmentation Fault
Bug was fixed in current since I first reported this bug (in fact, it was fixed beforehand). Was there a regression? -Original Message- From: Christos Zoulas Sent: Friday, February 13, 2015 11:03 AM To: Patrick Welche Cc: current-users@netbsd.org Subject: Re: Bug in nvi: Adding Tags to the stack, removing, then re-adding causes Segmentation Fault On Feb 13, 1:53pm, pr...@cam.ac.uk (Patrick Welche) wrote: -- Subject: Re: Bug in nvi: Adding Tags to the stack, removing, then re-addin | On Thu, Nov 27, 2014 at 08:04:58PM +, Christos Zoulas wrote: | In article 14E87758ADB246A58C5FAE0359DE5506@WilliamTHINK, | William D. Jones thor0...@comcast.net wrote: | 2. For a given C source tree, run ctags -t path/to/*.c path/to/*.h. Open | nvi. Position the cursor over a tag, press ^], then ^T twice, or ^T, then | ^]. nvi will segfault (near) consistently. This behavior can also be | duplicated using the corresponding cscope commands in ex (either :tagpop or | :cs fi [search type] [tag] will also cause a segfault). | | I can't reproduce this, can you provide an exact recipe? | | Could this be shell dependent - c.f. bin/42372 ? The only way I can think that the choice of shell affects the child's memory layout causing such execution differences is because the environment variable layout is different, or the initial open file descriptor set is different. The first is my guess, the second would be more exotic. env(1) is your friend debugging such problems. christos -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Panic on i386 kernels using legitimate 486's/workaround.
Hello all, I know a few users including myself run NetBSD's on 486's and old systems just to keep them doing useful work, so I thought I would signal-boost a problem I had with a (long overdue) kernel upgrade that I had this morning (see also: http://gnats.netbsd.org/49104), so that it's easier to find the solution for now until (hopefully) a patch gets accepted back into the main tree. The relevant bug report is here: http://gnats.netbsd.org/49124 Running kernels after August or so result in a nice panic on 486's: privileged instruction fault in supervisor mode. In short, a change back in August disabled a check for a 486 CPU that causes an illegal instruction on 486's (RDTSC). The submitter of the above bug report adds the check back in, so we can now use 486 CPUs again- a very important CPU target for NetBSD :) It does not appear there has been any activity on the bug report since then. I hope a workaround or solution gets accepted back into the tree so that 486 support remains working (akin to continued 68k support). While I understand that someone running NetBSD on a 486 is likely to use current and not an official release, I know I would've been frustrated if the first thing I saw 6 months ago was a panic that could be fixed by a single line of C code. Sincerely, -- William D. Jones
Detecting kernel version upgrade
Hello all, I use a cron script to pull changes from CVS and rebuild the NetBSD distributions for a variety of architectures each night. As expected, builds do not always succeed because the source tree is not guaranteed to compile. Most of these errors will fix themselves eventually. However, occasionally, I will run into errors that require a full rebuild. In particular, any time there is a kernel version upgrade, the builds will fail until I manually run a script to rebuild distributions from the beginning. As an example, such an error may look as follows: === 8 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/X11R7/lib/libxcb-randr.so.0 ./usr/X11R7/lib/libxcb-randr.so.0.1 ./usr/X11R7/lib/libxcb-sync.so.0 ./usr/X11R7/lib/libxcb-sync.so.0.1 ./usr/X11R7/lib/libxcb.so.1 ./usr/X11R7/lib/libxcb.so.1.1 ./usr/lib/libssh.so.22 ./usr/lib/libssh.so.22.0 = end of 8 extra files === For space reasons, I do not capture the output from each invocation of build.sh each night :P. I also cannot always check the build logs from my cron scripts each night (sometimes once a week). I've been looking into trying to autodetect kernel version upgrades so I can full rebuild without needing to manually run the script. The best I've come up with is the following grep command: ./gen_i386build.sh -u 2 /dev/null | grep -q Files in DESTDIR but missing from flist.; echo $? Ignoring the contrived example above, this requires saving output to an intermediate file; I need both the output of build.sh and grep to detect whether to rebuild, fail, or continue, so a pipe in non-bash will not work in my cron scripts. While I can't guard against all errors, is it possible to programmatically (and reliably) detect when a kernel version upgrade occurred so I can tailor my cron scripts to do a full rebuild during those cases? Even better would be to detect a kernel version upgrade BEFORE beginning the builds :). As always, thanks in advance for any help. Sincerely, -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Bug in nvi: Adding Tags to the stack, removing, then re-adding causes Segmentation Fault
Hello all, I'm attempting to debug a problem with the NetBSD version of nvi, and would like some feedback on how to progress from here. Specifically, I am able to consistently crash nvi under two circumstances: 1. Run the mkexrc command with a file name after opening. SIGABRT is generated. 2. For a given C source tree, run ctags -t path/to/*.c path/to/*.h. Open nvi. Position the cursor over a tag, press ^], then ^T twice, or ^T, then ^]. nvi will segfault (near) consistently. This behavior can also be duplicated using the corresponding cscope commands in ex (either :tagpop or :cs fi [search type] [tag] will also cause a segfault). I am not sure if these bugs are present in the git version of nvi-1.81.6, and I am currently unable to test- the git repo versions of nvi lack a configure or autogen script, and I'm not in the position to install autotools to generate one. My NetBSD source tree is currently on a different machine. Without completely circumventing the build.sh framework (I've had problems in the past running make directly from within the source tree after a build.sh build), what is the best way to compile a debugging version of nvi to test without completely bloating the source tree? I suppose MKDEBUG in mk.conf would be the best option, and just copy it manually to my current machine (or let sysupgrade handle it)? As always, thanks for any help/feedback! Sincerely, -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Intel HD Graphics 3000 support/getting started
With my current userland, the hardware is detected by Xorg, but Xorg falls back to using the VESA driver. The only resolution available there is 1024x768... on a widescreen monitor. It's not a pleasant experience. Am I supposed to be getting more resolutions with the current Intel Xorg driver? Using xrandr to set them doesn't work either- I get errors trying to program the CRTC (don't remember the errors specifically offhand). In essence, the 6.1.5 kernel and X server both WORK on my hardware, just that I'd be hard pressed to get any work done on it. Also 7-beta userland with a current kernel? Is there a tar.gz file of a stable 7-beta userland (one that will not be changing daily) available on the FTP server? -Original Message- From: Andrew Cagney Sent: Friday, November 21, 2014 8:59 PM To: William D. Jones Cc: current-users@netbsd.org Subject: Re: Intel HD Graphics 3000 support/getting started What happens if you boot a current kernel (with your 6.1.5 userland)? It can't be worse, and if it works and doesn't crash, would provide a useful data point for kern/49368 Otherwise, I know a 7-beta userland with a current kernel do work for that hardware. -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Intel HD Graphics 3000 support/getting started
Hello all, I know based on previous posts that Intel graphics drivers are available in current. However, I'm currently a bit puzzled on how to get started with these drivers due to lack of information about what specific drivers are available, how to enable them, and how to setup X so I get beyond 1024x768 resolution. To start, I have a Lenovo Thinkpad W520 as my laptop, with Intel HD Graphics 3000, so getting a new gfx card is infeasible. Is this particular card supported in amd64 current at this time? If so, what is the easiest way to get started if my current NetBSD installation is 6.1.5 (which does not have such support and limits me to a 4:3 ratio on a 16:9 monitor :P)? I know for now that I should disable acceleration based on Firefox issues, which were mentioned in another post on this list. If it's not currently supported, well- I just have to wait for now :P. nv doesn't support my discrete gfx card (Quadro 2000M). Thanks in advance for any help you can give me! Sincerely, -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
I'm not sure why if MKPCC=yes and HAVE_PCC=yes, ./build.sh still wants
libgcc, but I'll look into it. In any case, the solution I proposed is
simply a stopgap until PCC can compile userland.
Right now, there's at least four ways NetBSD can in theory be built:
GCC tools, GCC release
LLVM tools, LLVM release (undocumented?)
PCC tools, PCC release
EXTERNAL tools, GCC release
I figured getting GCC tools to compile PCC- again, as a stopgap solution-
should be as simple as swapping the GCC target with the PCC target, in the
appropriate Makefile. Since GCC can compile PCC just fine, all other
dependencies could be left alone. However, this does not appear to be the
case. Even after modifying bsd.mk.own and lib/Makefile, if MKPCC=yes,
MKGCC=no, and HAVE_GCC=48 (indeed I had to move the .endif in bsd.own.mk-
good catch), the build complains about a missing libgcc.
I suppose the only option for now is to compile both and just delete GCC
manually after install.
-Original Message-
From: Iain Hibbert
Sent: Monday, August 18, 2014 12:23 PM
To: William D. Jones
Cc: current-users@netbsd.org
Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
On Mon, 18 Aug 2014, William D. Jones wrote:
also, you should probably use HAVE_GCC=48 since that is the version in
use, and the version number is checked sometimes for various features
I removed the conditional logic for MKGCC. I'll give a more complete
update
later, but believe it or not, setting HAVE_GCC=48 while MKGCC=no and
MKPCC=yes
actually causes the variable ${EXTERNAL_GCC_SUBDIR} (lib/Makefile, line 9)
to
not be expanded AT ALL when searching for libgcc to add to the list of
build
targets. This baffles me, because bs.own.mk in $NETBSD_SRC/share/mk has an
else statement which should prevent this at line 86-88, but the logic is
not
firing. Setting HAVE_GCC=4 SEEMS to solve the problem- at least, libgcc
gets
added to the list of targets and is found.
I think there is too much MKGCC conditional logic
Firstly, bsd.own.mk doesn't set EXTERNAL_GCC_SUBDIR if MKGCC=no .. the
.endif could move up a paragraph I think.
Then inside the libgcc directory there is some logic. I think the libgcc
directory should not be descended into if it is not required, rather than
descending into it and deciding we want out.
iain
--
William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
thor0...@comcast.net
Message sent using 'Windows Live Mail' client.
Re: Adding firmware for USB ethernet to RPI install image
The file size error disappeared on its own without me having to change MEMORY_DISK_ROOT_SIZE (I have not done a CVS checkout since this morning). I'm not sure I understand, but I'll take my luck and run with it :P. -Original Message- From: William D. Jones Sent: Monday, August 18, 2014 11:49 AM To: Martin Husemann Cc: port-...@netbsd.org Subject: Re: Adding firmware for USB ethernet to RPI install image Well, indeed I do have a rather long path that I use to get to my source tree, but I'm a bit skeptical that it added 302,700 bytes to my image. I don't have the means to verify it right now, so for the time being I'll just increase the size of MEMORY_DISK_ROOT_SIZE again in my own personal tree so ./build.sh stops complaining. -Original Message- From: Martin Husemann Sent: Monday, August 18, 2014 8:46 AM To: William D. Jones Cc: port-...@netbsd.org Subject: Re: Adding firmware for USB ethernet to RPI install image On Mon, Aug 18, 2014 at 08:06:50AM -0400, William D. Jones wrote: As of today at 8:05 AM EDT today, I get the following error when compiling release for RPI: got symbols from netbsd-RPI_INSTALL.tmp mapped netbsd-RPI_INSTALL.tmp armv6--netbsdelf-eabihf-mdsetimage: fs image (9113600 bytes) too big for buffer (8806400 bytes) Was there changes made since the commit 3 days ago that further increased the fs image size? Hmm, the autobuild just completed successfull, so I guess not. However, if the size is borderline and you are not using MKREPRO=yes, a long path to the source directory might cause a few strings embeded in binaries to get slight longer - in that case we should bump the size again slightly. But I think Jörg is currently working on getting rid of this hard coded limits, so maybe this will not be needed any more. Martin -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client. -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
Then what's the best course of action? I'd just like to get a distribution with PCC instead of GCC for an old machine with limited disk space... it doesn't matter to me if PCC cannot compile all of userland. I was under the impression that PCC was able to compile a minimum working system (kernel and minimum userland) at some point in the past, but now needs to be updated so that it can compile a working distribution again. -Original Message- From: Iain Hibbert Sent: Wednesday, August 13, 2014 10:37 AM To: William D. Jones Cc: current-users@netbsd.org Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error? On Mon, 11 Aug 2014, William D. Jones wrote: 2. When attempting to build userland with the following mk.conf, I receive an error regarding a missing libgcc: COPTS=-Os -Wno-error=uninitialized -Wno-error=maybe-uninitialized #This is irrelevant, more than likely MKPCC=yes MKGCC=no HAVE_GCC=4 #Define if MKGCC=no #HAVE_PCC=1 Essentially, I want to use GCC to build a userland with PCC only for my 486 machine to save space and compiling time.I think this is a dependency error that the build system misses; it seems as if MKGCC isn't honored for certain Makefiles. Does anyone familiar with build.sh internals have any idea on how to fix this? I rather suspect this is unknown territory, with half-grown features lying in wait to trap the unwary. In the beginning, PCC support started to be added in the style of the GCC support, but I think this is not fully tested (since PCC cannot yet build everything). Latterly, Joerg has been working on LLVM support and he has added the AVAILABLE_COMPILER functionality, but there are still remnants of the previous setup, and I am not sure if there is yet a final design for providing a NetBSD release with a different compiler, though as far as I know, LLVM/Clang should be capable enough (there are still some UNSUPPORTED_COMPILER.clang instances in the GCC code) regards, iain -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
The error to which I refer to (cannot find -lgcc) also occurs now, even when I set HAVE_PCC=1 while building libc... it seems that there is a depedency problem that has crept into the NetBSD source tree the past few days, because me receiving complaints about a missing libgcc when only building the PCC tools only started in the 2 to 4 days. -Original Message- From: Iain Hibbert Sent: Wednesday, August 13, 2014 10:37 AM To: William D. Jones Cc: current-users@netbsd.org Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error? On Mon, 11 Aug 2014, William D. Jones wrote: 2. When attempting to build userland with the following mk.conf, I receive an error regarding a missing libgcc: COPTS=-Os -Wno-error=uninitialized -Wno-error=maybe-uninitialized #This is irrelevant, more than likely MKPCC=yes MKGCC=no HAVE_GCC=4 #Define if MKGCC=no #HAVE_PCC=1 Essentially, I want to use GCC to build a userland with PCC only for my 486 machine to save space and compiling time.I think this is a dependency error that the build system misses; it seems as if MKGCC isn't honored for certain Makefiles. Does anyone familiar with build.sh internals have any idea on how to fix this? I rather suspect this is unknown territory, with half-grown features lying in wait to trap the unwary. In the beginning, PCC support started to be added in the style of the GCC support, but I think this is not fully tested (since PCC cannot yet build everything). Latterly, Joerg has been working on LLVM support and he has added the AVAILABLE_COMPILER functionality, but there are still remnants of the previous setup, and I am not sure if there is yet a final design for providing a NetBSD release with a different compiler, though as far as I know, LLVM/Clang should be capable enough (there are still some UNSUPPORTED_COMPILER.clang instances in the GCC code) regards, iain -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
=${this:-.}; echo ${target} === ${show%/}${1:+ (with: $@)}; cd
${real} /mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this}
$@ ${target}; }; _makedirtarget libatf-c++ dependall
*** Error code 1
Stop.
nbmake[6]: stopped in /mnt/lfs/NetBSD-CVS/src/external/bsd/atf/lib
*** Failed target: dependall-../external/bsd/atf/lib
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=lib/;
real=/mnt/lfs/NetBSD-CVS/src/lib ;; *) this=lib/${dir}/;
real=/mnt/lfs/NetBSD-CVS/src/lib/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget ../external/bsd/atf/lib dependall
*** Error code 1
Stop.
nbmake[5]: stopped in /mnt/lfs/NetBSD-CVS/src/lib
*** Failed target: build_install
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=lib/;
real=/mnt/lfs/NetBSD-CVS/src/lib ;; *) this=lib/${dir}/;
real=/mnt/lfs/NetBSD-CVS/src/lib/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget . dependall-npf
dependall-../external/bsd/atf/lib dependall-libform dependall-libmenu
dependall-libradius dependall-librump
dependall-../crypto/external/bsd/heimdal/lib
dependall-../crypto/external/bsd/openssh/lib
dependall-../crypto/external/bsd/netpgp/lib
dependall-../external/bsd/libevent/lib dependall-../external/bsd/fetch/lib
dependall-../external/bsd/openldap/lib
*** Error code 1
Stop.
nbmake[4]: stopped in /mnt/lfs/NetBSD-CVS/src/lib
*** Failed target: do-lib
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=;
real=/mnt/lfs/NetBSD-CVS/src ;; *) this=${dir}/;
real=/mnt/lfs/NetBSD-CVS/src/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget lib build_install
*** Error code 1
Stop.
nbmake[3]: stopped in /mnt/lfs/NetBSD-CVS/src
*** Failed target: build
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=;
real=/mnt/lfs/NetBSD-CVS/src ;; *) this=${dir}/;
real=/mnt/lfs/NetBSD-CVS/src/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget . do-lib
*** Error code 1
Stop.
nbmake[2]: stopped in /mnt/lfs/NetBSD-CVS/src
*** Failed target: distribution
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=;
real=/mnt/lfs/NetBSD-CVS/src ;; *) this=${dir}/;
real=/mnt/lfs/NetBSD-CVS/src/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget . build NOPOSTINSTALL=1
*** Error code 1
Stop.
nbmake[1]: stopped in /mnt/lfs/NetBSD-CVS/src
*** Failed target: release
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=;
real=/mnt/lfs/NetBSD-CVS/src ;; *) this=${dir}/;
real=/mnt/lfs/NetBSD-CVS/src/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget . distribution
*** Error code 1
Stop.
nbmake: stopped in /mnt/lfs/NetBSD-CVS/src
ERROR: Failed to make release
*** BUILD ABORTED ***
william@xubuntu-ltrain:~/Projects/NetBSD-CVS/src$
In any case, it seems that pcc is getting closer to being able to compile
the NetBSD source tree. Perhaps it'll be ready in time for 7 release at this
rate (I'll file a problem report with the relevant patches if I can get a
GENERIC i386 kernel to build). I'll be on standby ready to apply patches
from the main PCC source tree if need be, and be I'll sure to send a diff of
my PCC tree (which has patches from the main source tree applied) vs the one
currently in NetBSD.
-Original Message-
From: Anders Magnusson
Sent: Saturday, July 26, 2014 3:43 AM
To: William D. Jones
Cc: current-users@NetBSD.org
Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
The commit messages are saved at marc.info, see
http://marc.info/?l=pcc-commit-listm=140628065609751w=2
To get a diff you can use cvs -d
:pserver:anonym...@pcc.ludd.ltu.se:/cvsroot rdiff -u -r1.376 -r1.377
pcc/cc/ccom/cgram.y
Should be directly applyable.
-- Ragge
Sincerely,
--
William D. Jones
Rowan University | ECE | 2012
Re: Missing files in DESTDIR- NetBSD version increment problem?
Although deleting the ./stand directory fixed the particular problem of missing files, I received another error regarding a file-size mismatch while writing installation media (sadly I forgot to copy the specific error). Deleting the entire DESTDIR and running build.sh from the beginning (besides rebuilding tools) fixed the problem. -Original Message- From: Martin Husemann Sent: Wednesday, August 06, 2014 10:10 AM To: Alan Barrett Cc: current-users@netbsd.org Subject: Re: Missing files in DESTDIR- NetBSD version increment problem? On Wed, Aug 06, 2014 at 04:02:25PM +0200, Alan Barrett wrote: Do you know what's wrong with the automated removal that was added in src/Makefile revision 1.309 on 2014-06-16? Oh, maybe I didn't have to do it since then - not sure, will look closer if it should happen again at next kernel bump. Martin -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Missing files in DESTDIR- NetBSD version increment problem?
-Original Message- From: Alan Barrett Sent: Wednesday, August 06, 2014 9:08 AM To: current-users@netbsd.org Subject: Re: Missing files in DESTDIR- NetBSD version increment problem? What are the exact build.sh commands that you use? Well, I use a wrapper script to separate directories but the exact commands are: ./build.sh -m evbearmv6hf-el -U -O ../objdir/evbearmv6hf-el-rpi -T ../tools/ -D ../destdir/evbearmv6hf-el-rpi -R ../releasedir/evbearmv6hf-el-rpi -j 4 for RPI (evbarmhf) ./build.sh -m i386 -U -O ../objdir/i386-std -T ../tools/ -D ../destdir/i386-std -R ../releasedir/i386-std (-u) -j 4 for GENERIC (i386) -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Missing files in DESTDIR- NetBSD version increment problem?
Sorry, I forgot to add: In both cases, the target is release. I can manually delete the old versions of the offending directories, but you say this should be done automatically? I still don't understand why the files for the new kernel version are missing... -Original Message- From: William D. Jones Sent: Wednesday, August 06, 2014 1:17 PM To: Alan Barrett Cc: current-users@netbsd.org Subject: Re: Missing files in DESTDIR- NetBSD version increment problem? Well, I use a wrapper script to separate directories but the exact commands are: ./build.sh -m evbearmv6hf-el -U -O ../objdir/evbearmv6hf-el-rpi -T ../tools/ -D ../destdir/evbearmv6hf-el-rpi -R ../releasedir/evbearmv6hf-el-rpi -j 4 for RPI (evbarmhf) ./build.sh -m i386 -U -O ../objdir/i386-std -T ../tools/ -D ../destdir/i386-std -R ../releasedir/i386-std (-u) -j 4 for GENERIC (i386) -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
Once again, sorry for the delay (I need to work on this). Just as a
heads-up, prepare_import.sh appears to be broken on my (Ubuntu-Linux)
machine, so I'll go ahead and just apply the diff we discussed that add
__restrict in arrays directly. This means that my copy of pcc will be a
hybrid between the currently imported pcc tree in NetBSD and the current
master on pcc.ludd.ltu.se- not sure if that will be an issue in practice
however. I'm going to do a clean build of my 486 machine's tree beforehand
with the pcc-20140706, however, to make sure my source tree is sane (see
Missing files in DESTDIR- NetBSD version increment problem?).
Have B. Harder's (Re: pcc build error that has been outstanding for a few
days...) changes been added to the main tree yet?
Perhaps PCC will be ready by the time NetBSD 7 is released- there's still
time to make sure it works!
The following shows the error:
william@xubuntu-ltrain:~/Projects/NetBSD-CVS/src/external/bsd/pcc$
./prepare-import.sh
+ set -e
+ [ ! -d work -o ! -d work/pcc ]
+ echo Removing pcc CVS directories...
Removing pcc CVS directories...
+ find work+ -typexargs rm -Rf
d -name CVS
+ echo Fixing file and directory permissions...
Fixing file and directory permissions...
+ find work -type d -exec chmod u=rwx,go=rx {} ;
+ find work -type f -exec chmod u=rw,go=r {} ;
+ echo Fixing RCS tags...
Fixing RCS tags...
+ grep -RL \$(NetBSD|Id).*\$ work
+ sed -e /\$NetBSD\$/d -e s,\$\(NetBSD[[::]].*\)\$,\1, -e
s,\(.*\)\$\(Id[[::]].*\)\$\(.*\),\1\2\3 \
\1\$NetBSD\$\3,
sed: -e expression #2, char 29: Invalid character class name
Sadly, I do not know enough about the context of replacements you are trying
to make to feel comfortable editing this myself.
Thanks again for your prompt responses!
-Original Message-
From: Iain Hibbert
Sent: Thursday, July 31, 2014 5:20 AM
To: William D. Jones ; Anders Magnusson
Cc: current-users@netbsd.org
Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
On 31 July 2014 06:13:00 BST, William D. Jones thor0...@comcast.net
wrote:
Sorry for the delay in getting back. Iain sent me an email suggesting a
checkout like you suggested, or using prepare_import.sh in
$NETBSD_ROOT/external/bsd/pcc/. Is prepare_import.sh up to date?
it should be fine for current PCC sources
Should
I
use that script instead, or are there subtle issues to using that
script
right now as opposed to applying the diff directly (I've read that
PCC's
files are kept in multiple parts of the source tree)?
I don't think that is the case, feel free to apply the diff directly
It seems as if
prepare_import.sh implements the equivalent of git subtree (track
repository from within repositoty).
I use that script to prepare the PCC sources before import to netbsd tree..
you can use it locally and get the same result as if I had imported a new
version
if you just apply one patch at a time there is always the chance you miss
something
--
William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
thor0...@comcast.net
Message sent using 'Windows Live Mail' client.
Re: pcc build error that has been outstanding for a few days...
Recently, I requested that the PCC tree in NetBSD be brought up to date to fix build failures (missing/outdated symbols, like __USE) while attempting to compile the toolchain (i.e. tools directory pcc, used to compile the NetBSD distribution) and distribution (i.e. version of PCC send to the target machine) for a customized, low-memory install. Considering the coincidental timing, it's very possible that the PCC build broke for amd64. I will test when I get the chance to see if I can duplicate your error; I need to clean up my scripts/fix some changes to my source tree that break generic x86/amd builds beforehand. -Original Message- From: B Harder Sent: Tuesday, July 29, 2014 12:57 PM To: current-users Subject: pcc build error that has been outstanding for a few days... I've got an error (transcribing): /usr/src/external/bsd/pcc/libexec/ccom/../../dist/pcc/arch/amd64/code.c: In function 'amd64_builtin_v_arg': /usr/src/external/bsd/pcc/libexec/ccom/../../dist/pcc/arch/amd64/code/c:622:8: error: variable 'ap' set but not used [-Werror=unused-but-set-variable] NODE *ap, *r, *dp; ^ I've re-run ./build.sh w/o -u to an implicit make clean is run, to no effect. Has this indeed been outstanding for a number of days, or am I missing a step to get over a hurdle? Cheers, -bch -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
Would it be a problem for you if the alias names were changed? --apb (Alan Barrett) Not at all- I'll just regenerate my scripts. I was concerned that the aliases would be removed period because technically they're redundant. The aliases however, make generating my scripts easier.
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
Do you have a patch that I can apply to my private NetBSD source tree of pcc for the time being? My pcc is compiled into the NetBSD tools directory, at which point it is used to compile the rest of the NetBSD source tree. -Original Message- From: Anders Magnusson Sent: Friday, July 25, 2014 5:41 AM To: William D. Jones ; Iain Hibbert Cc: current-users@NetBSD.org Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error? William D. Jones skrev 2014-07-25 07:58: Yes, I think you can set UNSUPPORTED_COMPILER.pcc in the Makefile and it will proceed using a different one For the time being, I'll make a note of all the tools that pcc cannot currently build, and set Makefiles accordingly. I'm not sure if these tools under gpl track upstream or not, so at least for tonight I'm not sure if feel comfortable changing the actual source code of binutils to make pcc compile it successfully. Although perhaps submitting a patch to binutils that undefines __restrict in arrays if pcc is being used is a possible solution for the time being. pcc accepted __restrict but not restrict in array declaration. I just added a yacc rule to pcc to accept both (to master tree). -- Ragge -- William D. Jones
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
Good going :D! As of 5 minutes ago, by setting HAVE_GCC=4, HAVE_PCC=1, MKGCC=no, and MKPCC=yes, I've successfully compiled the current pcc in the NetBSD source tree (using i486--netbsdelf-gcc) into my (global for all archs) NetBSD tools directory. pcc has also just successfully built a kernel for my i486 machine. I recall reading that build.sh can automatically determine which sources pcc can compile and which sources it cannot, so I'll let pcc attempt to build the userland and will report back if it fails on any targets that I cannot fix (or skip) myself. At some point, I'll try a dummy i386 build target and see if pcc can compile gcc by setting HAVE_PCC=1, HAVE_GCC=4, MKGCC=yes, and MKPCC=no. Failing that- since pcc doesn't have a fully functional C++ backend, I'll download GCC 4.7.3 and try the same with a pcc on my host machine (since that's unrelated to NetBSD, I'll join/post on the pcc mailing list). -Original Message- From: Iain Hibbert Sent: Thursday, July 24, 2014 5:07 PM To: William D. Jones Cc: current-users@netbsd.org Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error? On Sun, 20 Jul 2014, Iain Hibbert wrote: On Sat, 19 Jul 2014, William D. Jones wrote: it certainly is. I think I remember that __USE() now, it was a local (NetBSD) addition due to a set but unused variable, which is changed in upstream versions now. Alright then. What do you suggest I do to reconcile the NetBSD version with the current upstream tree? Should I wait for the next major release of PCC, and then attempt to integrate the changes, or is there something I can do now (to start)? I will try to import a new version later this week.. I have imported pcc-20140706 now, please report any problems in the usual places (here for NetBSD build problems, or the PCC issue tracker for compilation troubles) regards, iain -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
}; }; _makedirtarget . do-lib
*** Error code 1
Stop.
nbmake[2]: stopped in /mnt/lfs/NetBSD-CVS/src
*** Failed target: distribution
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=;
real=/mnt/lfs/NetBSD-CVS/src ;; *) this=${dir}/;
real=/mnt/lfs/NetBSD-CVS/src/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget . build NOPOSTINSTALL=1
*** Error code 1
Stop.
nbmake[1]: stopped in /mnt/lfs/NetBSD-CVS/src
*** Failed target: release
*** Failed command: _makedirtarget() { dir=$1; shift; target=$1; shift;
case ${dir} in /*) this=${dir}/; real=${dir} ;; .) this=;
real=/mnt/lfs/NetBSD-CVS/src ;; *) this=${dir}/;
real=/mnt/lfs/NetBSD-CVS/src/${dir} ;; esac; show=${this:-.}; echo
${target} === ${show%/}${1:+ (with: $@)}; cd ${real}
/mnt/lfs/NetBSD-CVS/src/../tools/bin/nbmake _THISDIR_=${this} $@
${target}; }; _makedirtarget . distribution
*** Error code 1
Stop.
nbmake: stopped in /mnt/lfs/NetBSD-CVS/src
ERROR: Failed to make release
*** BUILD ABORTED ***
william@xubuntu-ltrain:~/Projects/NetBSD-CVS/util$
william@xubuntu-ltrain:~/Projects/NetBSD-CVS/util$ cat mk.conf.i386-pb
COPTS=-Os -Wno-error=uninitialized -Wno-error=maybe-uninitialized
#COPTS.libm=-O2
MKPCC=yes
MKGCC=no
HAVE_GCC=4 #Define if MKGCC=no
HAVE_PCC=1
The relevant lines which cause an error are here:
extern int regexec (const regex_t *__restrict __preg,
const char *__restrict __string, size_t __nmatch,
line 544:regmatch_t __pmatch[__restrict_arr],
int __eflags);
With that being said, I guess this is a gcc extension-related error,
although I'm not sure how to fix it. Based upon lines 512 to 532, line 544
should be defined to regmatch_t __pmatch[__restrict]. Perhaps pcc does not
support that extension inside an array, but does elsewhere? If
__restrict_arr expands to nothing, then we have regmatch_t __pmatch[], which
seems to be legal ANSI C. Does the binutils version provided with NetBSD
track upstream so perhaps I/someone could add a patch?
-Original Message-
From: William D. Jones
Sent: Thursday, July 24, 2014 7:19 PM
To: Iain Hibbert
Cc: current-users@netbsd.org
Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
Good going :D!
As of 5 minutes ago, by setting HAVE_GCC=4, HAVE_PCC=1, MKGCC=no, and
MKPCC=yes, I've successfully compiled the current pcc in the NetBSD source
tree (using i486--netbsdelf-gcc) into my (global for all archs) NetBSD tools
directory. pcc has also just successfully built a kernel for my i486
machine.
I recall reading that build.sh can automatically determine which sources pcc
can compile and which sources it cannot, so I'll let pcc attempt to build
the userland and will report back if it fails on any targets that I cannot
fix (or skip) myself.
At some point, I'll try a dummy i386 build target and see if pcc can compile
gcc by setting HAVE_PCC=1, HAVE_GCC=4, MKGCC=yes, and MKPCC=no. Failing
that- since pcc doesn't have a fully functional C++ backend, I'll download
GCC 4.7.3 and try the same with a pcc on my host machine (since that's
unrelated to NetBSD, I'll join/post on the pcc mailing list).
-Original Message-
From: Iain Hibbert
Sent: Thursday, July 24, 2014 5:07 PM
To: William D. Jones
Cc: current-users@netbsd.org
Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
On Sun, 20 Jul 2014, Iain Hibbert wrote:
On Sat, 19 Jul 2014, William D. Jones wrote:
it certainly is. I think I remember that __USE() now, it was a local
(NetBSD) addition due to a set but unused variable, which is changed
in
upstream versions now.
Alright then. What do you suggest I do to reconcile the NetBSD version
with
the current upstream tree? Should I wait for the next major release of
PCC,
and then attempt to integrate the changes, or is there something I can
do now
(to start)?
I will try to import a new version later this week..
I have imported pcc-20140706 now, please report any problems in the usual
places (here for NetBSD build problems, or the PCC issue tracker for
compilation troubles)
regards,
iain
--
William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
thor0...@comcast.net
Message sent using 'Windows Live Mail' client.
Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch)
Accidentally forgot to Cc: the mailing list... whoops! -Original Message- From: William D. Jones Sent: Thursday, July 24, 2014 10:55 PM To: Jeff Rizzo Subject: Re: ARM ABI changes/combinations (was Re: Preparation for creating netbsd-7 branch) That said, if people don't care about aliases, I can remove them. +j I happen to use the aliases to simplify generation of a build.sh wrapper using m4 (although if necessary I could run etcmanage on my cross compiling machine). See: https://gist.github.com/cr1901/07b8e6810caedc31fe7c -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client. -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Add Firmware images to INSTALL kernels
Just wanted to check in re: adding a patch for INSTALL kernels:
http://cvsweb.netbsd.org/bsdweb.cgi/src/distrib/evbarm/instkernel/sshramdisk/?only_with_tag=MAIN
It appears the last time the install images were updated was to add
Raspberry Pi functionality to unstable. With NetBSD 7.0 on the horizon, are
there plans to add the RPI kernel to the stable release for 7.0. If so, I
can imagine others who choose to use NetBSD on their Model A's (and
specifically Model A, which has no onboard Ethernet) finding an unpleasant
surprise when they realize they can't install the sets over the network!
Adding the firmware to list did fix this problem.
Now while my use case is in particular for the Model A, I can imagine other
people needing such functionality for boards without onboard networking. But
if the firmware isn't needed, I imagine it should be left out to conserve
resources/space. Is there a suggested method to adding the firmware images
to the list and mtree.conf files that checks whether a evbarm install
kernel may need firmware on a device or user basis (i.e. RPI Model A will
most likely need the firmware, on Model B, it's not essential)?
-Original Message-
From: Martin Husemann
Sent: Monday, July 14, 2014 1:55 AM
To: thor0...@comcast.net
Cc: current-users@netbsd.org
Subject: Re: Add Firmware images to INSTALL kernels
On Sun, Jul 13, 2014 at 10:20:46PM +, thor0...@comcast.net wrote:
*I altered both mtree.conf to add the libdata subtree, and lists
to tell ./build.sh/make to copy the firmware: COPY
${NETBSDSRCDIR}/external/realtek/urtwn/dist/rtl8192cfw.bin
libdata/firmware/if_urtwn/rtl8192cfw.bin
That sounds correct - if it works for you, can you please send a diff -u ?
This should be changed in the main tree (and maybe extended to other
firmwares).
Martin
--
William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
thor0...@comcast.net
Message sent using 'Windows Live Mail' client.
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
-Original Message- From: Iain Hibbert Sent: Saturday, July 19, 2014 1:33 PM To: William D. Jones Cc: current-users@netbsd.org Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error? it certainly is. I think I remember that __USE() now, it was a local (NetBSD) addition due to a set but unused variable, which is changed in upstream versions now. Alright then. What do you suggest I do to reconcile the NetBSD version with the current upstream tree? Should I wait for the next major release of PCC, and then attempt to integrate the changes, or is there something I can do now (to start)? It does handle most of the NetBSD source tree lately, the main problems currently are things which GCC accepts (or encourages) which are not supported. Personally, I think it would be good for PCC to be able to build GCC, perhaps that would be enough compatibility. I would be ecstatic to find another compiler that can compile GCC- even if only the first stage. It doesn't solve the difficult problem of finding a 100% compatible GCC compiler that's not a nightmare to port, but it's a start. I have not tried application sources (eg pkgsrc) due to lack of time. Join the club :P. I am not sure, but it may not.. predictably the GCC developers use GCC language features within their code, and these are not always supported. I have been concentrating on other things lately and have not tried to build GCC with PCC. At least I know that the binutils we have in tree won't build, as there is an unsupported feature which causes an error (restrict keyword in array declaration). GCC 4.7.3 and below can in theory (emphasis on theory) be built with a pure ANSI C compiler that has a working libc. The first stage of GCC will use the host C compiler to build a cross-gcc from pure ANSI C. The cross-gcc can compile the remaining source code that relies on GCC's extensions. In practice, I have seen GCC 4.7.3 emit a number of warnings for standards-violating code when -pedantic is set. For perspective, from my own experimentation, TinyCC is capable of compiling the cross-gcc which then builds the remaining extensions (with minor source code tweaks in 3 or so file)... sadly the cross-gcc segfaults :P, and I haven't had the time to figure out what goes wrong. So I don't think it's an impractical goal. Versions above 4.7.3 sadly require a C++ compiler. Still, one could compile GCC 4.7.3 and use that to create the C++ compiler. -- William D. Jones
Re: pkg_add packages for evbearmv6hf-el: Cannot execute ELF binary
I don't think it is, it was just a typo, and it's fixed. Understood. Just was the result that came up when using Google. Can you send me your wget binary (off-list), please? And dmesg too? Done, sent in separate email that was not CC'ed. dmesg is printed here for convenience: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 6.99.47 (RPI) #1: Wed Jul 16 02:22:14 EDT 2014 william@xubuntu-ltrain:/mnt/lfs/NetBSD-CVS/objdir/evbearmv6hf-el-rpi/sys/arch/evbarm/compile/RPI total memory = 192 MB avail memory = 183 MB sysctl_createv: sysctl_create(machine_arch) returned 17 sysctl_createv: sysctl_locate(multicast) returned 2 sysctl_createv: sysctl_locate(multicast_kludge) returned 2 timecounter: Timecounters tick every 10.000 msec mainbus0 (root) cpu0 at mainbus0 core 0: 700 MHz ARM1176JZ-S r0p7 (ARM11J V6ZK core) cpu0: DC enabled IC enabled WB enabled LABT cpu0: isar: [0]=0x140011 [1]=0x12002111 [2]=0x11231121 [3]=0x1102131, [4]=0x1141, [5]=0 cpu0: mmfr: [0]=0x1130003 [1]=0x10030302 [2]=0x1222100 [3]=0 cpu0: pfr: [0]=0x111 [1]=0x11 cpu0: 16KB/32B 4-way L1 VIPT Instruction cache cpu0: 16KB/32B 4-way write-back-locking-C L1 VIPT Data cache vfp0 at cpu0: VFP11, rounding, exceptions, NaN propagation, denormals vfp0: mvfr: [0]=0x [1]=0x obio0 at mainbus0 bcmicu0 at obio0 bcmmbox0 at obio0: VC mailbox vcmbox0 at bcmmbox0 bcmtmr0 at obio0 intr 3: VC System Timer vchiq0 at obio0 intr 66: BCM2835 VCHIQ bcmpm0 at obio0: Power management, Reset and Watchdog controller bcmrng0 at obio0: RNG plcom0 at obio0 intr 57 plcom0: txfifo disabled plcom0: console genfb0 at obio0 genfb0: framebuffer at 0xc006000, size 1280x720, depth 32, stride 5120 wsdisplay0 at genfb0 kbdmux 1 wsmux1: connecting to wsdisplay0 wsdisplay0: screen 0-3 added (default, vt100 emulation) sdhc0 at obio0 intr 62: SDHC controller sdhc0: interrupting on intr 62 sdhc0: SD Host Specification 3.0, rev.153 sdmmc0 at sdhc0 slot 0 dwctwo0 at obio0 intr 9: USB controller bcmspi0 at obio0 intr 54: SPI spi0 at bcmspi0: SPI bus bsciic0 at obio0 intr 53: BSC0 iic0 at bsciic0: I2C bus bsciic1 at obio0 intr 53: BSC1 iic1 at bsciic1: I2C bus bcmgpio0 at obio0: GPIO [0...31] gpio0 at bcmgpio0: 32 pins bcmgpio1 at obio0: GPIO [32...53] gpio1 at bcmgpio1: 22 pins usb0 at dwctwo0: USB revision 2.0 timecounter: Timecounter clockinterrupt frequency 100 Hz quality 0 timecounter: Timecounter bcmtmr0 frequency 100 Hz quality 100 WARNING: module error: vfs load failed for `usbverbose', error 45 uhub0 at usb0WARNING: module error: vfs load failed for `usbverbose', error 45 : vendor 0x DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1 uhub0: 1 port with 1 removable, self powered ld0 at sdmmc0: 0x03:0x5344:SU08G:0x80:0x007e2c78:0x0da ld0: 7580 MB, 3850 cyl, 64 head, 63 sec, 512 bytes/sect x 15523840 sectors ld0: 4-bit width, bus clock 50.000 MHz WARNING: module error: vfs load failed for `usbverbose', error 45 WARNING: module error: vfs load failed for `usbverbose', error 45 uhub1 at uhub0 port 1WARNING: module error: vfs load failed for `usbverbose', error 45 WARNING: module error: vfs load failed for `usbverbose', error 45 : vendor 0x050d product 0x0234, class 9/0, rev 2.00/0.00, addr 2 uhub1: multiple transaction translators uhub1: 4 ports with 4 removable, self powered WARNING: module error: vfs load failed for `usbverbose', error 45 WARNING: module error: vfs load failed for `usbverbose', error 45 uhub2 at uhub1 port 1WARNING: module error: vfs load failed for `usbverbose', error 45 WARNING: module error: vfs load failed for `usbverbose', error 45 : vendor 0x0409 product 0x0059, class 9/0, rev 2.00/1.00, addr 3 uhub2: single transaction translator uhub2: 4 ports with 4 removable, self powered umidi_search_quirk: v=1435, p=880, i=0 umass0 at uhub2 port 2 configuration 1 interface 0 umass0: Iomega Iomega, rev 2.00/1.0f, addr 4 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: Iomega E, xternal HD, disk fixed umass0: dCSWDataResidue=6 req=32 act=32 sd0: 931 GB, 500 cyl, 8 head, 32 sec, 512 bytes/sect x 1953525168 sectors dwctwo0: dwc2_update_urb_state(): trimming xfer length umidi_search_quirk: v=1604, p=0, i=0 umass1 at uhub2 port 3 configuration 1 interface 0 umass1: TEACV0.0 TEACV0.0, rev 1.10/2.00, addr 5 umass1: using UFI over CBI with CCI atapibus0 at umass1: 2 targets probe(umass1:0:0): generic HBA error dwctwo0: dwc2_update_urb_state(): trimming xfer length urtwn0 at uhub1 port 4 urtwn0: Realtek 802.11n WLAN Adapter, rev 2.00/2.00, addr 6 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R, address 00:13:ef:d0:23:62 urtwn0: 1 rx pipe, 2 tx pipes urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps
Re: Add Firmware images to INSTALL kernels
-Original Message- From: William D. Jones Sent: Wednesday, July 16, 2014 6:47 PM To: Martin Husemann Cc: current-users@netbsd.org Subject: Re: Add Firmware images to INSTALL kernels I have attached a diff which will install firmware to the sshramdisk (and standard ramdisk) by default. It appears only editing the sshramdisk mtree.conf and list is necessary, but just in case someone uses the standard ramdisk, I edited that as well. Please do not apply the patch to distrib/evbarm/instkernel/ramdisk/list as is. I didn't catch this error initially, but it the change as-is prompts the following error during make release: # build ramdisk/work nbmtree: ./libdata: missing directory in specification nbmtree: failed at line 699 of the specification It appears I have to create an mtree.conf in the ramdisk directory. Before I add one, however: does mtree.conf override cvsroot/src/distrib/common/mtree.common, or create additional entries to be appended to mtree.common? I would guess the latter based on other aspects of the build system, but sshramdisk/mtree.conf includes all the directories present in mtree.conf. The sshramdisk patch works as intended- the installation image now has wifi!
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
Thank you for your response. I *fully* recommend using the latest pcc before looking too deeply into any errors. You can use the native pcc configure script and build system (installs to /usr/local) or the lang/pcc-current package (might not always be latest but its easy to change the date -- I just updated it) regards, iain I'm afraid that I am cross-compiling from a Linux system, and as to not contaminate my source tree, I wanted to create a tools version of PCC that can be used to compile the rest of the tree. However, if your source tree does not have __USE (Google says you are a PCC developer), then it's probable that NetBSDs version of PCC is simply out of date. I have a separate compiler (GCC) on my host machine as well... I can skip HAVE_PCC for now and just have the distribution ship PCC, or I can try an EXTERNAL_TOOLCHAIN. The latter is not trivial, since I have to create a cross-PCC. But I want to see JUST how much software PCC is capable of compiling. For example, will it compile most untarred source trees and GNU autoconfed trees I throw at it on the 486 without problem? The NetBSD source tree is a good test for this. As an aside, is it possible for PCC to reliably build the first stage of GCC = 4.7.3? -- Sincerely, William D. Jones
pkg_add packages for evbearmv6hf-el: Cannot execute ELF binary
Hello all, I am not sure whether this is user error or a legitimate bug, so I will post here before filing a PR. The following thread may be related: http://mail-index.netbsd.org/current-users/2013/12/21/msg023935.html I am attempting to get my NTFS hard disk recognized under Raspberry Pi so that I may transfer files to and from the device as secondary storage. Currently, any attempt to mount the device using mount_ntfs returns Operation not supported by device, even using the ro option. At least on FreeBSD as of August 2013, mount_ntfs is broken, so I figured installing ntfs-3g is the solution. Compiling ntfs-3g from scratch is not ideal on my Pi currently (see below), so I attempted to use pkg_add (with -f option) to install from: ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/evbarm/6.1/filesystems/fuse-ntfs-3g-1.1120.tgz pkg_add works correctly and installs the package, but all attempts to run the program end with the following error message: rpi-ptrain# ntfs-3g -sh: Cannot execute ELF binary /usr/pkg/bin/ntfs-3g This also applies to other packages, such as python. Is the expected behavior due to ARM family mismatch, intentional changes in the kernel facilities between 6.1 and 6.99 that make the packages out of date, or is this a legitimate program loader bug that I may have found? Source that I have manually compiled and placed in /usr/local (including wget) works perfectly fine, and for the time being, I suppose the following git repository is an unofficial workaround: https://github.com/ebijun/NetBSD/tree/master/RPI/RPIimage/Image Yes, I could place the kernel sources on my host and compile ntfs-3g in that manner. However, that is currently not convenient for me when I effectively have a machine at home dedicated to building kernels/holding one copy of the CVS tree. I have not figured out the best way to cross-compile packages beyond what the NetBSD source tree provides (userland and kernel). As always, thank you for any guidance in helping me understand the problem :). Sincerely, William D. Jones
Re: Add Firmware images to INSTALL kernels
That sounds correct - if it works for you, can you please send a diff -u ? This should be changed in the main tree (and maybe extended to other firmwares). Will do when I can test- the source tree is currently broken for me (and has been since at least July 5th, according to cvs -D).
Re: Automated report: NetBSD-current/i386 build failure
As of a CVS checkout at 3:10PM today, I receive this same exact error when attempting to build an i386 kernel on a Linux cross-compiling machine. The problem I discussed yesterday (same directory, different error) seems to have corrected itself (I have no idea what changed). Is there a temporary fix to this problem however, so I can continue to build distributions? Indeed, CVSweb says curses.txt is missing in PSD.doc. -Original Message- From: David Holland Sent: Saturday, July 05, 2014 6:33 PM To: current-users@NetBSD.org Subject: Re: Automated report: NetBSD-current/i386 build failure On Sat, Jul 05, 2014 at 10:26:05PM +, David Holland wrote: On Sat, Jul 05, 2014 at 10:21:35PM +, NetBSD Test Fixture wrote: --- docinstall --- # install docinstall /tmp/bracket/build/2014.07.05.20.45.49-i386/tools/bin/i486--netbsdelf-install -U -M /tmp/bracket/build/2014.07.05.20.45.49-i386/destdir/METALOG -D /tmp/bracket/build/2014.07.05.20.45.49-i386/destdir -h sha256 -N /tmp/bracket/build/2014.07.05.20.45.49-i386/src/etc -c -r -o root -g wheel -m 444 curses.txt /tmp/bracket/build/2014.07.05.20.45.49-i386/destdir/usr/share/doc/reference/ref3/curses/curses.txt i486--netbsdelf-install: curses.txt: stat: No such file or directory *** [docinstall] Error code 1 nbmake[7]: stopped in /tmp/bracket/build/2014.07.05.20.45.49-i386/src/lib/libcurses/PSD.doc I'm trying to figure out why this doesn't happen in my tree. However, it should be fixed now. -- David A. Holland dholl...@netbsd.org -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Getting Started
(This mail is in response to Getting Started on 6/11/2014) Alan and Greg, thank you both for your responses. At this point (after dealing with real life of course), I've read through the driver-writing guide and driver(9), config(9), and autoconf(9), and have modified the kernel files so that my template driver is compiled in successfully (http://pastebin.com/AF7iSmfu). sys/dev/isa/files.isa, my custom kernel config, and sys/arch/i386/conf/majors.i386 have also been modified accordingly (I used char 94 block 25 for my own source tree). As of right now, I'm much better with CVS, and build.sh, and have a shell script to swap out a working kernel with my own (I use a remote machine for compiling). Greg: RAM will have to wait for now (parity SIMMs still cost an arm and leg), but I'll humor myself and try the tests anyway. Next is to actually get a driver working for this old CD-ROM device that is almost before my time :). Greg brings up a valid point when, in response to my delusions of writing a driver, he mentions “The question is who will spend time to address them and integrate it, and the easier you make that the better”. I'm writing a driver for a rather old piece of hardware for fun and education, not for use by the general public. Most people will not need this driver, and so I expect myself to be left to my own devices when writing the driver. In fact, it would be great if I could get this driver working without any questions at all- and I think that might be possible. Although the driver might be for an old device, I'm under the impression a working driver- written up to standards- would be accepted anyway as a meaningful contribution- educational at least. And who knows- it might be of use to others. With that being said, where would be the proper place to get feedback (WITHOUT harassing the developers) as I develop this driver to ease integration? I do want to make this easy for all parties involved (besides myself and my sanity :P), and I'm grateful for any help I can get if necessary. I figure the tech-kern mailing list (pre-bare minimum implementation) or problem reports (when I have a bare-minimum implementation, like pcdopen and pcdread) are most appropriate, but does anyone more experience than me at writing device drivers have any advice? Thanks for any help anyone can give me! Also, Alan wrote: It's easier to deal with one question at a time, unless the questions are closely related. My mistake :P. -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
