Re: DP2 (I think!) crash booting from floppies
Hi, On Fri, Nov 22, 2002 at 02:30:34PM -, local.freebsd.current wrote: > All goes well until I get "Extracting base into / directory" then > "Write failure on transfer. Wrote -1 bytes of 240640" and at the > bottom of the screen "/mnt: write failed, filesystem is full". I had exactly the same problems with 4.x recently; and it turned out that the problem was caused by a bad floppy. dd hat written all the data without reporting errors, but when I tried to boot from the floppy... b00m. Try to read the floppy back on the system where you created it, i.e. dd if=/dev/fd0 of=verify.dat and then compare the md5 checksums of the original .flp file and this file. If they do not match or if dd aborts with an error message, you know where your problems are coming from. /s/Udo -- "The only reasonable alternative we can come up with is to close off the Internet to America Online users until they have passed an entrance test. But that would break federal laws that prohibit discrimination against the intellectually challenged." - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world failure...
On Sun, Feb 11, 2001 at 10:56:18PM +0100, Robert Drehmel wrote: > In <38689.981926085@critter>, Poul-Henning Kamp wrote: > > [buildworld failure lib/libc/locale/lmessages.c] > > It should work with '#include '. Yep, that seems to be enough to get past this point. I don't know if there are any other surprises, my buildworld is still running. /s/Udo -- There's more than one way to skin a cat: Way number 15 -- Krazy Glue and a toothbrush. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Looking for old snapshots
Hi, I tried to install a snapshot of -current on my "new" test box. The hardware used for the box should be OK, I've managed to boot it with a recent snapshot of RELENG_4. -current is another matter. I've tried to install 20010131 and 20001204 and both die with a "Fatal Trap 18: integer divide fault while in kernel mode". The last words are: sio4: probe failed test(s): 0 2 4 6 9 unknown: failed to probe at port 0x10-0x1f on isa0 adv1: Invalid baseport of 0x20 specified. Nearest valid baseport is 0x100. Failing probe. Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x8:0xc01e1c64 stack pointer = 0x10:0xc07d5704 frame pointer = 0x10:0xc07d570c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 0 (swapper) trap number = 18 panic: integer divide fault Uptime: 0s Any further analysis seems impossible: The kernel on the install floppy doesn't contain any symbols :-( The box is a P-60 (complete with the floating point bug) on a really old Intel mainboard (82433LX chipset?). The box has 32 MByte RAM, an Adaptec 2940 AU and an Oak Technologies ISA VGA Card. Right now, I'm looking for old (Sep/Oct/Nov 2000) snapshots of -current to find a version that works on this box. Thanks in advance /s/Udo -- Murphy was an optimist To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sbin/ccdconfig ccdconfig.c
> 1.17 +5 -5 src/sbin/ccdconfig/ccdconfig.c
Broke world:
===> sbin/ccdconfig
rm -f .depend
mkdep -f .depend -a-I/usr/src/sbin/ccdconfig/../../sys -I/usr/obj/usr/src/i3
86/usr/include /usr/src/sbin/ccdconfig/ccdconfig.c
/usr/src/sbin/ccdconfig/ccdconfig.c:725: unterminated string or character consta
nt
/usr/src/sbin/ccdconfig/ccdconfig.c:635: possible real start of unterminated con
stant
mkdep: compile failed
Fix:
Index: ccdconfig.c
===
RCS file: /home/ncvs/src/sbin/ccdconfig/ccdconfig.c,v
retrieving revision 1.17
diff -r1.17 ccdconfig.c
635c635
< warnx("%s', kvm_geterr(kd));
---
> warnx("%s", kvm_geterr(kd));
/s/Udo
--
"What part of no don't you understand?"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS UP** if you used to cvsup the crypto repo from internat !
On Fri, Jul 14, 2000 at 01:56:31PM +0200, Sheldon Hearn wrote: > Also, he clarified the last sentence for me, by saying that it's the > crypto ,v files that need to be removed and not the checked out crypto > files. What about the non-US cvsup mirrors? Most of them used cvsup to mirror the crypto distributions from internat. Does this mean that these mirrors have to nuke theier local copies (of the crypto files), too? That would be a major problem for all users of these mirrors. They would have to wait until "their" mirror fixed it's copy... Is it possible to check if a repository is affected? Something along the lines of "/home/ncvs/src/crypto/foo.c should have revision bar, last commit by ... on ..., the md5 should be ..." /s/Udo -- "People who claim Windows in superior to Unix are the same people who'd argue that you better use your hand instead of toilet paper to wipe your ass. I can hear them now - 'It's colourful and it's intuitive and easy to use and even a child could do it.'". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in sbdrop(), propably not ppp-related
On Wed, Jul 12, 2000 at 02:50:45PM +0100, Brian Somers wrote: > I'd like to disclaim all responsibility :-I I'm almost convinced you're innocent. I've managed to restabilize my system by replacing "set device PPPoE:ed1" with "set device /dev/cuaa2". I've been pumping data through ppp for about 10 hours now and everything is perfect. And yes, the sbdrop panic also happens if /etc/malloc.conf is a symbolic link to aj. /s/Udo -- He who findeth sensuous pleasures in the bodies of lush, hot, pink damsels is not righteous, but he can have a lot more fun. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp-related panic in sbdrop()
Hi,
I've finally managed to capture a crashdump after a panic in sbdrop(). The
machine in question uses ppp/ipfw/natd to connect a small LAN to the
outside world via a DSL link. ppp started to misbehave: NS queries were
sent out but didn't come back (I had tcpdumps running on both tun0 and
ed1). I tried to terminate ppp by sending a SIGTERM. ppp (pid 78) was
still around after a minute, so I send a SIGTERM. The machine crashed
immediately.
The machine world as of 7/7, I've only added the latest type fix to
ppp/bundle.c (rev 1.99).
The point of doom:
bash# gdb -k /sys/compile/UE/kernel.debug /var/crash/vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 3952640
initial pcb at 325320
panicstr: sbdrop
panic messages:
---
panic: sbdrop
syncing disks...
done
Uptime: 1h4m5s
dumping to dev #da/0x20001, offset 190228
dump 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38
37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9
8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) wwhheerree
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc01717f4 in poweroff_wait (junk=0xc02b3a26, howto=-946356848)
at ../../kern/kern_shutdown.c:553
#2 0xc01931c8 in sbdrop (sb=0xc797bd90, len=158)
at ../../kern/uipc_socket2.c:793
#3 0xc0193058 in sbflush (sb=0xc797bd90) at ../../kern/uipc_socket2.c:772
#4 0xc0192b11 in sbrelease (sb=0xc797bd90, so=0xc6d59b40)
at ../../kern/uipc_socket2.c:455
#5 0xc0191443 in sorflush (so=0xc6d59b40) at ../../kern/uipc_socket.c:988
#6 0xc01900ad in sofree (so=0xc6d59b40) at ../../kern/uipc_socket.c:262
#7 0xc01901de in soclose (so=0xc6d59b40) at ../../kern/uipc_socket.c:327
#8 0xc018553a in soo_close (fp=0xc0f8fe40, p=0xc74b32a0)
at ../../kern/sys_socket.c:193
#9 0xc0166165 in fdrop (fp=0xc0f8fe40, p=0xc74b32a0) at ../../sys/file.h:212
#10 0xc01660ab in closef (fp=0xc0f8fe40, p=0xc74b32a0)
at ../../kern/kern_descrip.c:1079
#11 0xc0165dfc in fdfree (p=0xc74b32a0) at ../../kern/kern_descrip.c:945
#12 0xc016854d in exit1 (p=0xc74b32a0, rv=9) at ../../kern/kern_exit.c:186
#13 0xc01732d2 in sigexit (p=0xc74b32a0, sig=9) at ../../kern/kern_sig.c:1499
#14 0xc017304c in postsig (sig=9) at ../../kern/kern_sig.c:1402
#15 0xc028e6f0 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077940036, tf_esi = 134920284, tf_ebp = -1077940004,
tf_isp = -946356268, tf_ebx = 672838652, tf_edx = 134909952,
tf_ecx = 2048, tf_eax = 29, tf_trapno = 7, tf_err = 2,
tf_eip = 673074366, tf_cs = 31, tf_eflags = 647, tf_esp = -1077940096,
tf_ss = 47}) at ../../i386/i386/trap.c:164
#16 0xc02838f5 in Xint0x80_syscall ()
#17 0x80781c6 in ?? ()
#18 0x806eaa9 in ?? ()
#19 0x806e1fb in ?? ()
#20 0x8078778 in ?? ()
#21 0x805996f in ?? ()
#22 0x804ccd8 in ?? ()
#23 0x806a776 in ?? ()
#24 0x806a35f in ?? ()
#25 0x804b0a1 in ?? ()
(kgdb) frame 2
#2 0xc01931c8 in sbdrop (sb=0xc797bd90, len=158)
at ../../kern/uipc_socket2.c:793
793 panic("sbdrop");
(kgdb) print sb
$1 = (struct sockbuf *) 0xc797bd90
(kgdb) print *sb
$2 = {sb_cc = 158, sb_hiwat = 20480, sb_mbcnt = 512, sb_mbmax = 163840,
sb_lowat = 1, sb_mb = 0x0, sb_sel = {si_pid = 0, si_note = {
slh_first = 0x0}, si_flags = 0}, sb_flags = 64, sb_timeo = 0}
(kgdb) print len
$3 = 158
(kgdb) print m
$4 = (struct mbuf *) 0xc02b3a26
(kgdb) print *m
$5 = {m_hdr = {mh_next = 0x72646273, mh_nextpkt = 0x4e00706f,
mh_data = 0x63706900 ,
mh_len = -1377828864, mh_type = -16336, mh_flags = 73}, M_dat = {MH = {
MH_pkthdr = {rcvif = 0x6d6d7564, len = -1373634439,
header = 0x616dc030 ,
csum_flags = 1668248440, csum_data = 1718968939, aux = 0xae60},
MH_dat = {MH_ext = {
ext_buf = 0x616dc030 ,
ext_free = 0x636f7378, ext_size = 1937007979, ext_ref = 0xaea0},
MH_databuf =
"0Àmaxsockets\000\000 ®0Àsockbuf_waste_factor\000\000\000\000à®0Àkern.ipc.maxsockets\000\004¯0À\000\000\000\000\000\000\000\000\024¯0Àaccept\000connec\000sfbufa\000\000\000\000\000\000\000\000sf_buf_ref:
referencing a free sf_buf", '\000' , "sf_buf_free: freeing free
sf_buf\000sfpbs"}},
M_databuf = "dummy\000
®0Àmaxsockbuf\000\000`®0Àmaxsockets\000\000 ®0Àsockbuf_waste_factor\000\000\000\000à®0Àkern.ipc.maxsockets\000\004¯0À\000\000\000\000\000\000\000\000\024¯0Àaccept\000connec\000sfbufa\000\000\000\000\000\000\000\000sf_buf_ref:
referencing a free sf_buf", '\000' , "sf_buf_free: freein"...}}
(kgdb) print mn
$6 = (struct mbuf
Re: ppp -auto gone again
On Sun, Jul 09, 2000 at 06:04:47PM +0200, Daniel Rock wrote: > - if (pri > 0) > + if (pri >= 0) Groan. "The problem must be somewhere in ip.c, the other changes were purely cosmetic". Famous last words. Thanks, I've re-reverted to the current version, applied your patch and -auto mode works. /s/Udo (I need new glasses) -- I have learned over the years, that if it is the truth you seek, then honesty on your own part, is the best policy. That and torture. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Suspicious warnings in -CURRENT
Hi, I've had the warnings, too, always after successful search operations in vi and mutt. cvs co -D '06 Jul 2000 12:00' src/lib/libc/regex/ and rebuild/reinstall of libc fixed it. It seems the bug was introduced in regcomp.c 1.20/1.121 and/or engine.c 1.8. /s/Udo (still trying to find out what broke ppp -auto) -- I'd like to meet the man who invented sex and see what he's working on now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp -auto gone again
Hi, ppp -auto stopped working fater I've updated my box from 06/17-Sources to yesterday's version (07/06, approx. 1500 GMT). tcpdump -ni tun0 shows the traffic but that's it. ppp.log doesn't show any obvious problems. -ddial works, sending a manual dial command (via pppctl) brings the link up immediately. IPv6-related breakage again (this is an IPv4-only system) or something new? /s/Udo (too tired for a decent bughunt) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
On Tue, Mar 07, 2000 at 06:48:56PM +0100, Brad Knowles wrote: > Must be a FreeBSD vs. Solaris thing Are you using OpenSSH or the 'normal' ssh on your Solaris box? I've just tried to copy files between my FreeBSD box @home and one of 'my' Solaris boxes @work. All four possible directions work exactly as expected with both binary and text files. @home: FreeBSD 4.0, 05-MAR-2000, USA_RESIDENT=NO SSH Version OpenSSH-1.2.2, protocol version 1.5. Compiled with SSL. @work: SunOS [...] 5.6 Generic_105181-05 [...] SSH Version 1.2.27 [sparc-sun-solaris2.6], protocol version 1.5. Standard version. Does not use RSAREF. /s/Udo -- I'd like to meet the man who invented sex and see what he's working on now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.4 -> 4.0 upgrade problems
On Tue, Mar 07, 2000 at 11:56:32AM +0200, Ruslan Ermilov wrote: > + make buildkernel installkernel KERNEL="NAME_OF_YOUR_KERNEL" You should skip the "KERNEL=..." part. buildkernel and installkernel use KERNEL for *everything* - including the filename of the new kernel. In other words: root@nathan# ls -l / | grep '^-' [.profile, .cshrc, COPYRIGHT] -r-xr-xr-x 1 root wheel 2130036 5 Mär 18:00 kernel root@nathan# make buildkernel KERNEL=UE && make installkernel KERNEL=UE [several minutes later] root@nathan# ls -l / | grep '^-' [.profile, .cshrc, COPYRIGHT] -r-xr-xr-x 1 root wheel 2130036 7 Mär 19:39 UE -r-xr-xr-x 1 root wheel 2130036 5 Mär 18:00 kernel And upon reboot, the system will boot /kernel, not /UE. 4.0-current as of 05-MAR-2000. "make buildkernel" and "make installkernel" use GENERIC and kernel for the config file and the filename of the kernel. UPDATING should only contain this basic version. BTW, make buildkernel KERNEL=GENERIC;make installkernel KERNEL=GENERIC installs /GENERIC :( The big question: Is it a bug or is it a feature? Being able to create a kernel without messing with your existing kernel is an important feature for large installations: A dedicated build server could create WEBKERNEL, MAILKERNEL, FIREWALLKERNEL, SCSIKERNEL, IDEKERNEL etc. to be used by other machines. On the other hand, a lot of people will small/one-machine installations will wonder just why their new kernel doesn't work as expected. And yes, I've been there... /s/Udo (working on a possible solution for this problem) -- Eat the rich -- the poor are tough and stringy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
On Tue, Mar 07, 2000 at 11:26:03AM +0200, Sheldon Hearn wrote: > Is it supposed to be possible to drop a "1024-bit" host key from the old > ssh1 port into /etc/ssh? It works for me. I've created my host key with ssh-1.2.26 and the base system OpenSSH accepted it without any problems. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: des/ssl manpages lost
On Sun, Feb 27, 2000 at 11:43:26PM -0800, Kris Kennaway wrote: > > [OpenSSL 0.9.5 manpages for 'out' 0.9.4] > The OpenSSL API has changed a fair bit since 0.9.4 - not substantially, > but in a lot of little ways. Yikes, I'm getting old. My first reaction to this information was"Bah, whatever happend to the old days when changes in the API were a cause for a bump of the minor version number?" :( > I think it would be more confusing for someone to read about functions and > function semantics which don't exist in our version. No argument here. I assumed that an update from 0.9.4 to 0.9.5 did not include any changes to the API. > > [manpage-fixing] > Better make it quick :-) The first four sets of patches are in, three or four more will follow till midnight. For now, I'm concentrating on the obvious changes - only 240 hours till -RELEASE :) /s/Udo -- "Enjoy the beauty and power of root" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: des/ssl manpages lost
On Sun, Feb 27, 2000 at 02:05:51PM -0800, Kris Kennaway wrote: > > [des manpages lost] > We probably should revive these. OpenSSL 0.9.5 has a complete set of > manpages, and I hope to import it shortly after the release, but for > 4.0-REL we should keep these. What about importing the OpenSSL 0.9.5 manpages instead? If you revive the old des manpages for 4.0-REL and import OpenSSL 0.9.5 after 4.0-REL but before the creation of the 4.x-stable branch, we'll end up with two sets of des-related manpages in /usr/share/man/something. That's a landmine. > The ssl(8) references should change to openssl(8) since that's what we call > it, except neither of us (OpenBSD or FreeBSD) have a manpage for it :-) It's only one of the 178 unresolved references found by my (very crude) crossreference script. Most of them are references to manpages found under /usr/ports or references to external documents (like POSIX 1003b). But we still have references to cdplay (RIP with 3.0), xntpd (RIP with 4.0), bad144 (dito), ... Current totals: 312 warnings about references in 263 manpages (including "legal" missing references). I'll create PRs and patches to give Nik and the doc team a chance to fix at least some of them before 4.0-REL. > Excellent - it's nice to hear when things go well. Two more datapoints: openssh-client (FreeBSD) -> ssh1/Solaris works (as expected) openssh-client (FreeBSD) -> ssh2/Solaris does not work (no surprise) /s/Udo -- Now they show you how detergents take out bloodstains; a pretty violent image there. I think if you've got a T-shirt with a bloodstain all over it, maybe laundry isn't your biggest problem. Maybe you should get rid of the body before you do the wash. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Am I doing this right?
On Sun, Feb 27, 2000 at 10:37:01PM -0600, Steve Kaczkowski wrote: > One source says that I should recompile my kernel, reboot into single > user and do a 'make installworld'. Makes sense but I can't recompile my > kernel, I get errors like: > > config GENERIC You're using the 3.x-version of config to parse a config file for a 4.x system. You have to use the new versions of config etc. to generate a 4.x kernel. If you're able to boot your machine with the GENERIC kernel, the sequence "make buildkernel && make installkernel" will work just fine. Otherwise, you'll have to follow the instructions in /usr/src/UPDATING to update the neccessary tools. > the 'make installworld' it'll go for a bit and then finally error out > with: > [install-info fails] Known problem. make -DNOINFO installworld; make installworld. See /usr/src/UPDATING for details. > Any hints? /usr/src/UPDATING :) /s/Udo -- Abandon the search for Truth; settle for a good fantasy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
des/ssl manpages lost
Hi, I've noticed that the first successfull make world after the openssh import failed to update several manpages for des related functions. The functions were moved into libcrypto, the manpages were deleted alongside libdes. The missing files are: /share/man/man3/des_read_password.3.gz /share/man/man3/des_read_2password.3.gz /share/man/man3/des_string_to_key.3.gz /share/man/man3/des_string_to_2key.3.gz /share/man/man3/des_read_pw_string.3.gz /share/man/man3/des_random_key.3.gz /share/man/man3/des_set_key.3.gz /share/man/man3/des_key_sched.3.gz /share/man/man3/des_ecb_encrypt.3.gz /share/man/man3/des_3ecb_encrypt.3.gz /share/man/man3/des_cbc_cksum.3.gz /share/man/man3/des_cbc_encrypt.3.gz /share/man/man3/des_3cbc_encrypt.3.gz /share/man/man3/des_pcbc_encrypt.3.gz /share/man/man3/des_cfb_encrypt.3.gz /share/man/man3/des_ofb_encrypt.3.gz /share/man/man3/des_quad_cksum.3.gz /share/man/man3/des_enc_read.3.gz /share/man/man3/des_enc_write.3.gz /share/man/man3/des_set_odd_parity.3.gz /share/man/man3/des_is_weak_key.3.gz To be precise, it's just one file, the other 20 are hard links to it. The manual pages were generated from /usr/src/crypto/libdes/des_crypt.man. The manualpage for des(1) is also missing (it was created from des.man). 4.0-current doesn't contain the des executable but several crypto-related manpages refer to des(1). Additionally, the new manpage for sshd contains several references to ssl(8). This manpage is missing, too. Point of reference: 4.0-current, last update from cvsup1.de (base system) and cvsup.internat (crypto stuff) at 27-FEB-2000 02:00 +0100. make.conf contains USA_RESIDENT=NO, all other RSA- and crypto-related variables haven't been changed. On the other hand, make world and friends completed perfectly and I've already switched from the port version of ssh1 to the integrated sshd. No problems so far (client: SecureCRT 3.01, RSA-based authentication, 3DES encryption). Standing ovations. /s/Udo -- I'd like to meet the man who invented sex and see what he's working on now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/crypto/libdes [...]
On Thu, Feb 24, 2000 at 09:34:36PM +0200, Mark Murray wrote:
> markm 2000/02/24 21:34:35 SAST
> IP libdes. All hail libcrypto!
With -current (cvsuped from cvsup.freebsd.org/cvsup.internat.freebsd.org) as
of right now (23:40 +0100):
>>> stage 4: populating /usr/obj/usr/src/i386/usr/include
[...]
cd /usr/src/secure/lib/libcrypto; make beforeinstall
[...]
cd /usr/src/secure/lib/libdes; make beforeinstall
cd: can't cd to /usr/src/secure/lib/libdes
*** Error code 2
Patch for Makefile.inc1 1.138 included.
/s/Udo
--
Booze is the answer. I don't remember the question.
--- Makefile.inc1.orig Thu Feb 24 23:24:49 2000
+++ Makefile.inc1 Thu Feb 24 23:36:15 2000
@@ -585,7 +585,6 @@
.if exists(${.CURDIR}/secure/lib/libcrypto)
cd ${.CURDIR}/secure/lib/libcrypto; ${MAKE} beforeinstall
.endif
- cd ${.CURDIR}/secure/lib/libdes;${MAKE} beforeinstall
.if exists(${.CURDIR}/secure/lib/libssl)
cd ${.CURDIR}/secure/lib/libssl;${MAKE} beforeinstall
.endif
