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 now running: 5.0-20010210-CURRENT I think this is currently the last known good snapshot in current.freebsd.org To get around the installworld problem, do: Too late. I have just, for the first time since running -CURRENT feel the sorrow of running -CURRENT. He3x... But I'm not complaining. I take this as a challenge and as a reminder to not miss any more HEADS UPs ;) Thanks anyway for the help... Dan Eischen /john To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 c++'s optimization bug. Seems you can avoid the problem by adding the following line to Makefile instead of eliminating -O* from CFLAGS. CXXFLAGS+= -fPIC Now, I make a bug report out of this case for David. First, I have the following environment here: 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 --version 2.95.3 knu@archon[2]% make -V CFLAGS -O -march=pentiumpro -pipe And then when I try to build the palm/pilot-link port as of yesterday, I get this: knu@archon[2]% make === Extracting for pilot-link-0.9.3 Checksum OK for pilot-link.0.9.3.tar.gz. === pilot-link-0.9.3 depends on executable: libtool - found === pilot-link-0.9.3 depends on shared library: tk82.1 - found === Patching for pilot-link-0.9.3 === Applying FreeBSD patches for pilot-link-0.9.3 === Configuring for pilot-link-0.9.3 creating cache ./config.cache checking host system type... i386--freebsd5.0 checking for gcc... cc checking whether the C compiler (cc -O -march=pentiumpro -pipe ) works... yes checking whether the C compiler (cc -O -march=pentiumpro -pipe ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether cc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel checking for ranlib... ranlib checking for ld used by GCC... /usr/libexec/elf/ld checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes checking for BSD-compatible nm... test: /home/knu/bin/nm: unexpected operator /usr/bin/nm -B checking whether ln -s works... yes checking for object suffix... o checking for executable suffix... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.lo... yes checking if cc supports -fno-rtti -fno-exceptions ... yes checking if cc static flag -static works... -static checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes checking whether the linker (/usr/libexec/elf/ld) supports shared libraries... yes checking command to parse /usr/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/libexec/elf/ld option to reload object files... -r checking dynamic linker characteristics... freebsd5.0 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool checking for ranlib... (cached) ranlib checking for bison... no checking for byacc... byacc checking for c++... c++ checking whether C++ compiler (c++ ) works... yes checking whether we are using GNU C++... yes checking whether c++ accepts -g... yes checking for main in -lg++... no checking for ldexp in -lm... yes checking for alloca in -lPW... no checking for readline... 2.1 checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for fcntl.h... yes checking for malloc.h... no checking for sys/ioctl.h... yes checking for sys/time.h... yes checking for sys/ioctl_compat.h... yes checking for memory.h... yes checking for string.h... yes checking for strings.h... yes checking for unistd.h... yes checking for stdlib.h... yes checking for netinet/in.h... yes checking for dirent.h... yes checking for sys/ndir.h... no checking for sys/dir.h... no checking for ndir.h... no checking for sys/select.h... yes checking for sockio.h... no checking for netdb.h... yes checking for sys/utsname.h... yes checking for working const... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for connect... yes checking for gethostbyname... yes checking for main in -linet... no checking whether cc needs -traditional... no checking return type of signal handlers... void checking for atexit... yes checking for strchr... yes checking for strdup... yes checking for memcpy... yes checking for memmove... yes checking for strtoul... yes checking for cfmakeraw... yes checking for cfsetspeed... yes checking for cfsetispeed... yes checking for cfsetospeed... yes checking for sigaction... yes checking for dup2... yes checking for inet_aton... yes checking for gethostname... yes checking for uname... yes checking for putenv... yes checking for cispeed and cospeed members of struct termios... yes checking for sa_len... yes checking for Java Development Kit... not found checking for Tcl... version 8.2 from
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 whatsoever.
My version of /usr/src/contrib/gcc.295/config/freebsd.h is
v 1.32 2001/02/08 05:27:17
BTW the only different file from my system is that I applied this
patch from Maxim Sobolev to /usr/port/Mk/bsd.port.mk:
--- bsd.port.mk 2001/02/08 19:09:54 1.2
+++ bsd.port.mk 2001/02/08 19:15:50
@@ -948,6 +948,14 @@
MAKEFILE?= Makefile
MAKE_ENV+= PREFIX=${PREFIX} LOCALBASE=${LOCALBASE} X11BASE=${X11BAS
E} MOTIFLIB="${MOTIFLIB}" LIBDIR="${LIBDIR}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXF
LAGS}"
+.if ${OSVERSION} 50
+PTHREAD_CFLAGS=-D_THREAD_SAFE
+PTHREAD_LIBS= "-pthread"
+.else
+PTHREAD_CFLAGS=""
+PTHREAD_LIBS= "-lc_r"
+.endif
+
.if exists(/usr/bin/fetch)
# avoid -A for 2.2 -- it's not ported to that branch
.if ${OSVERSION} 30
Attached is the failure log of my kdesupport2 build.
Am I the only one having this problem?
Thanks...
/john
Script started on Thu Feb 15 11:01:48 2001
[root@dante kdesupport2]# make install
=== Extracting for kdesupport-2.0.1
Checksum OK for kdesupport-2.0.1.tar.bz2.
=== kdesupport-2.0.1 depends on executable: bzip2 - found
=== kdesupport-2.0.1 depends on executable: gmake - found
=== kdesupport-2.0.1 depends on shared library: png.4 - found
=== kdesupport-2.0.1 depends on shared library: jpeg.9 - found
=== kdesupport-2.0.1 depends on shared library: qt2.4 - found
=== Patching for kdesupport-2.0.1
=== Applying FreeBSD patches for kdesupport-2.0.1
=== Configuring for kdesupport-2.0.1
/usr/bin/perl -pi -e "s@TOPSUBDIRS libaps@TOPSUBDIRS@g ; s@odbc libaps@odbc@g"
/usr/ports/converters/kdesupport2/work/kdesupport-2.0.1/configure
/usr/bin/perl -pi -e "s@-version-info 1:1@-version-info 3:0@g"
/usr/ports/converters/kdesupport2/work/kdesupport-2.0.1/mimelib/Makefile.in
creating cache ./config.cache
checking host system type... i386--freebsd5.0
checking target system type... i386--freebsd5.0
checking build system type... i386--freebsd5.0
checking for a BSD compatible install... /usr/bin/install -c -o root -g wheel
checking whether build environment is sane... yes
checking whether gmake sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for a C-Compiler... cc
checking whether the C compiler (cc -O -pipe -mcpu=i686 -march=i686 ) works... yes
checking whether the C compiler (cc -O -pipe -mcpu=i686 -march=i686 ) is a
cross-compiler... no
checking whether we are using GNU C... yes
checking how to run the C preprocessor... cc -E
checking for a C++-Compiler... c++
checking whether the C++ compiler (c++ -O -pipe -mcpu=i686 -march=i686 ) works... yes
checking whether the C++ compiler (c++ -O -pipe -mcpu=i686 -march=i686 ) is a
cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ supports -fno-exceptions... yes
checking whether c++ supports -fno-check-new... yes
checking whether c++ supports -Wno-long-long... yes
checking whether c++ supports -fno-builtin... yes
checking whether c++ supports -fexceptions... yes
checking whether c++ supports -frtti... yes
checking how to run the C++ preprocessor... c++ -E
checking whether c++ supports -frepo... yes
checking for ld used by GCC... /usr/libexec/elf/ld
checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes
checking for /usr/libexec/elf/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking for ranlib... ranlib
checking for strip... strip
checking for Cygwin environment... no
checking for mingw32 environment... no
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking whether -lc should be explicitly linked in... yes
checking for objdir... .libs
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -fno-rtti -fno-exceptions ... yes
checking whether the linker (/usr/libexec/elf/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... freebsd5.0 ld.so
checking command to parse /usr/bin/nm -B output... ok
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for dlopen in -ldl... no
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 make a major change in the functionality of a lib routine w/o even a minor bump) If two libxyz.so.3 and libxyz.so.3 are incompatible, then a major shared version bump wasn't done when it should have been. When you login to a strange machine and you're trying to diagnose a problem there's no way to know whether the libc they've got installed is of version X or version Y because there's nothing to tell you what sources libc.so.Z was built from, it could be the .Z version with the X fixes or the Y fixes. When we had minor version numbers you still didnt' know if the X fixes or Y fixes were in it. You've missed the point I was trying to make. Our reluctance to bump what we perceive to be a major number is hampering our ability to differentiate between different versions. We aren't reluctant to bump in -STABLE if there is a need for it. The reluctance is in -CURRENT where we bump once and let that cover all the incompatibilities. We don't put our released version users thru the hoops we are willing to for the development version users. We could just as easily use a minor numbering scheme with Elf to indicate that a version change has occured but not an interface change. 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 require(s)(ed) a MAJOR bump. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 require(s)(ed) a MAJOR bump. Yes, that was true. The way we used to do it didn't address all the problems I'm alluding to either but I felt we had more versioning before than we do now. Regardless of that the issues are important enough that I think we should discuss them. There are in my mind two issues: 1) Being able to have the system continue working when a significant interface change occurs. 2) Being able to identify a specific version of a library on a system in order to determine whether it's a rogue version for a particular application. The former I accept works fine now as long as you can take the pain of current. An asthetic requirement to have a nice library number is counter-productive though when it screws the development team so completely that the system is unusable for a week. While developers should accept that they must occasionally suffer considerable pain when running -current it's foolish to not consider alternative methods of working when we run into a problem that causes the project to come to a grinding halt. Most of us don't have rooms full of development boxes, we have all our day to day applications on our development box and having to rebuild it completely is something we accept we may have to do on occasion but it's something we should try and avoid having to happen because it's so wasteful of everyone's time and energy. This library version problem is a non-problem from a technological perspective, it's only a problem from a policy perspective and it's a policy that's based entirely on asthetic requirements. I don't want to see library versions get into the hundreds (unless we adopt that as a convention i.e. 5xx) because we're bumping them all the time but at the same time, if one is necessary then it's necessary, even if it's current. Commercial vendors will skip version numbers in their public releases if their internal development required more than one bump. I don't think the attempt to make the major number bump once per release is a sensible goal. If we have to bump a major number on the stable branch (god forbid, but it may happen one day) then we'll have to deviate from that policy because it'll clash with the version number of -current and therefore I think the policy is flawed because it doesn't consider all the possible scenarios we might have to deal with. The second issue is probably not related to bumping the library version, since I accept your point that we didn't bump major or minor numbers for every change to the library. I think some way of identifying a build of a library would be a good thing though and perhaps we should discuss adding a "properties" field to libraries so we can identify which specific version of a library is installed. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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: /usr/lib/libm.so.2: Undefined symbol "__stderr" Unfortunately, it applies to some important bits like JDK 1.1.8... As a workaround, adding LDADD=-lc to src/lib/msun/Makefile seems to do the trick and get it working. Ideas, anyone? -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-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 synchronized. If so, this might be a bad idea. b) adding -pthread to each port which uses libGL. This method needs some work but if this is the way to go, we should start fixing broken ports. So many ports are broken with -pthread now. c) Use -lc_r instead of -pthread. As -pthread will be depreciated, we should use -lc_r for FreeBSD 5.0 and later, shouldn't we? d) [Please add your opinions] -- FUJISHIMA Satsuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 -march=pentiumpro -pipe -DREADLINE_2_1 -DLIBDIR=\"/usr/local/pilot/lib\" -DTCL -DTK -I/usr/local/include/tcl8.2 -I/usr/local/include/tk8.2 -I/usr/X11R6/include iambicexample.o libsock/.libs/libpisock.so getopt.o getopt1.o libcc/libpicc.a -o .libs/iambicexample -lm -Wl,--rpath -Wl,/usr/local/pilot/lib iambicexample.o: In function `main': iambicexample.o(.text+0x11b9): undefined reference to `L765' *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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. :( /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol "__stderr" Unfortunately, it applies to some important bits like JDK 1.1.8... As a workaround, adding LDADD=-lc to src/lib/msun/Makefile seems to do the trick and get it working. Oops, obviously I missed the 'Major bumping of libFOO' thread. Take msun into account as well, thanks. -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
2001-02-15
Thread
Paul Richards_imap/mail.originative.co.uk/Inbox.sbd/New Mail.sbd/OpenLDAP.sbd/Devel
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 Solaris 8. I suggest you take a look at http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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: kvm_getargv (10): Undefined error: 0
By the way, you'd better split patches into per-file patches..
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"We're only at home when we're on the run, on the wing, on the fly"
Index: Makefile
===
RCS file: /home/ncvs/ports/devel/libgtop/Makefile,v
retrieving revision 1.40
diff -u -r1.40 Makefile
--- Makefile2000/12/28 02:35:31 1.40
+++ Makefile2001/02/15 12:35:38
@@ -7,7 +7,7 @@
PORTNAME= libgtop
PORTVERSION= 1.0.10
-PORTREVISION= 3
+PORTREVISION= 4
CATEGORIES=devel gnome
MASTER_SITES= ${MASTER_SITE_GNOME}
MASTER_SITE_SUBDIR=stable/sources/libgtop
Index: files/patch-aj
===
RCS file: /home/ncvs/ports/devel/libgtop/files/patch-aj,v
retrieving revision 1.2
diff -u -r1.2 patch-aj
--- files/patch-aj 2000/12/28 02:35:34 1.2
+++ files/patch-aj 2001/02/14 16:24:33
@@ -71,9 +71,9 @@
- switch (pinfo [0].kp_proc.p_stat) {
+ switch (pinfo [0].XXX_P_STAT) {
case SIDL:
sysdeps/freebsd/procuid.c.orig Thu Sep 16 16:08:07 1999
-+++ sysdeps/freebsd/procuid.c Fri Dec 22 18:37:41 2000
-@@ -86,13 +86,38 @@
+--- sysdeps/freebsd/procuid.c.orig Fri Sep 17 06:08:07 1999
sysdeps/freebsd/procuid.c Thu Feb 15 01:16:50 2001
+@@ -86,13 +86,42 @@
- buf-uid = pinfo [0].kp_eproc.e_pcred.p_ruid;
- buf-euid = pinfo [0].kp_eproc.e_pcred.p_svuid;
@@ -95,7 +95,11 @@
+#define XXX_E_PGID ki_pgid
+#define XXX_E_TPGID ki_tpgid
+#define XXX_P_NICE ki_nice
++#if __FreeBSD_version = 500013
++#define XXX_P_PRIORITY ki_pri.pri_user
++#else
+#define XXX_P_PRIORITY ki_priority
++#endif
+#else
+
+#define XXX_P_RUID kp_eproc.e_pcred.p_ruid
@@ -122,8 +126,8 @@
+ buf-nice = pinfo [0].XXX_P_NICE;
+ buf-priority = pinfo [0].XXX_P_PRIORITY;
sysdeps/freebsd/proctime.c.origThu Sep 16 16:08:07 1999
-+++ sysdeps/freebsd/proctime.c Fri Dec 22 22:45:57 2000
+--- sysdeps/freebsd/proctime.c.origFri Sep 17 06:08:07 1999
sysdeps/freebsd/proctime.c Thu Feb 15 01:15:11 2001
@@ -68,5 +68,2 @@
u_quad_t u, st, ut, it, tot;
-#if (__FreeBSD_version 33)
@@ -150,10 +154,14 @@
- buf-rtime = tv2sec (pinfo [0].kp_proc.p_rtime);
+ buf-rtime = pinfo [0].kp_proc.p_runtime;
#endif
-@@ -194,2 +186,13 @@
+@@ -194,2 +186,17 @@
#else
+#if __FreeBSD_version = 500013
++#if __FreeBSD_version = 500016
++ if ((pinfo [0].ki_flag PS_INMEM)) {
++#else
+ if ((pinfo [0].ki_flag P_INMEM)) {
++#endif
+ buf-utime = pinfo [0].ki_runtime;
+ buf-stime = 0; /* XXX */
+ buf-cutime = tv2sec (pinfo [0].ki_childtime);
@@ -164,7 +172,7 @@
+
+#else
glibtop_suid_enter (server);
-@@ -224,2 +227,3 @@
+@@ -224,2 +231,3 @@
}
+#endif
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 FreeBSD 5.0 and later, shouldn't we? Yes, it looks like a most appropriate solution to me. If you read -ports, recently I proposed to add a small patch for the bsd.port.mk to help with transition process, but have not heard anything back from PW yet. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 PROTECTED] UNIX is user-friendly; it's just particular
work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 later, shouldn't we?
Yes, it looks like a most appropriate solution to me. If you read -ports,
recently I proposed to add a small patch for the bsd.port.mk to help with
transition process, but have not heard anything back from PW yet.
Either I do it the wrong way, or you are not paying attention to my
first message thoroughly. I HAVE applied your patch to my
/usr/ports/Mk/bsd.port.mk! But still, I failed to build kdesupport2
So, here's the summary of what I have done:
1. Reformat hard drive (cause I have a broken -CURRENT caused by FILE struct
changes)
2. Install from current.freebsd.org a -CURRENT snapshot of 2210
3. cvsup the latest ports tree
4. Applied Maxim Sobolev patch against my /usr/ports/Mk/bsd.port.mk
The patch is:
--- bsd.port.mk 2001/02/08 19:09:54 1.2
+++ bsd.port.mk 2001/02/08 19:15:50
@@ -948,6 +948,14 @@
MAKEFILE?= Makefile
MAKE_ENV+= PREFIX=${PREFIX} LOCALBASE=${LOCALBASE} X11BASE=${X11BASE}
MOTIFLIB="${MOTIFLIB}" LIBDIR="${LIBDIR}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}"
+.if ${OSVERSION} 50
+PTHREAD_CFLAGS=-D_THREAD_SAFE
+PTHREAD_LIBS= "-pthread"
+.else
+PTHREAD_CFLAGS=""
+PTHREAD_LIBS= "-lc_r"
+.endif
+
.if exists(/usr/bin/fetch)
# avoid -A for 2.2 -- it's not ported to that branch
.if ${OSVERSION} 30
Correct isn't it?
5. Start building my ports
6. Everything from XFree86-4.0.2_6 to qt-2.2.4 build and installed just fine
7. kdesupport2 started bombing error messages
So, if after all of this I SHOULD have not undergone any errors, then the
mistakes is on me, please forgive me for wasting your time and bandwith.
I am only seeking for some enlightenment.
-Maxim
/john
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 before I threaten it again. LibGTop-Server: kvm_getargv (12): Undefined error: 0 LibGTop-Server: kvm_getargv (11): Undefined error: 0 LibGTop-Server: kvm_getargv (10): Undefined error: 0 Hmm.. looks like the whole enchilada needs to have kvm calls ripped out of it. I'll look at your patches, and try and integrate them into the new release. -aDe -- Ade Lovett, Austin, TX.[EMAIL PROTECTED] FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 as follows. :( : : /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol "__stderr" : : Unfortunately, it applies to some important bits like JDK 1.1.8... : : As a workaround, adding LDADD=-lc to src/lib/msun/Makefile seems to : do the trick and get it working. : : Ideas, anyone? Do not use -current after 2000-02-10. They are broken. I'm working with others to integrate a fix that doesn't break things like this. I'll post something to -current and -arch when the buildworld finishes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 so badly. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 umount(8) does not like to unmount some device which
does not belong to the mountpoint.
--- vfs_syscalls.c Sun Nov 26 03:30:05 2000
+++ vfs_syscalls.c.new Thu Feb 15 18:22:13 2001
@@ -140,6 +140,8 @@
/*
* Get vnode to be covered
*/
+ if (strlen(SCARG(uap, path)) MNAMELEN)
+ return (ENAMETOOLONG);
NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE,
SCARG(uap, path), p);
if ((error = namei(nd)) != 0)
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133 Pratteln, Switzerland
Phone: +41 79 370 26 05, Fax: +41 61 826 93 01
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 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 umount(8) does not like to unmount some device which
does not belong to the mountpoint.
--- vfs_syscalls.c Sun Nov 26 03:30:05 2000
+++ vfs_syscalls.c.new Thu Feb 15 18:22:13 2001
@@ -140,6 +140,8 @@
/*
* Get vnode to be covered
*/
+ if (strlen(SCARG(uap, path)) MNAMELEN)
+ return (ENAMETOOLONG);
NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE,
SCARG(uap, path), p);
if ((error = namei(nd)) != 0)
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133 Pratteln, Switzerland
Phone: +41 79 370 26 05, Fax: +41 61 826 93 01
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 for FreeBSD
5.0 and later, shouldn't we?
Yes, it looks like a most appropriate solution to me. If you read -ports,
recently I proposed to add a small patch for the bsd.port.mk to help with
transition process, but have not heard anything back from PW yet.
Either I do it the wrong way, or you are not paying attention to my
first message thoroughly. I HAVE applied your patch to my
/usr/ports/Mk/bsd.port.mk! But still, I failed to build kdesupport2
So, here's the summary of what I have done:
1. Reformat hard drive (cause I have a broken -CURRENT caused by FILE struct
changes)
2. Install from current.freebsd.org a -CURRENT snapshot of 2210
3. cvsup the latest ports tree
4. Applied Maxim Sobolev patch against my /usr/ports/Mk/bsd.port.mk
The patch is:
--- bsd.port.mk 2001/02/08 19:09:54 1.2
+++ bsd.port.mk 2001/02/08 19:15:50
@@ -948,6 +948,14 @@
MAKEFILE?= Makefile
MAKE_ENV+= PREFIX=${PREFIX} LOCALBASE=${LOCALBASE} X11BASE=${X11BASE}
MOTIFLIB="${MOTIFLIB}" LIBDIR="${LIBDIR}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}"
+.if ${OSVERSION} 50
+PTHREAD_CFLAGS=-D_THREAD_SAFE
+PTHREAD_LIBS= "-pthread"
+.else
+PTHREAD_CFLAGS=""
+PTHREAD_LIBS= "-lc_r"
+.endif
+
.if exists(/usr/bin/fetch)
# avoid -A for 2.2 -- it's not ported to that branch
.if ${OSVERSION} 30
Correct isn't it?
5. Start building my ports
6. Everything from XFree86-4.0.2_6 to qt-2.2.4 build and installed just fine
7. kdesupport2 started bombing error messages
So, if after all of this I SHOULD have not undergone any errors, then the
mistakes is on me, please forgive me for wasting your time and bandwith.
I am only seeking for some enlightenment.
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 existing ports to the
new world order. In a nutshell, -pthread should be replaced with ${PTHREAD_LIBS} and
-D_THREAD_SAFE with ${PTHREAD_CFLAGS} in all Makefiles from the ports collection. In
addition all places where -pthread hardcoded in patches should also be identified and
adjusted to respect ${PTHREAD_LIBS} and ${PTHREAD_CFLAGS}.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 PROTECTED] [010215 09:46] wrote:
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 umount(8) does not like to unmount some device which
does not belong to the mountpoint.
--- vfs_syscalls.c Sun Nov 26 03:30:05 2000
+++ vfs_syscalls.c.new Thu Feb 15 18:22:13 2001
@@ -140,6 +140,8 @@
/*
* Get vnode to be covered
*/
+ if (strlen(SCARG(uap, path)) MNAMELEN)
+ return (ENAMETOOLONG);
NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE,
SCARG(uap, path), p);
if ((error = namei(nd)) != 0)
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133 Pratteln, Switzerland
Phone: +41 79 370 26 05, Fax: +41 61 826 93 01
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 existing ports to the
new world order. In a nutshell, -pthread should be replaced with ${PTHREAD_LIBS} and
-D_THREAD_SAFE with ${PTHREAD_CFLAGS} in all Makefiles from the ports collection. In
addition all places where -pthread hardcoded in patches should also be identified and
adjusted to respect ${PTHREAD_LIBS} and ${PTHREAD_CFLAGS}.
I support the addition of PTHREAD_CFLAGS/PTHREAD_LIBS to bsd.port.mk. It
allows one to specify exactly which threads library they want to use
(build against), even linuxthreads I would think.
If it matters, I think we've decided to keep the -pthread linker
option until FreeBSD gets its own libpthread at which point -pthread
will be deprecated. So there's no urgent rush to convert ports
to use the new mechanism if it's adopted.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 Ethernet card. I hope you are aware that -CURRENT is experimental and at times can be extremely unstable. Many thanks for your attention. I am a regular -current user from at least 4 years, and I know what -current means. Also, NEWCARD is really not supposed to be used unless you are planning on working on it. If nobody is using NEWCARD because of such warning, I wonder when NEWCARD will be functionnal for joe user. Be aware that I already tried the same NEWCARD kernel from a Sony Vaio and another Dell. - with the 3Com 3C589, I cannot get anything from the network (ECHO packets are emitted, but nothing returns) Hmm, that's odd. More precisely, ECHO packets are emitted from the NEWCARD machine, ECHO reply are transmitted by the pinged host, but nothing is received by the NEWCARD machine, which is typical of an IRQ problem. - with a 3Com 3CCFE575BT-D (xl0) - which works like a charm with a Sony Vaio - I get lot of: xl0: watchdog timeout and all communications are sloow. I smell an IRQ conflict. Many thanks for your helpful diagnostic ;-) Pierre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 necessary to start converting existing ports to
the new world order. In a nutshell, -pthread should be replaced with ${PTHREAD_LIBS}
and
-D_THREAD_SAFE with ${PTHREAD_CFLAGS} in all Makefiles from the ports collection.
In addition all places where -pthread hardcoded in patches should also be identified
and
adjusted to respect ${PTHREAD_LIBS} and ${PTHREAD_CFLAGS}.
I support the addition of PTHREAD_CFLAGS/PTHREAD_LIBS to bsd.port.mk. It
allows one to specify exactly which threads library they want to use
(build against), even linuxthreads I would think.
If it matters, I think we've decided to keep the -pthread linker
option until FreeBSD gets its own libpthread at which point -pthread
will be deprecated. So there's no urgent rush to convert ports
to use the new mechanism if it's adopted.
You are not quite right (unfortunately). The current behaviour or -pthread breaks lots
of ports because by default gcc doesn't link shared modules with -lc_r even with this
flag, thus requiring that you to explicitly specify -pthread or -lc_r when linking
program with shared library that uses pthreads. Good example of such breakage is libGL
from
XFree86-4. This library requires pthreads, but most programs that use this library
don't use threads and as such have no idea why they need -pthread to link with libGL.
Therefore we have several choices:
1. Fix bazillion GL ports and ports with similar breakage by explicitly adding
-pthread into each one (poor choice IMO);
2. Make -pthread flag link shared modules with -lc_r (jdp is against this for not very
clear to me reasons);
3. Use -lc_r instead of -pthread in all threaded ports, which is equivalent to 2, BTW,
but jdp have no control over this.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 related calls. The namei has all appropriate bounds checks it needs
for normal nul-termianted string reading from userland. If you need to
place an artificially low bound on the string length for a path name that
is to be read in, and reject based on the pathname length, then namei() is
probably not the right call to pull in the string in the first place. For
many reasons, including that if shared memory is in use, then there's a
race condition under SMP that can let malicious processes update the path
between the two checks as they are non-atomic.
What is it you're trying to accomplish here, exactly? Is it prevent paths
MNAMELEN to be used as targets of mounting operations? Or is it to
truncate strings reported via statfs to some arbitrary bound? If it's the
former, I think we need to be eliminating that need and moving to the
latter. If it's the latter, then we need to perform the truncation
wherefer f_mntfromname is set. That appears to be, btw, in vfs_mount()
for each filesystem, and in vfs_rootmountalloc(). A quick glance at UFS
seems to indicate that the MNAMELEN limit is already enforced there, and
that this is the right solution.
On Thu, 15 Feb 2001, Martin Blapp wrote:
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 umount(8) does not like to unmount some device which
does not belong to the mountpoint.
--- vfs_syscalls.c Sun Nov 26 03:30:05 2000
+++ vfs_syscalls.c.new Thu Feb 15 18:22:13 2001
@@ -140,6 +140,8 @@
/*
* Get vnode to be covered
*/
+ if (strlen(SCARG(uap, path)) MNAMELEN)
+ return (ENAMETOOLONG);
NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE,
SCARG(uap, path), p);
if ((error = namei(nd)) != 0)
Martin Blapp, [EMAIL PROTECTED]
Improware AG, UNIX solution and service provider
Zurlindenstrasse 29, 4133 Pratteln, Switzerland
Phone: +41 79 370 26 05, Fax: +41 61 826 93 01
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 Solaris does symbol versioning. FreeBSD does not have this technology today, so we cannot use it instead. The Linux way of doing this still has problems (see the Binutils mailing list). I'm waiting for the Linux way of doing this to fully settle and prove itself before I look at maybe using it for FreeBSD. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat Without Dieting Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10-20 years in 6 months of usage !!! You don't have to spend thousands of dollars on shots. You don't have to spend the $139.00 per bottle that HGH is selling for at some Clinics in the United States. For the next 30 Days, you can obtain a complete one-month supply of our HGH releaser for our special "New Customers" price of just $69.95 plus $6.00 shipping and handling. To ensure a constant supply and to SAVE EVEN MORE, you can order with confidence 3 bottles of HGH and GET 1 FREE - that's just $209.85 for 4 bottles, plus $6.00 shipping and handling. You SAVE $69.95! ORDER TODAY! Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, American Express payments. Money Orders are accepted only by Postal Mail. Step 1: Place a check by your desired quanity. __ 1 Bottle of HGH $69.95 __ 2 Bottles of HGH $131.90 ($65.95 a bottle) __ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85 Please add $6 shipping and handling for any size order. [ Total cost including shipping handling, 1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ] International shipping, please add $35 for any size order [ Total cost including shipping handling, 1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ] Foreign checks are not accepted. Credit cards international money orders only. Step 2: Place a check by your desired payment method and complete fields if necessary. _Check or CHECK-BY-FAX [details below] _Money Order _American Express Account Number__ Exp/ _Visa Account Number__ Exp/ _MasterCard Account Number__ Exp/ Please make your check or money order payable to "LSN". Step 3: Please complete and print the following fields clearly. Name ___ Address _ City State ___ Zip _ E-mail __ Signature _ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print mail to: LSN 273 S. State Rd. 7 #193 Margate, FL 33068-5727 __ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer easier ! TAPE CHECK BELOW _ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: HGH is not intended to diagnose, treat, cure or prevent any disease. The FDA has not evaluated these statements. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 --version 2.95.3 ...snip.. On the other hand, on another box it goes fine: knu@daemon[1]% uname -a FreeBSD daemon.local.idaemons.org 4.2-STABLE FreeBSD 4.2-STABLE #0: Wed Jan 31 16:01:53 JST 2001 [EMAIL PROTECTED]:/var/work/world/usr/src/sys/DAEMON i386 knu@daemon[1]% gcc --version 2.95.2 I could **REALLY** use help from someone to pin point the problem. I just found out, I have very,very limited time to get needed FreeBSD changes into GCC 3.0, Binutils 2.11, and the way over-due 2.95.3. To test this, either compile and install the 2.95.3-test1 compiler on an updated RELENG_4 using the -CURRENT sources (just change /usr/src/contrib/gcc.295/config/freebsd.h to make __FreeBSD__=4 rather than "5". And/Or on a 5-CURRENT box showing the problem, back out the 2.95.3-test1 compiler by: cd /usr/src/contrib/gcc.295 cvs up -rBEFORE_GCC_2_95_3 cd /usr/src/gnu/usr.bin/cc cvs up -rBEFORE_GCC_2_95_3 make cleandir make cleandir make obj make all install -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 to NT. Every other place in Australia has your type of business for far less and making more money. ONLY KIDDING - Check it out it has all the information on buying and selling a Business in Australia and it has stacks of businesses for sale and people looking for businesses. Here is the link http://www.bsab.com.au/ I've put a ad up in wanted to buy today it's free Have a look at my ad click on this http://www.bsab.com.au/boardinfo.asp?IDnum=140 Hey don't send me your business I can't handle paying Johnnie 100k in tax each year like you and supporting your sister too. Give me a call after you look at this site greg
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 choosen at compile time? It's done at compile-time. bah, lame. :( AFAIK, Solaris does this by (very roughly) having /usr/lib/libfoo.so depend on /usr/lib/machine/libfoo.so, where /usr/lib/machine is a symlink to the relevant set of architecture-specific libraries. The dynamic loading preferentially uses the machine-specific library. This means you get architecture-optimised routines with no additional overheads. 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 OpenSSL), I don't think the libraries have a significant impact on overall performance. IMHO, the main market for this feature would be people who just do binary installs - if you're doing a buildworld, you can tune to your hardware[1]. If we wanted to just speed up OpenSSL on binary installs, we could have processor-optimised variants of libssl.* available as packages (tick the box that suits your processor if you want the optimised library). [1] I don't think there's a lot of `build once, install on lots of different hardware', though I could be wrong. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 rely on the bounds checking in copyinstr() and related calls. The patch also seems to have a fatal off-by-2 error. It would only have a fatal off-by-1 error, but most filesystems seem to have a benign off-by-1 error. E.g., ffs uses copyinstr() but defeats copyinstr()'s "right" handling of the terminating NUL by subtracting one from the array size. copyinstr(9) has the usual unclearness about NUL terminators for this. The NUL terminator is included in the strings "long"ness for both the input and the output args. This is only documented explicitly for the output arg. The namei has all appropriate bounds checks it needs for normal nul-termianted string reading from userland. If you need to place an artificially low bound on the string length for a path name that is to be read in, and reject based on the pathname length, then namei() is probably not the right call to pull in the string in the first place. For many reasons, including that if shared memory is in use, then there's a race condition under SMP that can let malicious processes update the path between the two checks as they are non-atomic. The individual file systems can eaily do this check when the copy in the string. All they have to do is actually check for copyinstr() returning an error, and clean up a bit when it returns an error. Not checking is a bug even if ENAMETOOLONG is treated as a non-error. EFAULT should be treated as an error (but perhaps namei()'s success means that this error can't happen). If there is a race, then it is old and not restricted to SMP (just larger for SMP) -- copyinstr() may block. This shouldn't be a problem for mount(), since mount() requires privilege. What is it you're trying to accomplish here, exactly? Is it prevent paths MNAMELEN to be used as targets of mounting operations? Or is it to truncate strings reported via statfs to some arbitrary bound? If it's the It is to not permit mount() operations whose mount point can't be recorded in the kernel because its name is too long. There is a similar problem for the "from" name. At least the following non-interactive operations now depend on the names being recorded properly: fsck (for hotroot stuff) and `umount -A'. --- vfs_syscalls.c Sun Nov 26 03:30:05 2000 +++ vfs_syscalls.c.new Thu Feb 15 18:22:13 2001 @@ -140,6 +140,8 @@ /* * Get vnode to be covered */ + if (strlen(SCARG(uap, path)) MNAMELEN) ^ should be = for no off-by-1 error + return (ENAMETOOLONG); NDINIT(nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE, SCARG(uap, path), p); if ((error = namei(nd)) != 0) + From: + * $FreeBSD: src/sys/ufs/ffs/ffs_vfsops.c,v 1.138 2001/02/09 06:11:33 bmilekic Exp $ +... + copyinstr(path, mp-mnt_stat.f_mntonname, MNAMELEN - 1, size); off-by-1 + bzero( mp-mnt_stat.f_mntonname + size, MNAMELEN - size); The bzero() gives a second NUL terminator, but this doesn't require extra code because the rest of the array must be zeroed. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 OpenSSL), I don't think the libraries have a significant impact on overall performance. This would be quite doable, but I agree with you in thinking there aren't many people who would make use of it. If the kernel were to become dynamically tunable so e.g. GENERIC would dynamically select between the various CPU-specific asm optimizations, then there'd be more of a justification to making a generic userland self-tuning as well. IMHO, the main market for this feature would be people who just do binary installs - if you're doing a buildworld, you can tune to your hardware[1]. If we wanted to just speed up OpenSSL on binary installs, we could have processor-optimised variants of libssl.* available as packages (tick the box that suits your processor if you want the optimised library). If/when we ever get a packaged base system this would be a good and easy thing to do. We could do it now, but it wouldn't be natural in the sysinstall scheme of things (i.e. you'd have to install the OS, and then select the OpenSSL-i686 package from the listing of packages in the ports tree). Kris PGP signature
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 /var/log/messages: Feb 16 00:52:00 chapel-hill /boot/kernel/kernel: acd1: CD-RW R/RW 4x4x24 at ata1-slave using PIO4 Feb 16 00:53:30 chapel-hill /boot/kernel/kernel: acd1: READ_TOC - ILLEGAL REQUEST asc=24 ascq=00 error=00 Version is current as of 2001/02/07. Any comments welcome. Kent To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 chapel-hill# Trace messages from /var/log/messages: Feb 16 00:52:00 chapel-hill /boot/kernel/kernel: acd1: CD-RW R/RW 4x4x24 at ata1-slave using PIO4 Feb 16 00:53:30 chapel-hill /boot/kernel/kernel: acd1: READ_TOC - ILLEGAL REQUEST asc=24 ascq=00 error=00 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... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 having with my NEC burner? Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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 for it... Is this the same problem I was having with my NEC burner? No, your problem was IIRC that the drive wouldn't accept the setting of the write mode page... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
