make release broken in telnetd
Hi Ruslan, On the 26th you made changes to the Makefiles with this log message: ## Do not build (and install) both secure/ and standard versions of libtelnet, telnetd, and telnet. This only worked because secure/ was listed late in SUBDIR in Makefile.inc1. ## Did you check that "make release" still works with it? Here a "make release" bombs out with: ### cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DA UTHENTICATION -DENCRYPTION -I/usr/src/secure/libexec/telnetd/../../../crypto/te lnet -DINET6 -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/ libexec/telnetd/../../../crypto/telnet/telnetd/utility.c cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DA UTHENTICATION -DENCRYPTION -I/usr/src/secure/libexec/telnetd/../../../crypto/te lnet -DINET6 -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/ libexec/telnetd/../../../crypto/telnet/telnetd/authenc.c gzip -cn /usr/src/secure/libexec/telnetd/../../../crypto/telnet/telnetd/telnetd. 8 telnetd.8.gz cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DA UTHENTICATION -DENCRYPTION -I/usr/src/secure/libexec/telnetd/../../../crypto/te lnet -DINET6 -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -o telnetd global. o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -lte rmcap -ltelnet -lcrypto -lcrypt -lmp state.o: In function `willoption': state.o(.text+0x695): undefined reference to `auth_request' state.o(.text+0x69d): undefined reference to `encrypt_send_support' state.o(.text+0x705): undefined reference to `auth_request' state.o(.text+0x70d): undefined reference to `encrypt_send_support' state.o: In function `wontoption': state.o(.text+0x88c): undefined reference to `auth_finished' state.o(.text+0x926): undefined reference to `auth_finished' state.o: In function `suboption': state.o(.text+0x13e7): undefined reference to `auth_is' state.o(.text+0x1403): undefined reference to `auth_name' state.o(.text+0x144b): undefined reference to `encrypt_support' state.o(.text+0x1467): undefined reference to `encrypt_is' state.o(.text+0x1483): undefined reference to `encrypt_reply' state.o(.text+0x149f): undefined reference to `encrypt_start' state.o(.text+0x14a9): undefined reference to `encrypt_end' state.o(.text+0x14c3): undefined reference to `encrypt_request_start' state.o(.text+0x14cd): undefined reference to `encrypt_request_end' state.o(.text+0x14e7): undefined reference to `encrypt_enc_keyid' ... *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 Stop in /usr/src/release. It is because the libtelnet it is trying to link to, does not have the crypto stuff. It happens during the "make world" part of the release, because /tmp/.world_done does not exist yet. A normal "make world", ie. outside of the "make release" environment works fine though. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fsck pass sanitizing patch
I have put up a patch which sanitizes the fsck passno handling, you will find it at http://phk.freebsd.dk/patch/ Apologies to Kirk if this conflics with any of his work on delayed fsck... 20010328fsck.patch This patch sanitizes the way fsck deals with pass numbers. Consider this /etc/fstab: # Device Mountpoint FStype OptionsDumpPass# /dev/ad1s1b noneswapsw 0 0 /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1e /home ufs rw 2 2 /dev/ad1s1e /tmpufs rw 2 2 /dev/ad1s1f /usrufs rw 2 2 /dev/ccd0c /syvufs rw 2 11 proc /proc procfs rw 0 0 ccd0c is striped over /dev/ad0f and /dev/ad1g Without this pass, fsck in preen mode will check ad0s1a first, and then issue three processes in parallel: One process doing ad0s1e One process doing ad1s1e and ad1s1f One process doing ccd0c There is no way to tell it that ccd0c overlaps ad0 and ad1. With the patch, it will do it this way: pass 2: One process doing ad0s1e One process doing ad1s1e and ad1s1f and when they are complete: pass 11: One process doing ccd0c This is much faster and more sane. I retired the '-l' option which tried to allow people to do something like this, but which didn't work and which complicated the code an awful lot. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release broken in telnetd
Hi!
I don't see how my changes to non-secure Makefiles might affect this.
What I did is disabled building of non-secure, standard libtelnet,
telnet and telnetd if we are also building the secure versions.
I did not touch the secure/ versions in this commit. Moreover, the
standard versions are still built for ``make release'' (RELEASEDIR).
The problem is certainly elsewhere.
[2 minutes of thinking]
Doh, now I see what happened. It is another commit that broke this.
Commit to secure/ Makefiles. Here is part of my original posting to
Mark Murray on secure/ build fixes regarding secure/Makefile.inc:
: TELNETOBJDIR is gone. `buildworld' already installs libtelnet.a
: in ${WORLDTMP}/usr/lib, and we have LIBRARY_PATH pointing there.
: Doh, this change uncovered another bug: in the standard build
: environment, we built both secure/ and standard versions of
: libtelnet, telnetd and telnet; and standard libtelnet.a was
: clobbering secure/ libtelnet.a in ${WORLDTMP}/usr/lib at the
^
: `libraries' stage of `buildworld'.
I have fixed this for normal buildworld/installworld case -- we
do not build and install both secure and non-secure versions of
*telnet*, but the problem still persists for `make release' case
because in we forcibly build and install secure and non-secure
versions, and non-secure libtelnet.a clobbers secure version in
${WORLDTMP}/usr/lib.
The fix is easy -- make libtelnet an "internal static library",
as was discussed with Mark Murray recently, and I have actually
done the first prerequisite step in this direction -- fixed the
net/tn3270 port that depended on this library.
I will commit the changes soon, and will let you know. Actually,
this brokeness is a good argument in favor of this change! :-)
On Wed, Mar 28, 2001 at 10:42:10AM +0200, John Hay wrote:
Hi Ruslan,
On the 26th you made changes to the Makefiles with this log message:
##
Do not build (and install) both secure/ and standard versions
of libtelnet, telnetd, and telnet. This only worked because
secure/ was listed late in SUBDIR in Makefile.inc1.
##
Did you check that "make release" still works with it? Here a "make
release" bombs out with:
###
cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DA
UTHENTICATION -DENCRYPTION -I/usr/src/secure/libexec/telnetd/../../../crypto/te
lnet -DINET6 -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/
libexec/telnetd/../../../crypto/telnet/telnetd/utility.c
cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DA
UTHENTICATION -DENCRYPTION -I/usr/src/secure/libexec/telnetd/../../../crypto/te
lnet -DINET6 -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/
libexec/telnetd/../../../crypto/telnet/telnetd/authenc.c
gzip -cn /usr/src/secure/libexec/telnetd/../../../crypto/telnet/telnetd/telnetd.
8 telnetd.8.gz
cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DA
UTHENTICATION -DENCRYPTION -I/usr/src/secure/libexec/telnetd/../../../crypto/te
lnet -DINET6 -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -o telnetd global.
o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -lte
rmcap -ltelnet -lcrypto -lcrypt -lmp
state.o: In function `willoption':
state.o(.text+0x695): undefined reference to `auth_request'
state.o(.text+0x69d): undefined reference to `encrypt_send_support'
state.o(.text+0x705): undefined reference to `auth_request'
state.o(.text+0x70d): undefined reference to `encrypt_send_support'
state.o: In function `wontoption':
state.o(.text+0x88c): undefined reference to `auth_finished'
state.o(.text+0x926): undefined reference to `auth_finished'
state.o: In function `suboption':
state.o(.text+0x13e7): undefined reference to `auth_is'
state.o(.text+0x1403): undefined reference to `auth_name'
state.o(.text+0x144b): undefined reference to `encrypt_support'
state.o(.text+0x1467): undefined reference to `encrypt_is'
state.o(.text+0x1483): undefined reference to `encrypt_reply'
state.o(.text+0x149f): undefined reference to `encrypt_start'
state.o(.text+0x14a9): undefined reference to `encrypt_end'
state.o(.text+0x14c3): undefined reference to `encrypt_request_start'
state.o(.text+0x14cd): undefined reference to `encrypt_request_end'
state.o(.text+0x14e7): undefined reference to `encrypt_enc_keyid'
...
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
Stop in /usr/src/release.
It is because the libtelnet it is trying to link to, does not have the
crypto stuff. It happens during the "make world" part of the release,
because /tmp/.world_done does not exist yet. A normal "make world",
ie. outside of the "make
Re: ACL support in 5.0-CURRENT (was: cvs commit: src/sys/conf files options src/sys/ufs/ufs acl.h ufs_acl.c ufs_vnops.c (fwd))
On Tue, Mar 27, 2001 at 02:14:38PM -0500, Robert Watson wrote: After the EA backing files are initialized, you can manually start the EA's on the file system, or if UFS_EXTATTR_AUTOSTART is enabled, simply remount the file systems, or reboot the system. To manually start and enable the attributes for the root file system, do the following: extattrctl start / extattrctl enable / posix1e.acl_access /.attribute/system/posix1e.acl_access extattrctl enable / posix1e.acl_default /.attribute/system/posix1e.acl_default When I did this several days ago, I had to actually issue: extattrctl enable / system posix1e.acl_access /.attribute/system/posix1e.acl_access extattrctl enable / system posix1e.acl_default /.attribute/system/posix1e.acl_default ^^ Note namespace argument. Your directions in RAEDME probably got out of sync with `extattrctl' implementaion which now requires attrnamesspace argument. Manpage is accurate though. -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 12 weeks in the brand new millenium... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fun way to panic -current
Run the 4.3 mountd on it. Boom! Kernel memory allocation way to large; unrecoverable! Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HEADS UP: I'm breaking the kernel again
On 28-Mar-01 John Baldwin wrote: On 28-Mar-01 John Baldwin wrote: That's right, more SMPng breakage is on the way. Well, hopefully not bad breakage. On a more serious note, I've just spammed sys/alpha/alpha with parts of the critical_enter/exit change which I meant to commit anyways, so I'm going to go ahead and finish committing that right now. The kernel probably won't compile until it is all checked in. Once I get this in I will hopefully also get a chance to check in the new witness code tonight (or tomorrow morning as the case may be) as well. Well, it should compile and run now. I have more changes that I hope to commit now, but I'll try not to break the kernel compile while I'm doing them. s/now/later this evening (or morning)/ -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use 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: fsck pass sanitizing patch
On Wed, 28 Mar 2001, Poul-Henning Kamp wrote: There is no way to tell it that ccd0c overlaps ad0 and ad1. With the patch, it will do it this way: pass 2: One process doing ad0s1e One process doing ad1s1e and ad1s1f and when they are complete: pass 11: One process doing ccd0c I've always assigned a ccd (this would apply to Vinum volumes as well, I'd think) a pass number of 1. According to the fsck manual page, each filesystem with a pass number of 1 is processed by itself. The code might say something different (which I've looked at but can't quite figure out how that is handled). If assigning a pass number of 1 doesn't do that, we probably should either fix the code so it does, or change the manual pages to match. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fsck pass sanitizing patch
In message [EMAIL PROTECTED], Chr is Dillon writes: On Wed, 28 Mar 2001, Poul-Henning Kamp wrote: There is no way to tell it that ccd0c overlaps ad0 and ad1. With the patch, it will do it this way: pass 2: One process doing ad0s1e One process doing ad1s1e and ad1s1f and when they are complete: pass 11: One process doing ccd0c I've always assigned a ccd (this would apply to Vinum volumes as well, I'd think) a pass number of 1. Pass number 1 in magic in that it is sequential. Traditional wisdom (or lack thereoff) have only put rootfs in pass 1. Until my patch, pass 1 would certainly be better for ccd than pass 1. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
chmod 666 /dev/null
I just rebooted my machine with the cvupped-and-compiled world and kernel, I logged on and did the following: (stephanb@enigma|ttyp4)~ w w: /dev/null: Permission denied Checking out /dev/null gave me this: crw--- 1 root wheel2, 2 Mar 28 20:00 /dev/null I had to chmod it to 666 again in order for me as non-root to do a 'w' ... my question. Why this behaviour ? I've been running FreeBSD for years, but this puzzles me -Stephan -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 "To err is human, to forgive is Not Company Policy" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: chmod 666 /dev/null
Ouch .. ok this was meant to go to -stable. I don't know what made me sent this to -current.. damn. I'll cc this reply to -stable. My apologies. Anyway, I forgot to mention some into.. I do not have DEVFS in my kernel and this is my kernel: FreeBSD enigma.whacky.net 4.3-RC FreeBSD 4.3-RC #0: Wed Mar 28 10:40:13 CEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENIGMA i386 On Wed, 28 Mar 2001, Stephan van Beerschoten wrote: I just rebooted my machine with the cvupped-and-compiled world and kernel, I logged on and did the following: (stephanb@enigma|ttyp4)~ w w: /dev/null: Permission denied Checking out /dev/null gave me this: crw--- 1 root wheel2, 2 Mar 28 20:00 /dev/null I had to chmod it to 666 again in order for me as non-root to do a 'w' ... my question. Why this behaviour ? I've been running FreeBSD for years, but this puzzles me -Stephan -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 "To err is human, to forgive is Not Company Policy" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Stephan van Beerschoten [SVB21-RIPE] [EMAIL PROTECTED] PGP fingerprint: 4557 9761 B212 FB4C 778D 3529 C42A 2D27 "To err is human, to forgive is Not Company Policy" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: chmod 666 /dev/null
Stephan van Beerschoten wrote: I just rebooted my machine with the cvupped-and-compiled world and kernel, I logged on and did the following: (stephanb@enigma|ttyp4)~ w w: /dev/null: Permission denied Checking out /dev/null gave me this: crw--- 1 root wheel2, 2 Mar 28 20:00 /dev/null I had to chmod it to 666 again in order for me as non-root to do a 'w' ... my question. Why this behaviour ? I've been running FreeBSD for years, but this puzzles me I've also saw this once, but still wonder what the reason was. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
Peter Wemm([EMAIL PROTECTED])@2001.03.28/06:24:34(epoch+985757074s): FYI: SYNOPSIS portmap [-d] [-v] SYNOPSIS rpcbind [-dilLs] yup, so i think it makes sense, to have the daemon called rpcbind, since it would probably break other people's configuration after making world. /k -- die rechtschreibreform macht spas! KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD broken in -current
On Wed, Mar 28, 2001 at 10:09:28PM +0200, Jesper Skriver wrote: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/../include -I/usr/src/sys/contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/dev/pccbb/pccbb.c In file included from /usr/src/sys/dev/pccbb/pccbb.c:56: /usr/src/sys/sys/mutex.h:87: field `mtx_object' has incomplete type /usr/src/sys/dev/pccbb/pccbb.c: In function `pccbb_detach': /usr/src/sys/dev/pccbb/pccbb.c:533: warning: implicit declaration of function `MPASS' /usr/src/sys/dev/pccbb/pccbb.c:533: warning: implicit declaration of function `LOCK_LOG_LOCK' /usr/src/sys/dev/pccbb/pccbb.c:533: warning: implicit declaration of function `WITNESS_LOCK' /usr/src/sys/dev/pccbb/pccbb.c:539: warning: implicit declaration of function `WITNESS_UNLOCK' *** Error code 1 You'll need to #include sys/types.h and sys/lock.h in /usr/src/sys/dev/pccbb/pccbb.c /Jesper /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, Tele Danmark NET, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD broken in -current
On Wed, Mar 28, 2001 at 10:15:21PM +0200, Niels Chr. Bank-Pedersen wrote: On Wed, Mar 28, 2001 at 10:09:28PM +0200, Jesper Skriver wrote: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/../include -I/usr/src/sys/contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/dev/pccbb/pccbb.c In file included from /usr/src/sys/dev/pccbb/pccbb.c:56: /usr/src/sys/sys/mutex.h:87: field `mtx_object' has incomplete type /usr/src/sys/dev/pccbb/pccbb.c: In function `pccbb_detach': /usr/src/sys/dev/pccbb/pccbb.c:533: warning: implicit declaration of function `MPASS' /usr/src/sys/dev/pccbb/pccbb.c:533: warning: implicit declaration of function `LOCK_LOG_LOCK' /usr/src/sys/dev/pccbb/pccbb.c:533: warning: implicit declaration of function `WITNESS_LOCK' /usr/src/sys/dev/pccbb/pccbb.c:539: warning: implicit declaration of function `WITNESS_UNLOCK' *** Error code 1 You'll need to #include sys/types.h and sys/lock.h in /usr/src/sys/dev/pccbb/pccbb.c Right, the below fixes it, should I commit ? Index: src/sys/dev/pccbb/pccbb.c === RCS file: /home/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.12 diff -u -r1.12 pccbb.c --- src/sys/dev/pccbb/pccbb.c 2001/02/09 06:08:52 1.12 +++ src/sys/dev/pccbb/pccbb.c 2001/03/28 20:51:20 @@ -53,6 +53,8 @@ #include sys/kernel.h #include sys/kthread.h #include sys/malloc.h +#include sys/types.h +#include sys/lock.h #include sys/mutex.h #include sys/bus.h /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
I do not. -v could easily be added to what is now rpcbind (even if it
was ignored). -d mean the same thing for both. there's then no reason
to change its name.
Well, my feeling on the matter, since everyone gets to have an opinion
today, is that we should stick with rpcbind: it's what everyone else who
uses TIRPC calls it (as well as the entire source code tree). Given that
it's not going to be MFC'd to RELENG_4, and everything in the universe is
changing in -CURRENT, this minor change to improve our compliance with
${THERESTOFTHEWORLD} isn't a big problem. However, for consistency, it
probably is the case that someone should go slap s/portmap/rpcbind/
s/PORTMAP/RPCBIND/ strategically through /etc and associated man pages.
Maybe adding a compatibility check that maps PORTMAP into RPCBIND, and
then prints a message on boot in the style of nsswitch.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Building aout ports in -current
I've been notified that one of the ports I'm responsible for, xswallow, will no longer build under -current. Here's a snip from the build log: === Building for xswallow-1.0.18 cd /tmp/a/ports/www/xswallow/work/xswallow/xswallow cc -O -pipe -o xswallow.so -aout -shared -nostdlib -DXP_UNIX -I../include -I/usr/X11R6/include -L/usr/lib/compat/aout -lgcc UnixShell.c stubs.c as: could not exec aout/as in /usr/libexec: No such file or directory UnixShell.c: In function `readEntries2': UnixShell.c:498: output pipe has been closed cpp0: output pipe has been closed as: could not exec aout/as in /usr/libexec: No such file or directory stubs.c:15: output pipe has been closed *** Error code 1 Stop in /a/ports/www/xswallow. *** Error code 1 Is it no longer possible to build aout binaries in -current, or am I simply using the wrong approach here? Admittedly, I did employ a rather "ad hoc" method to get this package to compile, and up until now it's worked just fine. Any info that might help will be greatly appreciated. -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Building aout ports in -current
On Wed, Mar 28, 2001 at 10:20:33PM -0600, Conrad Sabatier wrote: I've been notified that one of the ports I'm responsible for, xswallow, will no longer build under -current. Here's a snip from the build log: a.out support is entirely optional thesedays for ports, so it's up to you whether or not you care about fixing your port to build that way. Kris PGP signature
Re: Building aout ports in -current
On 29-Mar-2001 Kris Kennaway wrote: On Wed, Mar 28, 2001 at 10:20:33PM -0600, Conrad Sabatier wrote: I've been notified that one of the ports I'm responsible for, xswallow, will no longer build under -current. Here's a snip from the build log: a.out support is entirely optional these days for ports, so it's up to you whether or not you care about fixing your port to build that way. Well, this is a plugin for Netscape, and (unless I'm mistaken) *must* be in aout format, or will ELF plugins work with Netscape??? -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
