Re: world breakage in pam_echo
On Wed, 16 Jul 2003, Christian Brueffer wrote: === lib/libpam/modules/pam_echo cc -O2 -pipe -march=pentium2 -I/usr/src/lib/libpam/modules/pam_echo/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_echo/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c: In function `_pam_echo': /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 I was just about to report this myself. The breakage only occurs with optimization levels of -O2 (and maybe higher). Officially -O2 is not supported for world, but in my experience there are real problems with code (warnings in this case) that do not show up until the optimizer takes a closer look at them. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: world breakage in pam_echo
Wesley Morgan [EMAIL PROTECTED] writes: On Wed, 16 Jul 2003, Christian Brueffer wrote: === lib/libpam/modules/pam_echo cc -O2 -pipe -march=pentium2 -I/usr/src/lib/libpam/modules/pam_echo/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_echo/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c: In function `_pam_echo': /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 I was just about to report this myself. The breakage only occurs with optimization levels of -O2 (and maybe higher). Officially -O2 is not supported for world, but in my experience there are real problems with code (warnings in this case) that do not show up until the optimizer takes a closer look at them. [snip] It's my impression that these warnings mean the C code in question is undefined or implementation-defined according to the C standard, and the generated assembler may have unexpected behavior. I get this impression from reading the description of -fstrict-aliasing (enabled at -O2, -O3, -Os) at: http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Optimize-Options.html#Optimize%20Options (The relevant warning flag is -Wstrict-aliasing, see http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Warning-Options.html#Warning%20Options ) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: world breakage in pam_echo
On Wed, 16 Jul 2003, Christian Brueffer wrote: my world is broken with the following error message for some days now: === lib/libpam/modules/pam_echo cc -O2 -pipe -march=pentium2 -I/usr/src/lib/libpam/modules/pam_echo/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_echo/../../libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c 1. Optimization levels above -O are not supported. 2. -Werror is NOT recommended post-gcc 3.3 upgrade unless you are fixing warnings. gcc3.3 is much more warn-happy. I'm not sure how you got -Werror in there since it was removed prior to the gcc3.3 import. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: World breakage in lib/libc/gen/disklabel.c; here's a patch
Date: Fri, 16 Aug 2002 08:03:06 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] The following patch (from /usr/src) gets past the problem, but I don't know that it's correct: Still don't know about correct, but it was incomplete. Index: lib/libc/gen/disklabel.c After adding these patches to that one, I got world to build. (Building kernel as I type, so I haven't booted the result, let alone tested it.) Index: sbin/disklabel/disklabel.c === RCS file: /cvs/freebsd/src/sbin/disklabel/disklabel.c,v retrieving revision 1.56 diff -u -r1.56 disklabel.c --- sbin/disklabel/disklabel.c 3 Jul 2002 16:43:11 - 1.56 +++ sbin/disklabel/disklabel.c 16 Aug 2002 15:18:40 - @@ -60,6 +60,7 @@ #include sys/file.h #include sys/stat.h #include sys/wait.h +#define FSTYPENAMES #define DKTYPENAMES #include sys/disklabel.h #ifdef __sparc64__ Index: sbin/fsck_ffs/setup.c === RCS file: /cvs/freebsd/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.36 diff -u -r1.36 setup.c --- sbin/fsck_ffs/setup.c 16 Aug 2002 07:34:19 - 1.36 +++ sbin/fsck_ffs/setup.c 16 Aug 2002 15:28:35 - @@ -39,6 +39,7 @@ $FreeBSD: src/sbin/fsck_ffs/setup.c,v 1.36 2002/08/16 07:34:19 alfred Exp $; #endif /* not lint */ +#define FSTYPENAMES #include sys/param.h #include sys/stat.h #include sys/disklabel.h Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World breakage in lib/libc/gen/disklabel.c; here's a patch
* David Wolfskill [EMAIL PROTECTED] [020816 08:52] wrote: Date: Fri, 16 Aug 2002 08:03:06 -0700 (PDT) From: David Wolfskill [EMAIL PROTECTED] The following patch (from /usr/src) gets past the problem, but I don't know that it's correct: Still don't know about correct, but it was incomplete. Index: lib/libc/gen/disklabel.c After adding these patches to that one, I got world to build. (Building kernel as I type, so I haven't booted the result, let alone tested it.) Sorry, I'll have this committed soon. Index: sbin/disklabel/disklabel.c === RCS file: /cvs/freebsd/src/sbin/disklabel/disklabel.c,v retrieving revision 1.56 diff -u -r1.56 disklabel.c --- sbin/disklabel/disklabel.c3 Jul 2002 16:43:11 - 1.56 +++ sbin/disklabel/disklabel.c16 Aug 2002 15:18:40 - @@ -60,6 +60,7 @@ #include sys/file.h #include sys/stat.h #include sys/wait.h +#define FSTYPENAMES #define DKTYPENAMES #include sys/disklabel.h #ifdef __sparc64__ Index: sbin/fsck_ffs/setup.c === RCS file: /cvs/freebsd/src/sbin/fsck_ffs/setup.c,v retrieving revision 1.36 diff -u -r1.36 setup.c --- sbin/fsck_ffs/setup.c 16 Aug 2002 07:34:19 - 1.36 +++ sbin/fsck_ffs/setup.c 16 Aug 2002 15:28:35 - @@ -39,6 +39,7 @@ $FreeBSD: src/sbin/fsck_ffs/setup.c,v 1.36 2002/08/16 07:34:19 alfred Exp $; #endif /* not lint */ +#define FSTYPENAMES #include sys/param.h #include sys/stat.h #include sys/disklabel.h Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill[EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. -- -Alfred Perlstein [[EMAIL PROTECTED]] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: world breakage?
On Mon, 13 Nov 2000 17:24:41 +0100, Andrea Campi wrote: I think it wasn't reported yet? No time to debug it, I am at work ;-) Reported and fixed. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in usr.bin/kdump
On Wed, 02 Aug 2000 09:19:36 -0400, Donn Miller wrote: In file included from ioctl.c:63: /usr/obj/usr/src/i386/usr/include/net/if_ieee80211.h:14: `ETHER_ADDR_LEN' undeclared here (not in a function) I'm pretty sure this was fixed several hours ago. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit-sys_exit change?
Mike Meyer wrote: Ok, I give up. It seems that the world change from exit to sys_exit broke the world build, but I can't figure out where. I've fixed every occurence of SYS_exit in the source tree (this one seems to be src/lib/csu/i386/crt0.c, but there were some in gdb as well), and removed /usr/obj - and I still get the following error from buildworld: I think this might be due to the fact that, for some reason, the build is still using the old syscall.h (the one that references SYS_exit rather than SYS_sys_exit -- ie. the installed one rather than the newly generated one). The funny thing here is I would have expected a make -DCLOBBER to take care of that... Regards, PYD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit-sys_exit change?
Argh! I knew today was going to stay a bad day.
I am pretty sure I know how to fix this and will commit a fix shortly. If you
want to try now, edit sys/kern/syscalls.master:
1 STD NOHIDE { void sys_exit(int rval); } sys_exit sys_exit_args void
---
1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args void
and cd src/sys/kern; make init_sysent.c
Then your world should build ok.
Mike Meyer wrote:
Ok, I give up. It seems that the world change from exit to sys_exit
broke the world build, but I can't figure out where. I've fixed every
occurence of SYS_exit in the source tree (this one seems to be
src/lib/csu/i386/crt0.c, but there were some in gdb as well), and
removed /usr/obj - and I still get the following error from
buildworld:
=== bin/cat
cc -O -pipe -march=pentium -Wall -Wformat -I/usr/obj/usr/src/i386/usr/inclu
de -c /usr/src/bin/cat/cat.c
gzip -cn /usr/src/bin/cat/cat.1 cat.1.gz
cc -O -pipe -march=pentium -Wall -Wformat -I/usr/obj/usr/src/i386/usr/inclu
de -static -o cat cat.o
/usr/obj/usr/src/i386/usr/lib/libc.a(_exit.o): In function `_exit':
_exit.o(.text+0x2): undefined reference to `SYS_exit'
*** Error code 1
1 error
Is this one of those things that is going to require gyrations to get
built?
Thanx,
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit-sys_exit change?
Peter Wemm writes:
Argh! I knew today was going to stay a bad day.
I had similar thoughts about mine, both before I started the build,
and afterwards.
I am pretty sure I know how to fix this and will commit a fix shortly. If you
want to try now, edit sys/kern/syscalls.master:
1 STD NOHIDE { void sys_exit(int rval); } sys_exit sys_exit_args void
---
1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args void
and cd src/sys/kern; make init_sysent.c
Then your world should build ok.
That fix indeed seems to work (it managed to build cat), and looks
saner than mine.
Thanx,
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: World breakage from exit-sys_exit change?
Mike Meyer wrote:
Peter Wemm writes:
Argh! I knew today was going to stay a bad day.
I had similar thoughts about mine, both before I started the build,
and afterwards.
I am pretty sure I know how to fix this and will commit a fix shortly. If
you
want to try now, edit sys/kern/syscalls.master:
1 STD NOHIDE { void sys_exit(int rval); } sys_exit sys_exit_args
void
---
1 STD NOHIDE { void sys_exit(int rval); } exit sys_exit_args voi
d
and cd src/sys/kern; make init_sysent.c
Then your world should build ok.
That fix indeed seems to work (it managed to build cat), and looks
saner than mine.
Anyway, it should be all fixed now (and has been committed for a while).
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: world breakage in -current (also breaks release)
"Jordan" == Jordan K Hubbard [EMAIL PROTECTED] writes: Jordan cd /usr/src; make -f Makefile.inc1 hierarchy Jordan cd /usr/src/etc;make distrib-dirs Jordan mtree -deLU -f /usr/src/etc/mtree/BSD.root.dist -p / Jordan mtree: illegal option -- L Yep, same for me... I succeed in installing mtree _before_ making installworld. -- - Éric Jacoboni « No sport, cigars! » (W. Churchill) - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage in usr.bin/kdump
On Sun, May 07, 2000 at 11:36:45PM -0700, Doug Barton wrote: /usr/include/sys/wormio.h:102: warning: `CDRIOCBLANK' redefined /usr/include/sys/cdrio.h:59: warning: this is the location of the In the old days cd /usr/src ; make -DCLOBBER includes would do what needs to be done. (the CLOBBER ability should not have been ripped out). wormio.h is no longer an active file, so you need to manually delete it from /usr/include. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage in usr.bin/kdump
David O'Brien wrote: On Sun, May 07, 2000 at 11:36:45PM -0700, Doug Barton wrote: /usr/include/sys/wormio.h:102: warning: `CDRIOCBLANK' redefined /usr/include/sys/cdrio.h:59: warning: this is the location of the In the old days cd /usr/src ; make -DCLOBBER includes would do what needs to be done. (the CLOBBER ability should not have been ripped out). wormio.h is no longer an active file, so you need to manually delete it from /usr/include. It should have been deleted by the appropriate makefile before the new headers are installed. Obsoleting header files can create as much backward compatibility problems as obsoleting functions or options can. It should have been dealt with accordingly... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage in usr.bin/kdump
On Mon, 8 May 2000, David O'Brien wrote: On Sun, May 07, 2000 at 11:36:45PM -0700, Doug Barton wrote: /usr/include/sys/wormio.h:102: warning: `CDRIOCBLANK' redefined /usr/include/sys/cdrio.h:59: warning: this is the location of the In the old days cd /usr/src ; make -DCLOBBER includes would do what needs to be done. Cool. I figured it was something like that, but with all the header file stuff going around I guess the other question related to this is, why is the world build using the system's header files? Thanks, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage with NO_OPENSSL
On Wed, 8 Mar 2000, Matthew N. Dodd wrote: usr.sbin/ppp/ usr.sbin/pppd/ secure/libexec/telnetd/ (actually the Makefile below telnetd/ is the problem.) secure/usr.bin/telnet/ These all require simple !defined(NO_OPENSSL) additions. Known problem - see the patch I posted about 2 days ago which I already referred to in an earlier reply to you in this meta-thread. I think it's hit a bug in jordan.pl which means it isn't spitting out automatic commit approval; perhaps I should re-send it. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage?
On Thu, Jan 27, 2000 at 09:39:10AM +0100, Dag-Erling Smorgrav wrote: Sources from ~12 hours ago: === usr.bin/kdump ... In file included from ioctl.c:79: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined Peter Wemm fixed this as src/include/Makefile rev 1.109 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World Breakage in sys/modules/ukbd
Oops, sorry. Apply the attached patch to /sys/modules/ukbd/Makefile.
Kazu
A buildworld done in the last hour with a fresh cvsup fails with the
following:
touch opt_usb.h
echo ukbd.h
echo '#define KBD_INSTALL_CDEV 1' opt_kbd.h
rm -f .depend
mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../
include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/ukbd/../../
dev/usb/ukbd.c
/usr/src/sys/modules/ukbd/../../dev/usb/ukbd.c:46: opt_ukbd.h: No such file or
directory
mkdep: compile failed
*** Error code 1
[...]
Index: Makefile
===
RCS file: /src/CVS/src/sys/modules/ukbd/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile1999/11/28 18:53:31 1.8
+++ Makefile1999/12/13 10:07:14
@@ -5,15 +5,18 @@
.PATH: ${.CURDIR}/../../dev/usb
KMOD= ukbd
SRCS= bus_if.h device_if.h vnode_if.h \
- opt_usb.h ukbd.h opt_kbd.h \
+ opt_usb.h ukbd.h opt_kbd.h opt_ukbd.h \
ukbd.c
NOMAN =
-CLEANFILES = ukbd.h opt_kbd.h
+CLEANFILES = ukbd.h opt_kbd.h opt_ukbd.h
ukbd.h:
echo ukbd.h
opt_kbd.h:
echo '#define KBD_INSTALL_CDEV 1' opt_kbd.h
+
+opt_ukbd.h:
+ echo opt_ukbd.h
.include bsd.kmod.mk
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libpam?
In article [EMAIL PROTECTED], David Scheidt [EMAIL PROTECTED] wrote: Seeing this trying to build world, cvsup'd earlier today. cc -O -pipe -static -DSETPROCTITLE -DSKEY -DLOGIN_CAP -DVIRTUAL_HOSTING -Wall -I/usr/src/libexec/ftpd/../../contrib-crypto/telnet -DINTERNAL_LS -Dmain=ls_main -I/usr/src/libexec/ftpd/../../bin/ls -I/usr/obj/usr/src/tmp/usr/include -o ftpd ftpd.o ftpcmd.o logwtmp.o popen.o skey-stuff.o ls.o cmp.o print.o stat_flags.o util.o -lskey -lmd -lcrypt -lutil -lpam /usr/obj/usr/src/tmp/usr/lib/libpam.a(pam_static_modules.o): In function `_pam_get_static_sym': pam_static_modules.o(.text+0x299): undefined reference to `rad_create_request' pam_static_modules.o(.text+0x2af): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x2cc): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2e9): undefined reference to `rad_put_string' ... I think it's because of the "-static" in the link command. I don't have time to find the fix at the moment, but if you look at src/bin/login you might be able to work it out yourself. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
On a related topic, we should fix the Alpha to emit the weak alias like the i386 does. We should do what ever is reasonably possible to keep these two archs operating the same. IMHO, people will expect their FreeBSD platform knowledge to hold on the Alpha. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
As Daniel Eischen wrote ... Sheer curiosity and most likely a somewhat dim question: what the h* is a weak versus a strong symbol? Thanks, Wilko John Birrell wrote: Weak symbols don't work too well _between_ libraries. If libc is linked before libpthread, any unresolved references when libc is searched will use the weak symbols from there, regardless of the fact that a strong symbol exists in libpthread. If libc is linked after libpthread, then you can have libc internal references to things that should been resolved to things in libpthread, but end up using the weak symbols in libc because that is all there is left. 8-( Not a simple problem to solve. The current tools don't help at all. A second library pass to resolve weak symbols would have been better. It's too late for that now, though, since you can change the semantics on the shared loader. It'd be interesting to know how Solaris does this. I see they don't supply a static libpthread, just the dynamic. It seems they do use a strong symbol in libpthread, and a weak one in libc: vfr [80] $ nm /usr/lib/libc.so.1 | grep pthread_mutex_lock [4394] |596188| 44|FUNC |WEAK |0|12 |_pthread_mutex_lock [2980] |596188| 44|FUNC |WEAK |0|12 |pthread_mutex_lock vfr [81] $ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_lock [333] | 20704| 8|FUNC |GLOB |0|8 |_pthread_mutex_lock [107] | 20704| 8|FUNC |WEAK |0|8 |pthread_mutex_lock -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
On Wed, 13 Oct 1999, John Polstra wrote: I'm building world on an Alpha and have run into this: building shared library libc_r.so.4 sigpending.So: In function `sigpending': sigpending.S:2: multiple definition of `sigpending' uthread_sigpending.So(.text+0x0):uthread_sigpending.c: first defined here /usr/obj/a/src/tmp/usr/libexec/elf/ld: Warning: size of symbol `sigpending' changed from 68 to 36 in sigpending.So uthread_sigsuspend.So: In function `sigsuspend': uthread_sigsuspend.c(.text+0x0): multiple definition of `sigsuspend' sigsuspend.So:sigsuspend.S:2: first defined here /usr/obj/a/src/tmp/usr/libexec/elf/ld: Warning: size of symbol `sigsuspend' changed from 36 to 236 in uthread_sigsuspend.So *** Error code 1 I know the cause of it and I know the fix. The cause is this: --- dfr 1999/10/09 05:11:32 PDT Modified files: lib/libc/alpha/sys Makefile.inc Log: Remove old sig* wrappers. Revision ChangesPath 1.6 +2 -3 src/lib/libc/alpha/sys/Makefile.inc --- and the fix is to add sigpending.o and sigsuspend.o to the definition of HIDDEN_SYSCALLS in "src/lib/libc_r/Makefile". But there was a similar commit for the i386 a few hours later, and I haven't heard any complaints about this breakage on i386 systems. I'm reluctant to commit the fix for the Alpha until I understand why not, because it will affect the i386 too. Can any of you shed some light on this? I'm pretty sure that this is the right fix. My guess as to why it didn't pop up on i386 is that the old and new implementations were sufficiently close in size that rounding up to 16bytes made them look identical. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
Doug Rabson wrote: On Wed, 13 Oct 1999, John Polstra wrote: building shared library libc_r.so.4 sigpending.So: In function `sigpending': sigpending.S:2: multiple definition of `sigpending' uthread_sigpending.So(.text+0x0):uthread_sigpending.c: first defined here /usr/obj/a/src/tmp/usr/libexec/elf/ld: Warning: size of symbol `sigpending' changed from 68 to 36 in sigpending.So uthread_sigsuspend.So: In function `sigsuspend': uthread_sigsuspend.c(.text+0x0): multiple definition of `sigsuspend' sigsuspend.So:sigsuspend.S:2: first defined here /usr/obj/a/src/tmp/usr/libexec/elf/ld: Warning: size of symbol `sigsuspend' changed from 36 to 236 in uthread_sigsuspend.So *** Error code 1 and the fix is to add sigpending.o and sigsuspend.o to the definition of HIDDEN_SYSCALLS in "src/lib/libc_r/Makefile". I'm pretty sure that this is the right fix. My guess as to why it didn't pop up on i386 is that the old and new implementations were sufficiently close in size that rounding up to 16bytes made them look identical. I've just committed this. I'm also pretty sure this is the right fix. I don't know why ld/i386 doesn't complain. It may be a bug, because the difference in size is probably more than 16 bytes. Compare for example sigprocmask, it originally also wasn't added to HIDDEN_SYSCALLS and therefore was also defined twice. I'm very much surprised if both versions end op being the same size... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
As John Polstra wrote ... I'm building world on an Alpha and have run into this: building shared library libc_r.so.4 sigpending.So: In function `sigpending': sigpending.S:2: multiple definition of `sigpending' uthread_sigpending.So(.text+0x0):uthread_sigpending.c: first defined here /usr/obj/a/src/tmp/usr/libexec/elf/ld: Warning: size of symbol `sigpending' changed from 68 to 36 in sigpending.So uthread_sigsuspend.So: In function `sigsuspend': uthread_sigsuspend.c(.text+0x0): multiple definition of `sigsuspend' sigsuspend.So:sigsuspend.S:2: first defined here /usr/obj/a/src/tmp/usr/libexec/elf/ld: Warning: size of symbol `sigsuspend' changed from 36 to 236 in uthread_sigsuspend.So *** Error code 1 You are not alone... I've already been in contact with Marcel (Moolenaar) and he'll fix it. He really wants to, because he can borrow one of my Alpha's as soon as it can build it's own -current ;-) ;-) Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
In article [EMAIL PROTECTED], Marcel Moolenaar [EMAIL PROTECTED] wrote: Doug Rabson wrote: On Wed, 13 Oct 1999, John Polstra wrote: and the fix is to add sigpending.o and sigsuspend.o to the definition of HIDDEN_SYSCALLS in "src/lib/libc_r/Makefile". I'm pretty sure that this is the right fix. My guess as to why it didn't pop up on i386 is that the old and new implementations were sufficiently close in size that rounding up to 16bytes made them look identical. I've just committed this. Thanks. I'm also pretty sure this is the right fix. I don't know why ld/i386 doesn't complain. It may be a bug, because the difference in size is probably more than 16 bytes. Compare for example sigprocmask, it originally also wasn't added to HIDDEN_SYSCALLS and therefore was also defined twice. I'm very much surprised if both versions end op being the same size... I know now why it worked on the i386 but not on the Alpha. On the i386 a system call "read", for example, produces a strong (normal global) symbol "_read" and a weak alias "read". Because the symbols were weak, the linker didn't complain about the multiple definitions. But on the Alpha, only a strong symbol "read" is emitted. So multiple definitions caused a diagnostic there. On a related topic, we should fix the Alpha to emit the weak alias like the i386 does. That's for ANSI/ISO C compliance, so that if a user defines his own version of read(), it won't affect the behavior of, say, getc(). We need a lot more of this throughout the C library for both target platforms. And we need to fix the calls inside there to use the "_xxx" symbols rather than the "xxx" versions. Don't ya just love people who say "we" need to do stuff? :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
On Thu, Oct 14, 1999 at 02:06:40PM -0700, John Polstra wrote: On a related topic, we should fix the Alpha to emit the weak alias like the i386 does. That's for ANSI/ISO C compliance, so that if a user defines his own version of read(), it won't affect the behavior of, say, getc(). We need a lot more of this throughout the C library for both target platforms. And we need to fix the calls inside there to use the "_xxx" symbols rather than the "xxx" versions. When I put the weak symbol stuff in, it did work on the alpha. Must have got lost in the version upgrades. Don't ya just love people who say "we" need to do stuff? :-) "Don't ya just love tools people who say "we" need to do stuff to tools?" 8-) -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
John Polstra wrote: I know now why it worked on the i386 but not on the Alpha. On the i386 a system call "read", for example, produces a strong (normal global) symbol "_read" and a weak alias "read". Because the symbols were weak, the linker didn't complain about the multiple definitions. But on the Alpha, only a strong symbol "read" is emitted. So multiple definitions caused a diagnostic there. On a related topic, we should fix the Alpha to emit the weak alias like the i386 does. That's for ANSI/ISO C compliance, so that if a user defines his own version of read(), it won't affect the behavior of, say, getc(). We need a lot more of this throughout the C library for both target platforms. And we need to fix the calls inside there to use the "_xxx" symbols rather than the "xxx" versions. Don't ya just love people who say "we" need to do stuff? :-) One of the things on my wish list is a libpthread that can be linked with libc. So the way to accomplish this is to have null hooks with weak symbols in libc, and provide the same (non-null) functions in libpthread but with strong symbols? Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
John Polstra wrote: One of the things on my wish list is a libpthread that can be linked with libc. So the way to accomplish this is to have null hooks with weak symbols in libc, and provide the same (non-null) functions in libpthread but with strong symbols? Oh, maybe, but be careful. Weak symbols don't solve very many kinds of problems, but they can sure cause a lot of trouble. I don't have time to work through this case in detail right now. But think about whether a call to read() from inside libc will get the correct version in all cases. Consider both static and dynamic linking too -- they don't behave quite the same. There are lots of potential gotchas. Sorry to be so brief. I can help more with this after FreeBSDCon. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage related to svr4 module
Maxim Sobolev wrote: On the -CURRENT cvsup'ed two hours ago: cc -O2 -pipe -march=pentium -mpentium -DKERNEL -DCOMPAT_SVR4 -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/obj/usr/src/sys/modules/svr4 -I/usr/obj/usr/src/sys/modules/svr4/@ -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/sys/modules/svr4/../../svr4/svr4_signal.c /usr/src/sys/modules/svr4/../../svr4/imgact_svr4.c:233: parse error before `svr4_execsw' Ack, fixed.. (How embarresing... :-) Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 04-Apr-99 David O'Brien wrote: /usr/obj/home/imp/FreeBSD/src/tmp/usr/lib/libc.a(mktemp.o): In function `mkstemps': mktemp.o(.text+0x0): multiple definition of `mkstemps' /usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(mks temp.o)(.text+0x0): first defined here /usr/libexec/elf/ld: Warning: size of symbol `mkstemps' changed from 573 to 39 in mktemp.o I can't duplicate this problem. Just to be sure... you aren't using -DNOCLEAN, -O2 or anything like that, right? I now can =) using a freshly cvsupped repository, cvs checkout of src, and make with a clean obj tree. So -DNOCLEAN isn't the issue, I replace -O2 in the /etc/make.conf with -Os. Funny thing that it bombs now, whereas I made world fine before. === gnu/usr.bin/cc/cc cc -Os -pipe -DFREEBSD_ELF -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE -DDEFAULT_TARGET_VERSION=\egcs-2.91.66\ -DDEFAULT_TARGET_MACHINE=\\ -I/usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools -c /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c In file included from /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c:555: /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools/multilib.h:4: warning: initialization from incompatible pointer type /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c:1178: warning: initialization from incompatible pointer type /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c: In function `print_multilib_info': /work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/gcc.c:5919: warning: assignment from incompatible pointer type cc -Os -pipe -DFREEBSD_ELF -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE -DDEFAULT_TARGET_VERSION=\egcs-2.91.66\ -DDEFAULT_TARGET_MACHINE=\\ -I/usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools -I/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_tools-o cc gcc.o /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(choose-tem p.o): In function `make_temp_file': choose-temp.o(.text+0x278): undefined reference to `mkstemps' *** Error code 1 Stop. Going to look at Warner's patches just in case... --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
In message xfmail.990405175536.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Funny thing that it bombs now, whereas I made world fine before. Looks like you didn't get the other of my two changes. It was to src/gnu/usr.bin/cc/cc_drv/Makefile. Make sure that it doesn't have mkstemp.o listed. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 Warner Losh wrote: In message xfmail.990405175536.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Funny thing that it bombs now, whereas I made world fine before. Looks like you didn't get the other of my two changes. It was to src/gnu/usr.bin/cc/cc_drv/Makefile. Make sure that it doesn't have mkstemp.o listed. Looking at that file now: # $Id: Makefile,v 1.2 1999/04/04 20:29:43 imp Exp $ That seems right... [asmo...@daemon] (13) $ more Makefile | grep mkstemp [asmo...@daemon] (14) $ That's odd... Will nuke /usr/obj again just be sure for 100% on that part, but I think that I oughtta had that problem on my earlier builds as well though... Hmmm... --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
In message xfmail.990405185525.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Will nuke /usr/obj again just be sure for 100% on that part, but I think : that I oughtta had that problem on my earlier builds as well though... Odd. I completed a make world with my changes... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 Warner Losh wrote: In message xfmail.990405185525.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Will nuke /usr/obj again just be sure for 100% on that part, but I think : that I oughtta had that problem on my earlier builds as well though... Odd. I completed a make world with my changes... Oops, said that wrong: I did _not_ have that problem on my earlier build. Anyways I just rm -rf'd the contents of /usr/obj and trying it again with a fresh cvsup. === rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:188 2: Internal compiler error in function main *** Error code 33 Stop. *** Error code 1 *sigh* and it's so easy to find what those error messages mean. Btw, using my previous make world the egcs info files didn't get installed. Seems that the make install target doesn't get called. Need to verify that though. A make make install from the subdir works though as it should. --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 Jeroen Ruigrok/Asmodai wrote: On 05-Apr-99 Warner Losh wrote: In message xfmail.990405185525.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: === rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1 882: Internal compiler error in function main *** Error code 33 Stop. *** Error code 1 Tried to remake the cc stuff first as suggested in a previous mail by John Polstra. However this returns me to the mkstemps problem with a source tree which _is_ accurate though... --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
In message xfmail.990405203100.asmo...@wxs.nl Jeroen Ruigrok/Asmodai writes: : Tried to remake the cc stuff first as suggested in a previous mail by John : Polstra. However this returns me to the mkstemps problem with a source tree : which _is_ accurate though... Can you do an ar: ar tv /usr/obj/mumble/gnu/usr.bin/cc/cc_drv/libcc_drv.a Also make sure that you have version 1.2 of src/gnu/usr.sbin/cc/cc_drv/Makefile. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
=== rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:1 882: Internal compiler error in function main *** Error code 33 This has been fixed. Tried to remake the cc stuff first as suggested in a previous mail by John Polstra. However this returns me to the mkstemps problem with a source tree which _is_ accurate though... Sounds like maybe you should try a different CVSup server. Maybe there is one out there that isn't up to date? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
=== rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:188 2: Internal compiler error in function main *** Error code 33 The fix for this is to CVSup, cd /usr/src/gnu/usr.bin/cc do a build and install from there. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 Warner Losh wrote:
In message xfmail.990405203100.asmo...@wxs.nl Jeroen Ruigrok/Asmodai
writes:
: Tried to remake the cc stuff first as suggested in a previous mail by
: John Polstra. However this returns me to the mkstemps problem with a
: source tree which _is_ accurate though...
Can you do an ar:
ar tv /usr/obj/mumble/gnu/usr.bin/cc/cc_drv/libcc_drv.a
[r...@daemon] (9) # ar tv libcc_drv.a
rw-r--r-- 0/0920 Apr 5 20:09 1999 version.o
rw-r--r-- 0/0 2035 Apr 5 20:09 1999 pexecute.o
rw-r--r-- 0/0 1889 Apr 5 20:09 1999 prefix.o
rw-r--r-- 0/0 2313 Apr 5 20:09 1999 obstack.o
rw-r--r-- 0/0 2545 Apr 5 20:09 1999 choose-temp.o
Also make sure that you have version 1.2 of
src/gnu/usr.sbin/cc/cc_drv/Makefile.
[r...@daemon] (19) # more Makefile
#
# $Id: Makefile,v 1.2 1999/04/04 20:29:43 imp Exp $
#
.include ../Makefile.inc
.PATH: ../cc_tools ${GCCDIR}
SRCS= multilib.h choose-temp.c obstack.c prefix.c pexecute.c version.c
CFLAGS+=-DPREFIX=\/usr\
CFLAGS+=-DIN_GCC
LIB=cc_drv
NOPROFILE= YES
NOPIC= YES
install:
@true
${OUT_OBJ}.o ${OUT_OBJ}.so: ${OUT_FILE}
.include bsd.lib.mk
Before I tried the make world again with the latest stuff from cvsup I
nuked /usr/obj to obilivion just to be sure...
---
Jeroen Ruigrok van der Werven http://www.freebsdzine.org
asmodai(at)wxs.nlThe idea does not replace the work...
Network/Security Specialist http://home.wxs.nl/~asmodai
*BSD: Powered by Knowledge Know-how http://www.freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 David O'Brien wrote: === rpcsvc rpcgen -C -h -DWANT_NFS3 /work/FreeBSD/src/include/rpcsvc/klm_prot.x -o klm_prot.h /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp. c:1882: Internal compiler error in function main *** Error code 33 This has been fixed. I thought so as well. Tried to remake the cc stuff first as suggested in a previous mail by John Polstra. However this returns me to the mkstemps problem with a source tree which _is_ accurate though... Sounds like maybe you should try a different CVSup server. Maybe there is one out there that isn't up to date? cvsup.nl.freebsd.org is one of the better, tracks changes very fast. Anyways, see my mail to Warner in which he asks about an ar and the Makefile revision. Just tried a cvsup again and nothing else came from it. I got all the cvs changes which were mailed to cvs-all, including the Makefile 1.2 from cc_drv. I also nuked /usr/obj, so where else can it get _any_ reference to mkstemps from? --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
Also make sure that you have version 1.2 of src/gnu/usr.sbin/cc/cc_drv/Makefile. You might also need to build libc manually. Looks like maybe you are building parts of the tree manually (to fix the cpp problem), and src/gnu/usr.sbin/cc/cc_drv/Makefile changed between your various compiles. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 David O'Brien wrote: Also make sure that you have version 1.2 of src/gnu/usr.sbin/cc/cc_drv/Makefile. You might also need to build libc manually. Looks like maybe you are building parts of the tree manually (to fix the cpp problem), and src/gnu/usr.sbin/cc/cc_drv/Makefile changed between your various compiles. [r...@daemon] (2) # pwd /usr/src/lib/libc [r...@daemon] (3) # make rpcgen -C -h -o yp.h /usr/include/rpcsvc/yp.x /work/FreeBSD/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c:188 2: Internal compiler error in function main *** Error code 33 Uggh, ok. Let's try egcs first again: /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(choose-tem p.o): In function `make_temp_file': choose-temp.o(.text+0x278): undefined reference to `mkstemps' *** Error code 1 Nice case of chicken egg =) Will try yer suggestion from the reply to John D. Polstra about adding mkstemp.c to the SRCS: just to get egcs working again. Will let ye know how I'd fare... Thanks for yer patience thus far =) --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
Uggh, ok. Let's try egcs first again: /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(choose-tem p.o): In function `make_temp_file': choose-temp.o(.text+0x278): undefined reference to `mkstemps' *** Error code 1 Nice case of chicken egg =) Will try yer suggestion from the reply to John D. Polstra about adding mkstemp.c to the SRCS: just to get egcs working again. You really need to do ``cd /usr/src/lib/libc'' and make from there. But I think you will have another chickenegg problem. The mkstemp.c in SRCS should over come is one. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
On 05-Apr-99 David O'Brien wrote: Uggh, ok. Let's try egcs first again: /usr/obj/work/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(choose- tem p.o): In function `make_temp_file': choose-temp.o(.text+0x278): undefined reference to `mkstemps' *** Error code 1 Nice case of chicken egg =) Will try yer suggestion from the reply to John D. Polstra about adding mkstemp.c to the SRCS: just to get egcs working again. You really need to do ``cd /usr/src/lib/libc'' and make from there. But I think you will have another chickenegg problem. The mkstemp.c in SRCS should over come is one. That's what my error 33 before the egcs was about. So I am _forced_ to use the temporary hack, else I cannot compile either egcs nor libc =( Ah well, at least I gained some more insight into the whole makefile system, will make excellent documention for the PDP. And hurray, it worked! =) David, when we ever meet, mayhaps in one of the coming Dutch FreeBSD cons, remember to buy ye a few drinks =) --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
/usr/obj/home/imp/FreeBSD/src/tmp/usr/lib/libc.a(mktemp.o): In function `mkstemps': mktemp.o(.text+0x0): multiple definition of `mkstemps' /usr/obj/home/imp/FreeBSD/src/gnu/usr.bin/cc/cc/../cc_drv/libcc_drv.a(mkstemp.o)(.text+0x0): first defined here /usr/libexec/elf/ld: Warning: size of symbol `mkstemps' changed from 573 to 39 in mktemp.o I can't duplicate this problem. Just to be sure... you aren't using -DNOCLEAN, -O2 or anything like that, right? Would it be possible for you to take the March 31st CURRENT snapshot, do a fresh CVSup/cvs checkout and try a build? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: World Breakage?
In message 19990404132114.c77...@nuxi.com David O'Brien writes:
: I can't duplicate this problem. Just to be sure... you aren't using
: -DNOCLEAN, -O2 or anything like that, right?
:
: Would it be possible for you to take the March 31st CURRENT snapshot, do
: a fresh CVSup/cvs checkout and try a build?
I already have mkstemps in my tree. I had imported it from OpenBSD a
while ago, but hadn't committed it. I'll do that now, as well as
remove the mktemp.c from the offending makefile. It works w/o it and
eliminates an XXX comment.
So you shouldn't be able to reproduce this in a clean tree. :-)
Warner
P.S. here's what I have in my tree that I'll commit soon.
Index: mktemp.c
===
RCS file: /home/imp/FreeBSD/CVS/src/lib/libc/stdio/mktemp.c,v
retrieving revision 1.12
diff -d -u -r1.12 mktemp.c
--- mktemp.c1998/10/20 15:33:21 1.12
+++ mktemp.c1999/04/04 19:31:50
@@ -50,29 +50,39 @@
char *_mktemp __P((char *));
-static int _gettemp __P((char *, int *, int));
+static int _gettemp __P((char *, int *, int, int));
int
+mkstemps(path, slen)
+ char *path;
+ int slen;
+{
+ int fd;
+
+ return (_gettemp(path, fd, 0, slen) ? fd : -1);
+}
+
+int
mkstemp(path)
char *path;
{
int fd;
- return (_gettemp(path, fd, 0) ? fd : -1);
+ return (_gettemp(path, fd, 0, 0) ? fd : -1);
}
char *
mkdtemp(path)
char *path;
{
- return(_gettemp(path, (int *)NULL, 1) ? path : (char *)NULL);
+ return(_gettemp(path, (int *)NULL, 1, 0) ? path : (char *)NULL);
}
char *
_mktemp(path)
char *path;
{
- return(_gettemp(path, (int *)NULL, 0) ? path : (char *)NULL);
+ return(_gettemp(path, (int *)NULL, 0, 0) ? path : (char *)NULL);
}
#ifdef UNSAFE_WARN
@@ -88,12 +98,13 @@
}
static int
-_gettemp(path, doopen, domkdir)
+_gettemp(path, doopen, domkdir, slen)
char *path;
register int *doopen;
int domkdir;
+ int slen;
{
- register char *start, *trv;
+ register char *start, *trv, *suffp;
struct stat sbuf;
int pid, rval;
@@ -105,7 +116,13 @@
pid = getpid();
for (trv = path; *trv; ++trv)
;
+ trv -= slen;
+ suffp = trv;
--trv;
+ if (trv path) {
+ errno = EINVAL;
+ return (0);
+ }
while (*trv == 'X' pid != 0) {
*trv-- = (pid % 10) + '0';
pid /= 10;
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
