Re: -CURRENT is bad for me...

On Mon, Feb 12, 2001 at 07:59:03AM -0500, Daniel Eischen wrote: Did you miss the HEADS UP posted to -current? You better read these. Somehow, I just didn't notice that there is a HEADS UP. I have bang my head to the wall because of this sillyness I've done :( I have just reformat my box, and

Re: cvs commit: ports/palm/pilot-link Makefile

At Wed, 14 Feb 2001 14:50:25 -0800 (PST), Jun Kuriyama wrote: kuriyama2001/02/14 14:50:25 PST Modified files: palm/pilot-link Makefile Log: - Add write permission at post-patch stage to be able to build by non-root users. - Remove -O flag from CFLAGS due to

Failed to build kdesupport2 port

Hi folks... I am on a FreeBSD 5.0-20010210-CURRENT box. This is a clean system, I installed it from current.freebsd.org I tried to build kdesupport2 port, but it failed. Somehow, when checking for Qt, kdesupport2 configure script died. However, I installed qt 2.2.4 from port cleanly, no errors

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Wed, Feb 14, 2001 at 12:47:59AM +, Paul Richards wrote: Instead what we have now is libxyz.so.3 and libxyz.so.3 which are different from each other. No different than two libxyz.so.3.1 and libxyz.so.3.1 could be (a.out days). (well not entirely true, but in the a.out days, one could

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

David O'Brien wrote: We only bumped due to interface changes in the .MAJOR.MINOR days. The difference is *adding* an interface today does in cause a bump. In the .MAJOR.MINOR days it would require a bump the MINOR number. In both days, an incompatible change in an existing interface

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Thu, Feb 15, 2001 at 11:14:38AM +, Paul Richards wrote: Commercial vendors will skip version numbers in their public releases if their internal development required more than one bump. Which ones? Sun Solaris still ships their libc as "libc.so.1", even in Solaris 8. -- -- David

Backward binary compatibility with libc/libm

Seems some 4.x/3.x binary that is linked with libm.so does not work on 5-CURRENT because libm.so is not properly associated with (the latest) libc.so. So, when a program lets libm refers to __stdout/__stderr from within, it fails as follows. :( /usr/libexec/ld-elf.so.1:

-lc_r against shared library (Re: Failed to build kdesupport2 port)

If you paid attention to -ports, you found adding CONFIGURE_ARGS= "LIBS=-pthread" to kdesupport2/Makefile would help. There are some way to ``fix'' this problem: a) linking -lc_r against libGL. This is denied by John Polstra and he suggested (b). He said libc and libc_r must be strictly

Re: cvs commit: ports/palm/pilot-link Makefile

I believe this is bug in g++ optimizasion, at least 2.95.3 prerelease. Using -O2 or higher (which impiles -frerun-cse-after-loop) works. Many ports using g++ are hit by this... -- FUJISHIMA Satsuki At Thu, 15 Feb 2001 18:28:10 +0900, Akinori MUSHA wrote: c++ -I./include -I./include -O

Re: Backward binary compatibility with libc/libm

At Thu, 15 Feb 2001 20:47:57 +0900, I wrote: Seems some 4.x/3.x binary that is linked with libm.so does not work on 5-CURRENT because libm.so is not properly associated with (the latest) libc.so. So, when a program lets libm refers to __stdout/__stderr from within, it fails as follows.

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

David O'Brien wrote: On Thu, Feb 15, 2001 at 11:14:38AM +, Paul Richards wrote: Commercial vendors will skip version numbers in their public releases if their internal development required more than one bump. Which ones? Sun Solaris still ships their libc as "libc.so.1", even in

libgtop on CURRENT

It is necessary to update libgtop for CURRENT as attached. I haven't yet got an idea how to fix it to shut up the following error messages, though. LibGTop-Server: kvm_getargv (12): Undefined error: 0 LibGTop-Server: kvm_getargv (11): Undefined error: 0 LibGTop-Server:

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

FUJISHIMA Satsuki wrote: If you paid attention to -ports, you found adding CONFIGURE_ARGS= "LIBS=-pthread" to kdesupport2/Makefile would help. There are some way to ``fix'' this problem: c) Use -lc_r instead of -pthread. As -pthread will be depreciated, we should use -lc_r for

Re: cvs commit: ports/palm/pilot-link Makefile

"Akinori MUSHA" [EMAIL PROTECTED] writes: However, if I put either: CXXFLAGS+=-fPIC or: CFLAGS!= ${ECHO} "${CFLAGS}" | ${SED} -e 's/-O[0-9a-z]*//g' IMHO, this could be rewritten as ${CFLAGS:N-O*} which is more clean than forking a subshell. Cyrille. -- home: mailto:[EMAIL

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

On Thu, Feb 15, 2001 at 02:51:51PM +0200, Maxim Sobolev wrote: CONFIGURE_ARGS= "LIBS=-pthread" to kdesupport2/Makefile would help. There are some way to ``fix'' this problem: c) Use -lc_r instead of -pthread. As -pthread will be depreciated, we should use -lc_r for FreeBSD 5.0 and

Re: libgtop on CURRENT

On Thu, Feb 15, 2001 at 09:48:13PM +0900, Akinori MUSHA wrote: It is necessary to update libgtop for CURRENT as attached. I haven't yet got an idea how to fix it to shut up the following error messages, though. My -current box was a victim of -current a while back. It's currently on RR

Re: Backward binary compatibility with libc/libm

In message [EMAIL PROTECTED] "Akinori MUSHA" writes: : Seems some 4.x/3.x binary that is linked with libm.so does not work on : 5-CURRENT because libm.so is not properly associated with (the latest) : libc.so. : : So, when a program lets libm refers to __stdout/__stderr from within, : it fails

Re: Backward binary compatibility with libc/libm

In message [EMAIL PROTECTED] "Akinori MUSHA" writes: : Oops, obviously I missed the 'Major bumping of libFOO' thread. Take : msun into account as well, thanks. I had forgotten about msun :-(. However, I think we're going to try to do this without an interface change in libc that breaks things

Fix for mountpath lenght

In mount.h, we have a #define MNAMELEN80 and in struct statfs {} we have: charf_mntonname[MNAMELEN]; /* directory on which mounted */ but the kernel does no check to see if the mountpath is longer than MNAMELEN, it just accepts it ? It's impossible to umount(8) it, because

Re: Fix for mountpath lenght

This looks right, except that Bruce says that SCARG isn't to be used, instead just use uap-path. -Alfred * Martin Blapp [EMAIL PROTECTED] [010215 09:46] wrote: In mount.h, we have a #define MNAMELEN80 and in struct statfs {} we have: charf_mntonname[MNAMELEN]; /* directory

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

John Indra wrote: On Thu, Feb 15, 2001 at 02:51:51PM +0200, Maxim Sobolev wrote: CONFIGURE_ARGS= "LIBS=-pthread" to kdesupport2/Makefile would help. There are some way to ``fix'' this problem: c) Use -lc_r instead of -pthread. As -pthread will be depreciated, we should use -lc_r

Re: Fix for mountpath lenght

* Alfred Perlstein [EMAIL PROTECTED] [010215 10:15] wrote: This looks right, except that Bruce says that SCARG isn't to be used, instead just use uap-path. Also, you can't call strlen on a userland pointer. please test patches before submitting them! -Alfred * Martin Blapp [EMAIL

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

[ CC list trimmed ] On Thu, 15 Feb 2001, Maxim Sobolev wrote: You have totally misunderstood the purpose of my patch. The patch *isn't* intended as a quick fix for the recent -lc_r/-pthread weirdness, but instead it would provide porting team with infrastructure necessary to start converting

Re: NEWCARD xl0: watchdog timeout

On Wed, Feb 14, 2001 at 05:52:27PM -0500, Will Andrews wrote: On Wed, Feb 14, 2001 at 10:19:24PM +0100, Pierre DAVID wrote: I just upgraded my Dell Latitude LT from 4.2-RELEASE TO -current (just before 9h Feb): all is working perfectly with a GENERIC kernel, pccardd and a 3Com 3C589

Re: -lc_r against shared library (Re: Failed to build kdesupport2 port)

Daniel Eischen wrote: [ CC list trimmed ] On Thu, 15 Feb 2001, Maxim Sobolev wrote: You have totally misunderstood the purpose of my patch. The patch *isn't* intended as a quick fix for the recent -lc_r/-pthread weirdness, but instead it would provide porting team with infrastructure

Re: Fix for mountpath lenght

As has been pointed out, this is simply incorrect due to an attempt to use kernel string operators on a string in the kernel address space. Generally speaking, it's a bad idea to explicitly perform string activities on userland strings, instead, to rely on the bounds checking in copyinstr() and

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

On Thu, Feb 15, 2001 at 12:44:26PM +, Paul Richards_imap/mail.originative.co.uk/Inbox.sbd/New Mail.sbd/OpenLDAP.sbd/Devel wrote: I suggest you take a look at http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Yes, I know how

REVERSE the AGING PROCESS 10 - 20 Years!

HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF

Re: cvs commit: ports/palm/pilot-link Makefile

On Thu, Feb 15, 2001 at 06:28:10PM +0900, Akinori MUSHA wrote: knu@archon[2]% uname -a FreeBSD archon.local.idaemons.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Feb 14 16:49:24 JST 2001 [EMAIL PROTECTED]:/villa/work/obj/freebsd/src/usr/local/src/sys/ARCHON i386 knu@archon[2]% gcc

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

I suggest you take a look at http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ Thank you ! This confused the hell out of me when I first bumped into it on Solaris ! Something to read in the morning -- Brian [EMAIL PROTECTED]

That site for buying and selling businesses V

Hey That site on the net for buying and selling businesses is http://bsab.com.au This is the one that Craig Simmons told us he sold his shop from. I've checked it out - it looks great - but I do see a problem for you in that nobody is going to pay you $950k for your business unless you move

Re: OpenSSL ASM patch

On 2001-Feb-11 13:02:43 -0800, Alfred Perlstein [EMAIL PROTECTED] wrote: * Kris Kennaway [EMAIL PROTECTED] [010211 12:52] wrote: On Sun, Feb 11, 2001 at 12:47:07PM -0800, Alfred Perlstein wrote: Is it possible to have multiple ASM cores and use the appropriate routines? Or must it all be

Re: Fix for mountpath lenght

On Thu, 15 Feb 2001, Robert Watson wrote: As has been pointed out, this is simply incorrect due to an attempt to use kernel string operators on a string in the kernel address space. Generally speaking, it's a bad idea to explicitly perform string activities on userland strings, instead, to

Re: OpenSSL ASM patch

On Fri, Feb 16, 2001 at 03:57:57PM +1100, Peter Jeremy wrote: I'm sure something similar would be possible with FreeBSD, but I don't have the expertise to actually implement it. I'm less certain how much of a win this would be in the general scheme of things: Apart from special cases (like

Re: HEADSUP! change to atapi-cd driver and burncd

Hi all, I've been getting errors with "burncd" that I've not seen before. Specifically, I'm seeing the following: chapel-hill# burncd -f /dev/acd1c -s 4 blank data *1.iso fixate blanking CD - 100 % done burncd: ioctl(CDRIOCNEXTWRITEABLEADDR): Device busy chapel-hill# Trace messages from

Re: HEADSUP! change to atapi-cd driver and burncd

It seems Kent Hauser wrote: Hi all, I've been getting errors with "burncd" that I've not seen before. Specifically, I'm seeing the following: chapel-hill# burncd -f /dev/acd1c -s 4 blank data *1.iso fixate blanking CD - 100 % done burncd: ioctl(CDRIOCNEXTWRITEABLEADDR): Device busy

Re: HEADSUP! change to atapi-cd driver and burncd

This is because some sloppy firmware coders hasn't implemented the "test unit ready" command proberly, it return ready no matter what state the drive is in :( I've gotten ahold of one burner that has this problem and I'm trying to come up with a fix for it... Is this the same problem I was

Re: HEADSUP! change to atapi-cd driver and burncd

It seems Kenneth Wayne Culver wrote: This is because some sloppy firmware coders hasn't implemented the "test unit ready" command proberly, it return ready no matter what state the drive is in :( I've gotten ahold of one burner that has this problem and I'm trying to come up with a fix