Re: /bin/sh arithmetic doesn't seem to like leading 0 now
On Fri, Sep 21, 2012 at 07:34:06PM +0200, Jilles Tjoelker wrote: On Fri, Sep 21, 2012 at 10:09:02AM -0700, David Wolfskill wrote: $ echo $(( ( $( date +%m ) - 1 ) / 3 + 1 )) arithmetic expression: expecting ')': ( 09 - 1 ) / 3 + 1 ... This was done to avoid an inconsistency where constants starting with 0 and containing 8 or 9 were decimal, so something like $((018-017)) expanded to 3. Jilles, Would it be possible to improve on the error message? If David had been given the Bash error message, I suspect he would have figured out the issue right away. -- -- David(obr...@freebsd.org) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bash 4.2 patchlevel 28
On Thu, May 24, 2012 at 01:07:55PM -0700, Sean Bruno wrote: Noted that the following syntax is broken somewhere between 4.2 patchlevel 10 and 28. I'm sure its because we shouldn't be doing that over here at big purple, but we do ... and its a PITA. I'm bisecting to find out what is going on. Hi Sean, Were you able to track down which patch 10-28 broke this for you? thanks, -- -- David (obr...@freebsd.org) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: amd(8) cores dump when load high
On Sat, Dec 27, 2008 at 01:03:54PM +0200, Danny Braniss wrote: well, I'm running 7.1-PRERELEASE, what does the amd logs show? .. Dec 27 10:37:01 sf-02 amd[856]: am-utils version 6.1.5 (build 1). Dec 27 10:37:01 sf-02 amd[856]: Report bugs to https://bugzilla.am-utils.org/ or am-ut...@am-utils.org. Dec 27 10:37:01 sf-02 amd[856]: Configured by da...@sunfire on date Sun Jun 29 16:59:06 IDT 2008. Dec 27 10:37:01 sf-02 amd[856]: Built by da...@sunfire on date Sun Jun 29 17:02:07 IDT 2008. Dec 27 10:37:01 sf-02 amd[856]: cpu=x86_64 (little-endian), arch=amd64, karch=amd64. Dec 27 10:37:01 sf-02 amd[856]: full_os=freebsd7.0, os=freebsd7, osver=7.0, vendor=unknown, distro=none. How did you get this output from /usr/sbin/amd? It should be: # amq -v Copyright (c) 1997-2006 Erez Zadok Copyright (c) 1990 Jan-Simon Pendry Copyright (c) 1990 Imperial College of Science, Technology Medicine Copyright (c) 1990 The Regents of the University of California. am-utils version 6.1.5 (build 800059). Report bugs to https://bugzilla.am-utils.org/ or am-ut...@am-utils.org. Configured by David O'Brien obr...@freebsd.org on date 4-December-2007 PST. Built by r...@quynh.nuxi.org on date Fri Dec 19 15:29:18 PST 2008. cpu=amd64 (little-endian), arch=amd64, karch=amd64. full_os=freebsd8.0, os=freebsd8, osver=8.0, vendor=undermydesk, distro=The FreeBSD Project. So many of your fields aren't what I expect: build#, configured by, configured date, cpu, vendor, nor distro. -- -- David(obr...@freebsd.org) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: amd(8) cores dump when load high
On Mon, Dec 29, 2008 at 12:48:34PM +0200, Danny Braniss wrote: On Sat, Dec 27, 2008 at 01:03:54PM +0200, Danny Braniss wrote: well, I'm running 7.1-PRERELEASE, what does the amd logs show? .. Dec 27 10:37:01 sf-02 amd[856]: am-utils version 6.1.5 (build 1). Dec 27 10:37:01 sf-02 amd[856]: Report bugs to https://bugzilla.am-utils.org/ or am-ut...@am-utils.org. Dec 27 10:37:01 sf-02 amd[856]: Configured by da...@sunfire on date Sun Jun 29 16:59:06 IDT 2008. Dec 27 10:37:01 sf-02 amd[856]: Built by da...@sunfire on date Sun Jun 29 17:02:07 IDT 2008. Dec 27 10:37:01 sf-02 amd[856]: cpu=x86_64 (little-endian), arch=amd64, karch=amd64. Dec 27 10:37:01 sf-02 amd[856]: full_os=freebsd7.0, os=freebsd7, osver=7.0, vendor=unknown, distro=none. How did you get this output from /usr/sbin/amd? .. as explained in a later message, I rolled my own :-) with the unofficial patches. OK. I saw you later said that you had rolled your own, but I didn't think that your initial reporting of problems was also with that version. Thanks for the clarification. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: cvs commit: src/usr.bin/netstat Makefile bpf.c inet.c pfkey.c route.c sctp.c
On Tue, Sep 09, 2008 at 10:31:46PM -0400, Mike Tancsa wrote: Hi, The change below seems to make netstat -B on RELENG_7 coredump netstat -B specifically, - printf(%5d %6s %7s %9lu %9lu %9lu %5d %5d %s\n, + printf(%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n, Not sure if its a netstat issue or a libc issue as it works fine in HEAD Can you test this patch? This will quickly fix the issue, until I can build world with matching the releng7 definitions with CURRENT. Index: bpf.c === --- bpf.c (revision 182906) +++ bpf.c (working copy) @@ -122,7 +122,8 @@ bpf_stats(char *ifname) pname = bpf_pidname(d-bd_pid); (void) printf(%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n, d-bd_pid, d-bd_ifname, flagbuf, - d-bd_rcount, d-bd_dcount, d-bd_fcount, + (intmax_t)d-bd_rcount, (intmax_t)d-bd_dcount, + (intmax_t)d-bd_fcount, d-bd_slen, d-bd_hlen, pname); free(pname); } ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7_0 buildworld failure on read only source tree
On Sun, Mar 09, 2008 at 04:19:15PM -0500, Tom Judge wrote: Thanks for the response, it was indeed just a case of touching /usr/src/gnu/usr.bin/cvs/contrib/Makefile. Do you have the information about the relevent change sets that fix this? Then I can merge this fix to my local tree. You need to add .POSIX: to the top of /usr/src/gnu/usr.bin/cvs/contrib/Makefile. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gdbserver on latest -STABLE ...
On Mon, Dec 03, 2007 at 10:28:50PM -0400, Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is this related to the commit that just went through to enable on arch that support it? What platform are you using? I did my build testing on a FreeBSD/amd64 RELENG_6 machine that I [attempt] to keep totally stock. foo:/src/6/contrib/gdb/gdb/gdbserver cvs status server.c === File: server.c Status: Up-to-date Working file:server.c Working revision:1.1.1.4 Wed Jun 23 23:40:29 2004 Repository revision: 1.1.1.4 /home/ncvs/src/contrib/gdb/gdb/gdbserver/server.c,v Sticky Tag: RELENG_6 (branch: 1.1.1.4.8) Sticky Date: (none) Sticky Options: (none) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gdbserver on latest -STABLE ...
On Mon, Dec 03, 2007 at 10:28:50PM -0400, Marc G. Fournier wrote: === gnu/usr.bin/gdb/gdbserver (clean) cd: can't cd to /usr/src/gnu/usr.bin/gdb/gdbserver *** Error code 2 Stop in /usr/src/gnu/usr.bin/gdb. Or did I catch something 'in between'? Too many architectures, too many FreeBSD versions in flight... I've found one commit flubup I made. Please let me know if that takes care of your problem. -- -- David([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
MFC 7.0 calcru changes
This is a patch to MFC what I think are all the calcru-related changes
that occurred since 6-STABLE was branched and 7.0 continued forward.
If anyone spots some changes I missed, please yell out.
--
-- David ([EMAIL PROTECTED])
Index: amd64/amd64/mp_machdep.c
===
RCS file: /home/ncvs/src/sys/amd64/amd64/mp_machdep.c,v
retrieving revision 1.260.2.11
diff -u -p -r1.260.2.11 mp_machdep.c
--- amd64/amd64/mp_machdep.c5 May 2007 21:13:16 - 1.260.2.11
+++ amd64/amd64/mp_machdep.c23 Aug 2007 18:05:54 -
@@ -577,7 +577,7 @@ init_secondary(void)
spinlock_exit();
KASSERT(curthread-td_md.md_spinlock_count == 1, (invalid count));
- binuptime(PCPU_PTR(switchtime));
+ PCPU_SET(switchtime, cpu_ticks());
PCPU_SET(switchticks, ticks);
cpu_throw(NULL, choosethread());/* doesn't return */
Index: amd64/amd64/trap.c
===
RCS file: /home/ncvs/src/sys/amd64/amd64/trap.c,v
retrieving revision 1.289.2.6
diff -u -p -r1.289.2.6 trap.c
--- amd64/amd64/trap.c 14 Aug 2007 19:42:51 - 1.289.2.6
+++ amd64/amd64/trap.c 23 Aug 2007 20:28:33 -
@@ -162,7 +162,7 @@ trap(frame)
{
struct thread *td = curthread;
struct proc *p = td-td_proc;
- u_int sticks = 0, type;
+ u_int type;
int i = 0, ucode = 0, code;
PCPU_LAZY_INC(cnt.v_trap);
@@ -242,7 +242,7 @@ trap(frame)
if (ISPL(frame.tf_cs) == SEL_UPL) {
/* user trap */
- sticks = td-td_sticks;
+ td-td_pticks = 0;
td-td_frame = frame;
if (td-td_ucred != p-p_ucred)
cred_update_thread(td);
@@ -488,7 +488,7 @@ trap(frame)
#endif
user:
- userret(td, frame, sticks);
+ userret(td, frame);
mtx_assert(Giant, MA_NOTOWNED);
userout:
out:
@@ -703,7 +703,6 @@ syscall(frame)
struct thread *td = curthread;
struct proc *p = td-td_proc;
register_t orig_tf_rflags;
- u_int sticks;
int error;
int narg;
register_t args[8];
@@ -728,7 +727,7 @@ syscall(frame)
reg = 0;
regcnt = 6;
- sticks = td-td_sticks;
+ td-td_pticks = 0;
td-td_frame = frame;
if (td-td_ucred != p-p_ucred)
cred_update_thread(td);
@@ -851,7 +850,7 @@ syscall(frame)
/*
* Handle reschedule and other end-of-syscall issues
*/
- userret(td, frame, sticks);
+ userret(td, frame);
CTR4(KTR_SYSC, syscall exit thread %p pid %d proc %s code %d, td,
td-td_proc-p_pid, td-td_proc-p_comm, code);
Index: amd64/amd64/tsc.c
===
RCS file: /home/ncvs/src/sys/amd64/amd64/tsc.c,v
retrieving revision 1.205
diff -u -p -r1.205 tsc.c
--- amd64/amd64/tsc.c 17 Nov 2003 08:58:13 - 1.205
+++ amd64/amd64/tsc.c 23 Aug 2007 20:32:25 -
@@ -77,6 +77,7 @@ init_TSC(void)
tsc_freq = tscval[1] - tscval[0];
if (bootverbose)
printf(TSC clock: %lu Hz\n, tsc_freq);
+ set_cputicker(rdtsc, tsc_freq, 1);
}
Index: amd64/ia32/ia32_syscall.c
===
RCS file: /home/ncvs/src/sys/amd64/ia32/ia32_syscall.c,v
retrieving revision 1.8.2.2
diff -u -p -r1.8.2.2 ia32_syscall.c
--- amd64/ia32/ia32_syscall.c 11 Aug 2006 18:42:48 - 1.8.2.2
+++ amd64/ia32/ia32_syscall.c 23 Aug 2007 18:11:09 -
@@ -96,7 +96,6 @@ ia32_syscall(struct trapframe frame)
struct thread *td = curthread;
struct proc *p = td-td_proc;
register_t orig_tf_rflags;
- u_int sticks;
int error;
int narg;
u_int32_t args[8];
@@ -109,7 +108,7 @@ ia32_syscall(struct trapframe frame)
*/
PCPU_LAZY_INC(cnt.v_syscall);
- sticks = td-td_sticks;
+ td-td_pticks = 0;
td-td_frame = frame;
if (td-td_ucred != p-p_ucred)
cred_update_thread(td);
@@ -239,7 +238,7 @@ ia32_syscall(struct trapframe frame)
/*
* Handle reschedule and other end-of-syscall issues
*/
- userret(td, frame, sticks);
+ userret(td, frame);
CTR4(KTR_SYSC, syscall exit thread %p pid %d proc %s code %d, td,
td-td_proc-p_pid, td-td_proc-p_comm, code);
Index: arm/arm/trap.c
===
RCS file: /home/ncvs/src/sys/arm/arm/trap.c,v
retrieving revision 1.17.2.3
diff -u -p -r1.17.2.3 trap.c
--- arm/arm/trap.c 26 Feb 2007 20:38:31 - 1.17.2.3
+++ arm/arm/trap.c 23 Aug 2007 20:27:08 -
@@ -230,7 +230,6 @@ data_abort_handler(trapframe_t *tf)
vm_prot_t ftype;
void *onfault;
vm_offset_t va;
- u_int sticks = 0;
int error = 0;
struct ksig ksig;
Re: suggestions for SATA RAID cards
On Wed, Aug 23, 2006 at 11:13:37AM -0500, Nikolas Britton wrote: I agree. PCIe 8x is a faster bus and it's typically connected directly to the MCH (north bridge) unlike PCI-X which is stuck on the ICH (south bridge). This would be for a Northbridge-based system (ie. Intel). For AMD-based motherboards, both PCI-X and PCI-e controlers usually sit the same distance away the CPU's - one hop on the HyperTransport link. -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suggestions for SATA RAID cards
On Thu, Aug 24, 2006 at 01:39:43AM -0500, Nikolas Britton wrote: had nothing but problems with my Promise card. To make matters worse Promise doesn't support FreeBSD... No drivers, No docs, Nothing. eh??? You don't follow FreeBSD very carefully. Promise sends full docs to [EMAIL PROTECTED] who writes the driver. I'd much rather have a talented driver writer who knows FreeBSD coding style create the driver from vendor docs, than trusting the intern silicon guy the forced to write code make one. -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bash 3.1.10 breaks configure scripts (was Re: configure scripts ignores parameters)
On Mon, Mar 06, 2006 at 04:59:42PM -0500, Kris Kennaway wrote: On Sun, Mar 05, 2006 at 04:01:19AM -0500, Kris Kennaway wrote: On Sun, Mar 05, 2006 at 09:57:54AM +0100, Nicolas Rachinsky wrote: * Kris Kennaway [EMAIL PROTECTED] [2006-03-05 03:41 -0500]: On Sun, Mar 05, 2006 at 09:36:25AM +0100, Nicolas Rachinsky wrote: The problem seems to depend on the installed bison version. With no bison or bison-2.1_1 installed it works fine, with bison-1.75_2,1 it doesn't. Installed at what point: the build time of the bash port, or runtime (which would be very odd)? The build time. I submitted ports/94086, which contains a fix/workaround. Great, thanks for tracking this down! Can others confirm this solution? I have committed the patch, so this should go away next time you portupgrade. Kris, thanks for taking care of this. I've been Net-dead for 3 weeks. -- -- David ([EMAIL PROTECTED]) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
On Tue, Jun 28, 2005 at 08:46:27AM -0700, Alfred Perlstein wrote: I just got bitten by an upgrade from 5.2.1 to 5.4 where my apps linked with c++ stopped working. The solution I had to do was to copy an old 5.2.1 libstdc++ over my 5.4 one. My question is, why wasn't the library version bumped for this incompatible change? Because 5.2.1 was 5-CURRENT. Not until 5.3 did we make any ABI stability cares or guarantees. It was a conscientious decision the release management team made. I'm sure one could have built a 5.2.1 kernel module (.ko) that is broken on 5.3-RELEASE and 5-STABLE. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libstdc++ version bump.
On Tue, Jun 28, 2005 at 06:44:02PM +0200, Michael Nottebrock wrote: On Tuesday, 28. June 2005 18:21, Scot Hetzel wrote: Are you sure that the problem is with libstdc++ and not the above libraries? Yes, it's a well known-fact. In fact there might have been a break of ABI backwards-compatibility between gcc 3.3 and 3.4, too, but I'm not sure. There was. 3.3 could support either the C++ ABI of GCC 3.2, in which there was an implementation bug; or the fixed ABI of 3.4. I had hoped we had gone with the fixed ABI rather than being G++ 3.2 compatible, but that is what users wanted at the time. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM? (solved)
On Tue, Apr 05, 2005 at 10:09:11AM +0930, Greg 'groggy' Lehey wrote: The moral of the story is, I suppose, don't buy the MSI K8T Master2-FAR. I was warned about the motherboard before I bought it, WHY?? There is nothing wrong with that motherboard -- I have three of them. You are at fault for trying to treat a consumer desktop 2P mobo as a high-end server one. People do not run 2GB DIMM's in an MSI K8T Master2-FAR. If you want 4GB RAM get an eATX 4+4 DIMM configuration motherboard from Tyan or Iwill. The MSI K8T Master2-FAR works fine with 1GB DIMM's. Where on MSI's website did they state 2GB double-stacked DIMM's were supported? -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Tue, Apr 05, 2005 at 09:33:05AM +0200, Willem Jan Withagen wrote: I'm sorry to come into this discussion after 58 messages, but this board has been extensively discussed about 1 year ago, because it gave me trouble to no end (even with 2Gb). One of the early amd64 developers (not David or Scott) had the same board but could not get it stable under amd64 (i386 was fine with 2Gb). He tossed it, and suggested me to do the same. Hogwash. It was Peter Wemm and he was talking about the Asus SK8N, not the MSI K8T Master2-FAR. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Wed, Mar 30, 2005 at 03:25:37PM -0800, Peter Wemm wrote: Greg: The busdma problems from 5.3-RELEASE are fixed. That doesn't mean that there are no *other* problems. Scott is saying the old busdma bug shouldn't be affecting 5.4-PRE, and he's correct. Most likely, something else is happening, eg: you're running out of KVM or something silly like that. I know we're right on the brink at 8GB. The layout of the devices may be just enough to tip it over the edge. Grog's motherboard is a 4+0 configuration -- which would mean he is using (trying to) 2GB DIMM's. There are memory bus loading specifictions he may be out of spec of. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Thu, Mar 31, 2005 at 08:14:45AM +0930, Greg 'groggy' Lehey wrote: I had 4 bad out of 12 tested where the DIMMs were Crucial PC2700 2GB Reg. ECC DIMMs. OK, this makes sense. It might also explain why the 4 GB configuration only recognizes 3.5 GB. No. This is due to the 3.5-4.0GB PA address range that the PeeCee architecture reserves for the PCI config space, AGP GART, memory mapped I/O, etc... Many Opteron BIOS's don't bother to hoist the covered memory above 4GB. Please see the freebsd-amd64 archives -- this has been discussed many times. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Thu, Mar 31, 2005 at 10:32:33AM +0930, Daniel O'Connor wrote: On Thu, 31 Mar 2005 08:14, Greg 'groggy' Lehey wrote: Have you run sysutils/memtest86 with the 8 GB? Heh. Difficult when the system doesn't run. You could try http://www.memtest86.com although that doesn't do 4Gb :( Are you sure version 3.2 does not? -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with AMD64 and 8 GB RAM?
On Thu, Mar 31, 2005 at 11:24:29AM +0930, Greg 'groggy' Lehey wrote: On Thursday, 31 March 2005 at 10:32:33 +0930, Daniel O'Connor wrote: On Thu, 31 Mar 2005 08:14, Greg 'groggy' Lehey wrote: Have you run sysutils/memtest86 with the 8 GB? Heh. Difficult when the system doesn't run. You could try http://www.memtest86.com although that doesn't do 4Gb :( I'm pretty sure it's not the memory. I've tried each pair individually, and it's only when they're both in there together that it's a problem. And yes, I've tried them in each pair of slots. You have a dual-channel memory controller. If you insert one DIMM you perform 64-bit data accesses. If you install DIMM's in pairs (making sure you're using the right paired sockets), you perform 128-bit data accesses. Thus your access pattern is different between these two situations. I'm highly suspious that you can us 4x2GB DIMM's with out knowing the exact part number. Don't forget 2GB DIMM's are double-stacked and thus look like double the electrical bus loads. The same is true for older 1GB DIMM's. Install all the memory you would like to use into your motherboard, download memtest86+ version 1.40 from http://www.memtest.org, dd to floppy or burn the ISO, and report back your findings from running it. Also what version of the BIOS are you using? -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
On Tue, Mar 15, 2005 at 06:30:33PM -0600, Jon Noack wrote: Jon Noack wrote: Is it possible GCC compiled with CPUTYPE?=athlon-xp produces bad code? I guess my BIOS writer could've been on crack, but the machine is rock solid without CPUTYPE defined so I don't think it is a hardware problem. Anything thing is possible, but I've been using CPUTYPE=athlon-mp (which is same as 'athlon-xp') for a LONG time on 4 different machines with no problems. Including one that also is set to use -O2. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
On Tue, Mar 15, 2005 at 01:12:57PM -0600, Jon Noack wrote: David O'Brien wrote: On Sat, Mar 12, 2005 at 10:48:52PM +0100, Bartosz Fabianowski wrote: Are you saying, all we need to do is commit this diff to make everyone's environment happy? Obviously, I can't speak for everyone. For me, your patch fixes the kernel. Can you try with just -mno-sse2? I'd like to litter the compile command line as little as possible. Saw the commit -- do you plan to MFC? I need to ask RE@ to to an MFC at this time. I will after 5.4-R if I cannot get it into 5.4-R. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
On Tue, Mar 15, 2005 at 01:41:55PM -0600, Jon Noack wrote:
David O'Brien wrote:
On Sat, Mar 12, 2005 at 10:48:52PM +0100, Bartosz Fabianowski wrote:
Are you saying, all we need to do is commit this diff to make everyone's
environment happy?
Can you try with just -mno-sse2? I'd like to litter the compile command
line as little as possible.
I had this issue a while back with my Athlon-XP box
(http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042127.html).
Note that I would get instant reboots with CPUTYPE?=athlon-xp, CPUTYPE?=p3,
and CPUTYPE?=p2. However, it worked fine with CPUTYPE?=k6-2. I think you
are right to be cautious and disable anything that uses FP registers.
I remember that problem but I don't know why I don't experience it, since
I also use CPUTYPE=athlon-mp on my home desktop. I suspect the problem
is SSE2 usage, which the Althon {X,M}P doesn't support.
--
-- David ([EMAIL PROTECTED])
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
On Sat, Mar 12, 2005 at 10:48:52PM +0100, Bartosz Fabianowski wrote: Are you saying, all we need to do is commit this diff to make everyone's environment happy? Obviously, I can't speak for everyone. For me, your patch fixes the kernel. Can you try with just -mno-sse2? I'd like to litter the compile command line as little as possible. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE=pentium-m
On Sun, Mar 06, 2005 at 07:47:08PM +0100, Bartosz Fabianowski wrote:
i have read that were some problems compiling the kernel and the
loader with pentium-m in CPUTYPE. are they fixed now?
I'm the one who filed the original bug report:
http://www.freebsd.org/cgi/query-pr.cgi?pr=75898
..
I'd assume the answer to this one is yes - it's safe. Personally, I compile
world and kernel as pentium3, but that's just out of laziness. As you can
read in the bug report, the problem is that SSE2 instructions get used by
the kernel and loader before they are enabled. Once the boot gets to the
first userland programs, SSE2 is enabled so any world programs should run
just fine when compiled as pentium-m.
Are you saying, all we need to do is commit this diff to make everyone's
environment happy?
--
-- David([EMAIL PROTECTED])
Index: kern.mk
===
RCS file: /home/ncvs/src/sys/conf/kern.mk,v
retrieving revision 1.42
diff -u -r1.42 kern.mk
--- kern.mk 14 May 2004 13:35:46 - 1.42
+++ kern.mk 12 Mar 2005 02:03:47 -
@@ -28,7 +28,8 @@
# cache tag lines)
#
.if ${MACHINE_ARCH} == i386 ${CC} != icc
-CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2
+CFLAGS+= -mno-align-long-strings -mpreferred-stack-boundary=2 \
+ -mno-sse -mno-sse2
INLINE_LIMIT?= 8000
.endif
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.3-RELEASE (amd64) on LSILogic 1030 / mpt controller.
On Thu, Mar 10, 2005 at 04:45:50PM +0100, Krzysztof Kowalik wrote: Krzysztof Kowalik [EMAIL PROTECTED] wrote: I'm trying, without success, to install the FreeBSD 5.3 on a Sun Fire V40z (it's an amd64 box) on its LSILogic 1030 Ultra4 SCSI controller. Interesting. 5.3-RELEASE for x86 works on the same machine, same disks connected to the same controller without issues. [...] And 5-STABLE (installed snapshot from the end of January and upgraded to a recent -STABLE) works fine. I love to answer to myself. So the end result is that FreeBSD/amd64 5.3-RELEASE won't work for you, but 5.4-RELEASE will. Correct? -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld broken ?
On Mon, Feb 28, 2005 at 03:51:34PM +, Robert Watson wrote: On Mon, 28 Feb 2005, Mike Tancsa wrote: /usr/src/lib/libkvm/kvm_proc.c /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:269: warning: assignment makes integer from pointer without a cast /usr/src/lib/libkvm/kvm_proc.c:341: error: structure has no member named `p_runtime' I ran into this a few minutes ago also -- it looks like David merged the kernel but not user space portions of a change to process time measurement. I sent him an e-mail ping a few minutes ago -- if it isn't fixed shortly, I'll see about getting it fixed myself. How come the tenderbox report sfor RELENG_5 don't go to this mailing list? I was watching this list while waiting for my own 'make world' to finish. (but then passed out) -- -- David([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
On Mon, Feb 14, 2005 at 05:47:27PM -0800, Jonathan A. Dama wrote: FreeBSD/amd64 is not in my opinion not actually a stable tier 1 quality release under these configurations, too many problems remain--especially in regards to ia32 emulation. It is not required for a Tier-1 platform to have 32-bit support. Our UltraSparc platform does not have 32-bit support. Nor does any other of our 64-bit platforms. We also have these boards, I've found them unusable under FreeBSD/5.3-STABLE with 8GB of RAM--other qualities appear to work okay. But I even saw some infrequent problems with 6GB. This problem is of course valid. This is a really lamentable situation. We've been a primarily FreeBSD shop for 10 years now and for the past 4 years or so a pure FreeBSD shop. Switching to linux on just these machines has been quite the headache but I'm holding on to the hope that FreeBSD/amd64 will shape up. FreeBSD/amd64 will only get better with your bug reports, testing, and feedback. I searched the GNATS PR database and only saw you've submitted 2 PR's for something we don't claim to really support (32-bit binaries on 64-bit OS). Please submit a PR for the Broadcom and 8GB issues. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible problems with Broadcom BCM5704C 10/100/1000 on Tyan Motherboard
[ PLEASE don't top post - it losses context, and this is a Unix mailing list] On Tue, Feb 15, 2005 at 04:53:24PM -, Alan Jay wrote: I had major problems installing with more than 4Gb but once I moved to stable we seemed to have a stable platform when doing basic stuff - we have two databases (mySQL) one is reasonably heavily used and one very extensively used. Just to be clear, you're stating you had stability problems with 5.3-RELEASE and 4GB. But with 5.3-STABLE and 4GB you have a stable system. Correct? I think I agree wholeheartedly with your comments being a great supporter of FreeBSD it is a shame that the AMD release is not as super as the other versions we have used extensively. The problem is a major bug that has existed since FreeBSD ?3.0? was exposed very close to the 5.3 release cycle. This bug only causes a major problem with 4GB, thus few of us developers experienced it. [Most of us can't afford 4GB in our machines. Donations of 1GB DIMMs for FreeBSD developers are accepted by [EMAIL PROTECTED] Of course one reason many are moving to the AMD64 platform is to have 4GB RAM in the machine. We believe this bug has been fixed in 5.3-STABLE. But too few people are testing 5.3-STABLE and are using 5.3-RELEASE instead. This isn't helping us QA the issue so that we know all the corner cases are fixed in upcoming 5.4 release. A recent 5.3-STABLE snapshot can be found as ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/Feb_2005/5.3-STABLE-SNAP001-amd64-miniinst.iso and mirrors. -- -- David ([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII first official patches - please test!
On Sun, Feb 13, 2005 at 07:08:33PM +0100, Anthony Ginepro wrote:
- Retrying call doadump under a kernel without touching ATA_R_DEBUG,
it worked eventually once and could be canceled. Most of the time, dump
can't be canceled and doesn't progress.
Should I open a PR so that the issue can be tracked ?
This is what I have to do with ATAng to dump to an IDE disk, via Peter Wemm.
Maybe it will help you find a work around with mkIII.
Index: ata-all.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.234
diff -u -r1.234 ata-all.c
--- ata-all.c 24 Nov 2004 10:47:26 - 1.234
+++ ata-all.c 3 Dec 2004 00:46:03 -
@@ -375,6 +375,8 @@
struct ata_channel *ch;
int ctlr;
+if (panicstr) return;
+
/* flush cache on all devices */
for (ctlr = 0; ctlr devclass_get_maxunit(ata_devclass); ctlr++) {
if (!(ch = devclass_get_softc(ata_devclass, ctlr)))
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII first official patches - please test!
On Wed, Feb 09, 2005 at 03:00:50PM +0100, S?ren Schmidt wrote: S?ren Schmidt wrote: New version that fixes known problems so far etc now available: http://people.freebsd.org/~sos/ata-mk3k.tar.gz .. As always, enjoy and let me know how it goes... This does indead fix my panic that I reported to you. I'd like to add a wishlist item, that is really needed for the sparc64 platform. Currently hw.ata.ata_dma is a binary knob. I'd like to see it changed so that if the value isn't 0 or 1, then the value is taken to be the fastest dma to use. Values would be 2, 33, 66, 100, 133 (for completeness). My Sun Blade100 has an ATA66 controller, but other than the original disk with Sun firmware, no other ATA66 capable disk will work in the machine with either ATAng or ATA-mkIII unless I force the speed to udma33 or slower. FreeBSD doesn't currently have a good way to achieve this that we can easily do for the installation CDROM. -- -- David([EMAIL PROTECTED]) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No RAID for VT8237?
On Tue, Nov 30, 2004 at 11:09:34AM +, Bob Bishop wrote: You might try an 'atacontrol create etc'. I had a problem where I'd defined RAID1 in the BIOS, but 5.3 wouldn't see it (specifically saw the drives individually but no ar0); after atacontrol create... it all works. Go fig. This isn't weird. By using 'atacontrol create' yourself, you have a pure-software RAID same as you would have with ccd(4). The difference from defineing it in your software-assist RAID BIOS is that you can boot off the RAID. With the pure-software RAID you cannot[*]. [*] Unless your PATA/SATA RAID controller just happens to understand the metadata used by 'atacontrol create'. A 'atacontrol create' RAID1 (mirror) might also be bootable, I'm not sure about that; but a RAID0 (stripe) certainly isn't. There are many new SATA RAID controllers that our ATA driver doesn't yet understand the metadata. Soren is working on support for these newer chipsets. -- -- David([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Beastie
On Mon, Nov 29, 2004 at 12:25:59PM +1100, Edwin Groothuis wrote: On Sun, Nov 28, 2004 at 05:23:40PM -0800, Kris Kennaway wrote: On Sun, Nov 28, 2004 at 07:16:12PM -0600, Stephen Montgomery-Smith wrote: It is with a little intrepidation that I ask this question, because I sense that what I am about to ask might push some buttons, or perhaps bring back some unpleasant memories of those who have asked what I am going to ask in a less tactful manner. I find that the beastie that appears at boot time with FreeBSD 5.3 mildly bothers me. It is possible for me to edit boot/beastie.4th, but this gets put back each time I do make installworld. Would it be possible to add a variable show_beastie to be put in /boot/loader.conf, which would default to YES, but users could add in show_beastie=NO if they didn't want it, but only want the menu. That option is already there, you didn't look hard enough. It's not really the easiest option to find kris... beastie_disable=YES What do you suggest to make it easier? -- -- David([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No RAID for VT8237?
On Tue, Nov 30, 2004 at 09:38:19PM -0500, Mike Jakubik wrote: David O'Brien said: There are many new SATA RAID controllers that our ATA driver doesn't yet understand the metadata. Soren is working on support for these newer chipsets. Understood, but what im saying is that a list of supported ones would be very useful when trying to decide what hardware to buy. The problem is that the RAID metadata isn't identical for all motherboards that use the same SATA controller -- it is dependent on the BIOS also. For instance, I have an Iwill DK8X that has a Silicon Image 3114 controller. On many motherboards using the SiI 3114 FreeBSD knows the RAID metadata, however on this motherboard FreeBSD doesn't -- because my BIOS does things differently than other motherboards with a SiI 3114. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Valgrind for FreeBSD
On Fri, Apr 23, 2004 at 05:00:30PM +0200, Simon Barner wrote: After consultation with Doug Rabson, I have created ports for valgrind (stable version and a more ``bleeding edge'' development version). Until they hit the tree (probably after the ports freeze), you can get them at: http://home.leo.org/~barner/freebsd/valgrind/ Please rename valgrind-devel-port to valgrind-snapshot-port. thanks, -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Alpha 4.8 RC2 -- COME AND GET IT!!
Now available at ftp://ftp.freebsd.org/pub/FreeBSD/releases/alpha/ISO-IMAGES/4.8-RC2 and ftp://ftp.freebsd.org/pub/FreeBSD/releases/alpha/4.8-RC2 -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: adding athlon xp to bsd.cpu.mk
On Mon, Oct 29, 2001 at 10:29:00AM -0800, matt wrote: any one know if my 4.3 stable work with all AMD processors, as well as with SMP enabled? Yes it will. I certifed 4.3 RELEASE (and thus 4.3-STABLE) on the SMP Thunder for AMD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: time_t definition is worng
On Sat, Jun 02, 2001 at 01:23:05AM -0700, Matt Dillon wrote: Yes, I know all that. The problem isn't that you couldn't have an unsigned time_t, the problem is that there are vast amounts of software already out there that would break mysteriously if you did. So, like the int-long problem, the best thing to do is not rock the boat. That means for maximum portability time_t has to be a signed long. Not int, not unsigned int, not unsigned long... just 'long'. There is not enough context here for me to get any idea what the issue is. This email argued signed vs. unsigned, and that has nothing to do with time_t being an int. Since on IA-32 int == long, the only issue is what ones uses in printf() and scanf(). I have not seen anyone having a problem with this yet. So I ask you to bring this up on [EMAIL PROTECTED] why time_t needs to be a long. If you had more multi-platform concerns you would understand why having as consistent defintions of things is best for FreeBSD. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: time_t definition is worng
On Sun, Jun 03, 2001 at 01:05:18AM +0900, Yoshihiro Koya wrote: Hello, From: David O'Brien [EMAIL PROTECTED] Subject: Re: time_t definition is worng Date: Sat, 2 Jun 2001 08:52:37 -0700 Message-ID: [EMAIL PROTECTED] Since on IA-32 int == long, the only issue is what ones uses in printf() and scanf(). I have not seen anyone having a problem with this yet. Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=27757 and the response to this PR. This PR seems to be a signed vs. unsigned issue. Maybe it is too early in the morning, so please explain why int(32-bit) vs. long(32-bit) [on x86] is an issue for this PR. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Releases
On Mon, Apr 09, 2001 at 01:38:15PM -0400, Michael R. Rudel wrote: x.x-BETA is ... notoriously buggy. It has bugs, that's the point of the x.y-GAMMA rather than x.y-BETA might would be a good move. Then we'd have 1/2 the world asking what "GAMMA" means. We could then hit over the head them with the cluebat and maybe it would stick. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Can I stop BUILDWORLD from starting from scratch?
On Mon, Apr 09, 2001 at 04:16:45PM -0700, Christian Chen wrote: But why is "something" breaking ? The build process should be clean. If not, something is messed in your source code repository. Well, I know that when I installed 4.2-RELEASE off of CD, make world in /usr/src did not work. You've got big problems then. It would be worth your time to figure out *why* it broke. As other things are liable to be broken for you. If the source from the 4.2-RELEASE CD did not build, there would be no 4.2-RELEASE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: how to track stable
On Tue, Apr 10, 2001 at 05:36:20PM -0400, FreeBSD Admin wrote: Please bear with me. I have tried to understand this process, but still it is not clear to me. I have read http://www.freebsd.org/handbook/current-stable.html http://www.freebsd.org/handbook/synching.html http://www.freebsd.org/handbook/makeworld.html http://www.freebsd.org/handbook/anoncvs.html http://www.freebsd.org/handbook/cvsup.html ... Can someone point me to a clear step-by-step explanation of how to do We do think these are clear explanations. Perhaps you should tell us _WHY_ you do not think they are, so we'd know how to phrase our responses such that they aren't verbatim from the above docs. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cvsupped to RELENG_4 but got 4.3-RC
On Wed, Apr 04, 2001 at 09:32:39PM -0500, Brian D. Woodruff wrote: I quickly learned that RC is for Release Candidate, which would inticate to me that it's somewhere between CURRENT and RELEASE, but nowhere near STABLE!! Huh? RC means it could easily be _the_ RELEASE. In FreeBSD RC is more stable than "stable" as the code is frozen. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
*sigh* Alpha release broken
Setting up /boot directory for kern floppy /R/stage/image.kern/kernel: 63.2% -- replaced with /R/stage/image.kern/kernel.gz sh -e /usr/src/release/scripts/doFS.sh /R/stage/floppies/kern.flp /R/stage /mnt 1440 /R/stage/image.kern 8 fd1440 Warning: Block size restricts cylinders per group to 6. Warning: 1216 sector(s) in last cylinder unallocated /dev/rvnn0c:2880 sectors in 1 cylinders of 1 tracks, 4096 sectors 1.4MB in 1 cyl groups (6 c/g, 12.00MB/g, 32 i/g) super-block backups (for fsck -b #) at: 32 cpio: write error: No space left on device *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: failed to buildworld... (make: don't know how to make build-
On Sun, Mar 04, 2001 at 03:42:51PM -0600, Conrad Sabatier wrote: Nope. Forgot to commit the MFC in src/bin/csh Will the libdisk, etc. fixes be merged in anytime soon? Make buildworld is still broken. Still working on it. It would help if my -CURRENT NFS server would stop hanging... :-( It is now getting upgraded from -CURRENT to RELENG_4. So I'll have any buildworld problems fixed ASAP! -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: buildworld failure (3-4-2001 cvsup)
On Sun, Mar 04, 2001 at 10:16:47PM +0200, Alexandr A. Listopad wrote:
Uh, I'm waiting for it... ;{
To tell the truth, I would *HIGHLY* suggest that most users not even try
to update their RELENG_4 -STABLE systems for the next 2-3 days. Right
before a code freeze there is always a lot of commit activity.
I would suggest that only those that are interested in debugging build
problems (and suppling patches) be active right now.
--
-- David([EMAIL PROTECTED])
Disclaimer: Not speaking for FreeBSD, just expressing my own opinion.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: C++ threaded programs
On Thu, Jan 04, 2001 at 01:16:49AM +0200, Roman Shterenzon wrote: On the other side, I tested Daniel's patch - i.e. -nostdlib in libstdc++ and it works fine for everything I've tested it with - the only It matters ZILCH that that patch worked for you. What that patch does is just wrong. It was posted to help us pin down the problematic area. I need feedback on *my* current patch, nothing else. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: C++ threaded programs
On Wed, Jan 03, 2001 at 09:21:50PM -0600, Erich Zigler wrote: I have been unable to get anyone I've directly asked to actually test it (that emailed me saying they have a problem with the current state of the world). Here is what happened after test1.. This is a program called mq3 it is written in C++ and uses qt's threaded library. I applied your patch, rebuilt my world. I fail to see you say my app filed on a *stock* world, and in these way(s). Thus if I don't know what you're starting with, this feedback isn't very helpful. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Threaded C++ Question
On Wed, Jan 03, 2001 at 01:57:24PM -0600, David W. Chapman Jr. wrote: That was the same problem I encountered (*sarcasm*) Well that was very helpful. How about telling me how *_I_* can experience it? I'm about to give up and just drop fixing this as no one is able to give me any feedback. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, Dec 08, 2000 at 12:07:49AM -0700, Chad R. Larson wrote: I thought the space staked out by the *BSD gang was approximately this: NetBSD - the least amount of platform-specific code possible; run on most anything OpenBSD - pro-active security, bullet-proof from attacks FreeBSD - best performing on the Intel PC platform s/the Intel PC/server/ The Alpha has very good I/O bandwidth and 64-bit address space. Thus it fits our niche. You also mentioned Sparc, but really should have said sparc64(pci based). hopefully embeded soon too. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Password Encryption Problems
On Wed, Nov 29, 2000 at 12:26:56PM +0100, O. Hartmann wrote: Last week, I installed a new user and its password seems to be definitely encrypted by DES, but today's encrypted passwords seems to be MD5 although I did not change anything I assume this was mentioned in the 4.2 Release notes -- if not someone really should have put this in there. Anyway, `man login.conf' and look for "passwd_format". Why? Has anything changed in FreeBSD in the meanwhile? Yes. I'll let someome else give the why and how. IMHO, there should be a "I want MD5 by default, but when changing a password keep the hash format the same" option. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: file: table is full
On Wed, Nov 29, 2000 at 09:10:25AM -0800, Mike Smith wrote: If 'maxusers' is less than 128, bump that up first. Then you can try defining MAXFILES in your config file if you still hit the limit; check the output of 'sysctl kern.maxfiles' to find what it's currently at. You can also do it dyanmically by: root# /sbin/sysctl -w kern.maxfiles=2048 root# /sbin/sysctl -w kern.maxfilesperproc=1024 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Dedicated disks (was: Dangerously Dedicated)
On Thu, Nov 23, 2000 at 06:43:33AM +0100, Cyrille Lefevre wrote: can someone remember me the problem w/ DD ? Geez, we've just had a 30 message thread that stated many times the problem with dang.ded. drives. well, I don't have tested anything since I don't have any free drive to burn, but the spirit is here, no ? Use a vn(4) device as your "disk". You can then try things to your hearts content. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Cannot make buildworld
On Tue, Nov 21, 2000 at 08:58:14AM +0100, Jose Luis Arbona Orovay wrote:
Is this documented ?
If you kept up with this mailing list, you would have known this problem.
That is why I just gave the "what to do" rather than give an explanation.
Please review the recent archives when you have a problem.
Why should we do that ?
You must have CVSup'ed during a window of time when I was changing the
way we build crt{begin,end}.o. This caused the build problem you
experienced.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Removal of Disklabel
On Tue, Nov 21, 2000 at 03:59:15PM +1100, Gregory Bond wrote: I know of no Unix variant with more than 8 partitions/ disk OpenBSD has 16 / disk. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cd /usr/ports; make clean
On Sun, Nov 19, 2000 at 12:35:27AM -0600, David Kelly wrote: I'm sure to be off my rocker to suggest something like this 2 days before -RELEASE, but sometimes I don't clean up after installing a port ^^ WHY are you posting this in the -stable list?? This has nothing to do with anything specific to -stable. This 100% belongs in [EMAIL PROTECTED] Please stay on-topic. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: New US CVSup mirrors
On Fri, Nov 17, 2000 at 04:34:14PM -0500, Mike Tancsa wrote: Super. I know this has come up before, but what if you also added a few overloaded A records for those who want to spread the load automatically, and do it in a somewhat random way. Since you know it has come up before, please to re-read the archives on why this isn't a good idea. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ftpd from BSDI 4.1
On Wed, Nov 15, 2000 at 12:52:39PM +, Kaltashkin Eugene wrote: When in FreeBSD be ftpd server from BSDI 4.1 ? Him support virtual servers and very customisable config. It is my intention to change FreeBSD's ftpd to the Luke M. version in NetBSD. Luke's ftpd provides a very, very nice alternative to the wu-ftpd one (unless you like security vulnerabilities). Switching also moves us to one very much maintained and shares more code with our BSD brotheren where where is no reason not to. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version (consensus?)
On Tue, Nov 14, 2000 at 04:03:19PM -0600, Jeffrey J. Mountin wrote: Is the bump going to happen before 4.2 or not? I don't know. I'd like to hear Satoshi's response to my last email on the topic. The typical test [in this case] would be does a 4.0R shared binary still run fine on a 4.2-R system. No one has brought this up as the case. And for the example given, I don't know how bumping libc's shared version number will solve the problem. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
On Tue, Nov 14, 2000 at 02:15:49PM -0800, Satoshi - Ports Wraith - Asami wrote:
Hmm. That's a good point. So you mean there is no way to build a
libc that works for 4.2 that will also work with a 4.0 kernel?
Yes.
(I don't think just changing the libc source on a 4.0 machine will
accomplish that. Besides, that sounds even more dangerous, to build
something with mixed sources.)
IF 4.2-R libc sources would compile on a 4.0-R system the resulting
libc.so.4 will work much better than using a stock 4.2-R libc.so.4. This
is because the /usr/include/sys/ and /usr/include/machine/ headers
(especially the syscall ones) used to compile the 4.2-R libc sources will
match the 4.0-R kernel. Interface changes (as exposed) in /sys/sys and
/sys/arch/include are one of the bigger ways to get a kernel and
userland out of sync.
However, incompatible is incompatible and it seems to me that we should
still bump the version of libc just to make sure people won't get into
a similar situation by copying supposedly compatible shared library.
Maybe but this is unix where we kinda give people all the rope the
need... Switching to a versioned API would probably help this issue.
But it increases the library and toolchain maintenance.
(If libc was at so.5 in the upgrade kit it at least wouldn't have
killed existing binaries.)
I guess that would be one approach... but I fear it will lead us to bump
the version at every release. I think this could increase support
questions.
By the way, if the conclusion is that we can't provide an upgrade kit
that will work for 4.0R (regardless of whether we bump libc or not),
I'll just replace that package with something that prints "sorry, we
can't support that system anymore, please upgrade".
If you've got space [and time] to build a special libc.so.4 for 4.[01]-R,
using 4.2 libc (only) sources, it should work well. Of course at some
point it is a hopeless cause, as there will be some change to the libc
sources that requires changes in /usr/include/{sys,machine}/ .
In the merging of xpg4 into libc using the various Binutils utils.
JDP would know more about the viability of this than I do.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: 4.1.1-STABLE buildworld fails on libiberty.a
On Sat, Nov 11, 2000 at 11:42:46PM -0500, Jon Nathan wrote: i'm trying to upgrade a 3.2 box to 4.x. when i tried make buildworld, it bailed on miniperl. so i tried -DNOPERL, as suggested in the lists: Upgrade to RELENG_3 first. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Is sockstat broken in -stable?
On Tue, Nov 07, 2000 at 09:18:01AM -0800, John Polstra wrote: On a -stable system from October 31, I'm seeing this from sockstat: I get the same on my Nov 5th Alpha -current box, but not on my Nov 5th -current i386 box. Also on my Oct 31st 4.1.1-STABLE Alpha box. I would say it is an Alpha problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: burnt by the new crtbegin ?
On Wed, Nov 01, 2000 at 12:50:09PM -0500, Bill Fumerola wrote: cd /usr/src/lib/csu/i386-elf make cleandir ; make cleandir ; make obj ; make depend ; make all install cd /usr/src/gnu/lib/csu make cleandir ; make cleandir ; make obj ; make depend ; make all install This is a workaround and a better solution that make world takes care of is coming, right? No. This is a workaround for those that tried to update their systems during a window of vulnerability. I haven't heard of any problems updating from 4-STABLE before the weekend. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
** HEADS UP ** changes to /usr/lib/crt*.o
I'm about to MFC this. Again, please run as many old apps as you can to
see if this causes any problems.
- Forwarded message from David O'Brien [EMAIL PROTECTED] -
I am switching us from using or native crt{begin,end}.c to GCC's
crtstuff.c in the building of /usr/lib/crt{begin,end}.o.
- End forwarded message -
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: making a RELEASE
On Wed, Aug 02, 2000 at 11:42:50AM +0100, Dominic Mitchell wrote: I cvsup-ed all src collections, including ports and doc (i.e. src-all, doc-all and ports-all). ... Wich path should I give to CVSROOT dir ? You need to download the the cvs collections, not the "checked-out" collections for make release to work. You could also set CVSROOT to the anoncvs.freebsd.org service. This would be slower, but save you disk space. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: bioscall.s
On Mon, Jul 17, 2000 at 10:58:06AM -0400, Keith Mackay wrote: Is there a known issue in bioscall.s? Yes, it has been documented all over the place in this mailing list. It is also documented in /usr/src/UPDATING. You should review the expectations of running -STABLE and consider if you are better off just sticking with the released product. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: More optimization issues?
On Tue, Jul 11, 2000 at 07:48:33PM -0400, Chris D. Faulhaber wrote: While porting another program, I found the following: Using the default CXXFLAGS (-O -pipe): $ g++ -O -pipe ud2cd.cc -o ud2cd I don't believe this... (*sigh*). Remove the "-O" and it compiles fine on both -CURRENT and a 4-STABLE box before the Assember / Linker upgrade. Use ``g++ -Wall'' and ``g++ -O -Wall'' on the first (that works) you are given two warnings about the code. With "-O" you only get one of the warnings (and bad linking). The only difference is in the call to to ``cpp'' in which which "-O" causes "-D__OPTIMIZE__" (use ``g++ -v'' to see this). -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel build fail
Ted Sikora wrote: I just installed 4.0-RELEASE and cvsup'ed to STABLE. The kernel build fails with an Assembler error. I always do a kernel build before a makeworld. I hate to break tradition. Then you should wait for 4.1-RELEASE to come out and install that (in this case). You should be able to keep with tradition then. Rather you should wait for 4.1-RELEAES to come out and install that because YOU HAVE NO BUSINESS RUNNING 4-STABLE IF YOU ARE *_NOT_* GOING TO READ THIS MAILING LIST FOR "HEADS UP" AND OTHER ISSUES. -- -- David ([EMAIL PROTECTED]) Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: kernel build fail
On Tue, Jul 11, 2000 at 07:47:19PM -0700, Marcel Moolenaar wrote: make build/installkernel. All's well except now Linux emulation is broken. Any linux app produces: ELF interpreter /lib/ld-linux.so.2 not found Abort trap I believe this is caused by a change in how we brand binaries. rebrand /compat/linux/sbin/ldconfig and run it. Actually in 4-STABLE one should not need to rebrand their Linux binaries. If anyone finds they need(ed) to, I need to know ASAP!! -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problems with make world
On Tue, Jul 11, 2000 at 04:36:33PM -0400, Will Mitayai Keeso Rowe wrote: the error: cc -O6 -pipe -march=pentiumpro -I/usr/src/usr.bin/ar -Wall -I/usr/obj/usr/ ^^ Would you care to explain to me just what the hell you think you are achieving with "-O6"??? For one, no released version of GCC understands anything above "-O3" (anything above 3 gets converted to 3). RTFM. Have you done a single measure to see what the extra optimization is buying you? OR do you just want to be macho and so you can tell everyone your world is built with "-O6"? (As I stand up straight and stick out my chest like a military man) FreeBSD only officially supports building the OS with "-O". There are optimizer bugs above that (and even sometimes with just -O). -- -- David ([EMAIL PROTECTED]) Disclaimer: Not speaking for FreeBSD, just expressing my own opinion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: restarting buildworld
On Tue, Jul 11, 2000 at 12:31:47AM -0700, Jason C. Wells wrote: Is there a way to start buildworld without having it remove and rebuild the /usr/obj directory? There are bunches of command line options in /usr/src/Makefile*. I believe the one you want is 'make -DNOCLEAN' but read the makefile to be sure. ^^^ 'make -DNOCLEAN buildworld' (or 'make -DNOCLEAN world') -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: random.h - again...
On Tue, Jul 11, 2000 at 04:00:14PM -0400, Joakim Ryden wrote: Hi all, I cvsupped - built and installed world and went to make a new kernel. The kernel build fails with: === syscons/fire make: don't know how to make machine/random.h. Stop *** Error code 2 I cannot reproduce this. Can anyone? (ONLY "YES" answers need reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Next release should be called 5.0 (was:4.4 BSD forever?)
On Tue, Jan 11, 2000 at 08:48:08AM -0800, Cy Schubert - ITSD Open Systems Group wrote: UCB and ATT had agreed that there were to be no new releases of BSD and that 4BSD was the final release. 4.1BSD - 4.4BSD were named such because they were "officially" only modifications to 4BSD and as such were not full releases. In fact they contained more new features than previous releases and were modifications to 4BSD in name only. This is a quote from McKusick on a previous post. It doesn't seem to back up your statements. As I understood it, 4BSD was to be the last release based on 32V and ATT wouldn't license anything newer on agreeable terms, so Berkeley released 4.1. 4.1c (later renamed to 4.2) was released to fullfil their contractual obligation to DARPA. At least that's the scuttlebutt at the time, which likely suffered from at least some "telephone game" syndrome. ATT kept wanting Berkeley to move forward to a newer license, but we resisted because the newer licenses were considerably more expensive. That had nothing to do with the naming. The 4.1 release was called that because ATT was concerned that there would be confusion in the marketplace if there were System V and 5BSD, so we agreed to call it 4.1 instead of 5.0. The 4.1c release was never renamed 4.2. The 4.2 release followed 4.1c. The 4.1c release was what would probably be called an alpha release of 4.2 today. It's all in Kirk's book the Design and Implementation of 4.4BSD. What page numbers? -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4 BSD forever?
the 5.x releases, I'm gonna have to think about taking down the ole poster with `4.4 5.4' on it (not that that would be a *bad* thing, I just wonder if I can find where said poster is hanging in this mess) Your Mt. Xinu poster is being underutilized (and underappreciated). It isn't a Mt. Xinu poster. It is a BSDI poster with the Daemon on it and it did say "4.4 5.4". "5.4" refered to System V Rel. 4., which was fairly new at the time. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4 BSD forever?
On Sat, Jan 08, 2000 at 01:38:05AM -0800, Joseph Scott wrote: Perhaps we should skip version 4.4 of FreeBSD out of respect for our fore fathers. ( IE: release versions 4.0, 4.1, 4.2, 4.3, 4.5 ). It would kind of feel strange to have a release version of 4.4 for FreeBSD. If I have anything to do with it, there will be a FreeBSD 4.5 so the world will know what comes after 4.4BSD. The only nostalgic issues is if we should release the 4.x series as "4.xFreeBSD". -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: vim-5.5.67
On Sat, Jan 08, 2000 at 04:53:14PM +, Mark Ovens wrote: Use the vim-lite port, or build vim5 using # make LITE=yes install (which is all the vim-lite port does) Acutally if you build Vim locally on an X-less machine, the X11 support will keep out since you don't the libs + headers. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: When does the 4.x branch go stable?
On Mon, Jan 10, 2000 at 12:40:54AM -0500, Coleman Kane wrote: Obviously, you have never tried to make world with the new egcs, it is almost WHY do you need to make world with GCC 2.95.2? Gcc 2.7.2 acutally produces smaller code. For some things even faster code. What is so glammorous about a Gcc 2.95 built world and kernel? Use the base compiler to compile the product and install the `egcs' port for your own code. The big short falling with Gcc 2.7.2 is a total piece of crap C++ compiler. Since the only thing written in C++ in /usr/src/ is groff (and very old style C++), who cares. impossible since there are many violations of ANSI C and C++ in the code right now. The kernel does, however, properly compile (minus some ext2fs crap). Send patches then, if you are a programmer. -- -- David([EMAIL PROTECTED]) [maintainer of /usr/src/contrib/gcc, `gcc-devel', `egcs', `pgcc'] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: When does the 4.x branch go stable?
Brad please don't spread falsness. On Mon, Jan 10, 2000 at 02:19:10PM +0100, Brad Knowles wrote: There are also some issues with laptops and PC Cards, especially CardBus cards. No version of FreeBSD does or ever has supported CardBus. So there can't be any 4.0 issues here. There are issues with PCCard support (ie, the 16-bit, not 32-bit devices). few adaptec aha1542b's that are running very well, some of teh ..snip.. Watch the older cards. I think that AHA152x series support was 154x != 152x. FreeBSD has *always* supported the AHA-154x [minus a a month or so after the CAM switch while the `aha' driver was being updated]. just recently added back into 3.x-STABLE, specifically with 3.4-RELEASE (at least, I recall seeing that when last I read the RELEASE_NOTES). I don't recall whether or not they're supported under 4.x-CURRENT. The `aic' driver came into -CURRENT first as it has to. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: When does the 4.x branch go stable?
On Mon, Jan 10, 2000 at 03:42:04PM -0500, Coleman Kane wrote: Follow the link, dude. ..snip.. David O'Brien had the audacity to say: But your table doesn't say which compiler was used for what. Thus I can't tell what that table is telling me. My apologies. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: /sbin/dhclient-script and llinfo error
On Tue, Dec 07, 1999 at 11:23:54AM -0500, Brandon Fosdick wrote: I asked the same question abot a month ago and didn't get an answer. A quick search of the archives will find some others with the same problem. It seems to I got the report, but got busy and forgot about it (as it has never caused me problems). Let me try to revisit the patch for 3.4. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
On Thu, Nov 11, 1999 at 03:14:04PM -0800, Mike Meyer wrote: ;-It belongs in /usr/local. I don't agree. Things being maintainted and supported locally belong in /usr/local. Ports and packages come on the distribution, and you go back to the same channels for support as you do for core parts of that distribution. I'll have to agree with you here. I think it was a grave mistake for FreeBSD to install packages into /usr/local/. We should have used /usr/pkg/ as NetBSD did. As GCC maintainer, I will not add /usr/local/lib to the list of automatically looked places in the base compiler. For one it isn't PREFIX clean. [ Please remember one can set PREFIX=/usr/pkg and build the Ports Collection ] -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
On Thu, Nov 11, 1999 at 05:34:23PM -0800, Mike Meyer wrote: Except, of course, that /usr/local/lib *does* get special treatment! It's listed in ldconfig_paths (and the aout subdir ldconfig_paths_aout), along with /usr/X11R6/lib /usr/lib/compat. None of those are part of the OS, though all are part of the distribution. This seems a tad inconsistent. We make sure that the person installing Yes, but ldconfig_paths is in the rc.conf configuration file. -L paths are hardcoded and compiled into GCC and friends. The user can change ldconfig_paths as they need to. There isn't an easy way for them to change the auto -L list. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
On Fri, Nov 12, 1999 at 12:24:53PM -0800, Duane H. Hesser wrote: A few still have 'local' hardwired in, but after many years of ... The X11 situation is not quite as rosy; there have been quite a few which needed hand patching. The problem seems to be a lot of Imakefiles with BINDIR, INCROOT, MANPATH, and USRLIBDIR hard-coded to use /usr/local. Even so, hand-patching these has not been much of a burden. Please send a PR on these. We want to make everything PREFIX clean. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: installworld : problem 1 (softupdates)
Softupdates doesn't buy you anything on reads -- just writes. So unless you have it turned on for / because /tmp is on /, you aren't getting anything out of softupdates than frustration. Does softupdates score you something over MFS for /tmp ? Nope. MFS's are async by default. One of the big advantages of softupdates is the speed of full async mounts, with the stability of sync mounts. With an MFS, you newfs at every reboot, so you don't care if a crash pukes on your fs. -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
**HEADS UP** libreadline version number reverted
On 19-Aug-1999 I bumped the shared library major version number from "3" to "4" when I MFC'ed libreadline-4.0. It has been deemed that the interface change between readline-2.2 and readline-4.0 was not suffient to warrant the version number bump. Thus I have reverted it back to "3". Those that either installed the 19990819 or 19990820 SNAPSHOT, or did a ``CVSup'' and ``make world'' in the past two days will need to perform the below immediately before their next ``make world'': cd /usr/lib ls -l libreadline.so.4 (if you have /usr/lib/libreadline.so.4) mv libreadline.so.4 libreadline.so.3 rm -f libreadline.so ln -s libreadline.so.3 libreadline.so -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
