Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

stable-digest V5 #796

0 views
Skip to first unread message

owner-freebsd...@freebsd.org

unread,
Feb 17, 2003, 5:38:49 PM2/17/03
to

stable-digest Monday, February 17 2003 Volume 05 : Number 796

In this issue:
Re: Buildworld error
ncurses and terminfo
UHCI/USB related panic while
Re: ECC memory error reporting
Date: Mon, 17 Feb 2003 10:01:31 +0200
Re: ECC memory error reporting
Re: ECC memory error reporting
Re: ECC memory error reporting
Re: ECC memory error reporting
Re: Diffserv tagging in stable?
Intel E5700
opendchub from ports fails to build
Re: ipfw1 or ipfw2 in STABLE?
Re: ipfw1 or ipfw2 in STABLE?
Re: opendchub from ports fails to build
Re: opendchub from ports fails to build
Re: Buildworld error
buildworld failure in OpenSSL....

----------------------------------------------------------------------

Date: Sun, 16 Feb 2003 14:33:59 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: Buildworld error

- --RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Feb 15, 2003 at 08:23:02PM -0800, Glendon M. Gross wrote:

> ===> gnu/usr.bin/tar
> rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o
> exclude.o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o
> hash.o human.o mktime.o modechange.o prepargs.o print-copyr.o quotearg.o
> safe-read.o save-cwd.o savedir.o unicodeio.o xgetcwd.o xmalloc.o
> xstrdup.o xstrtoul.o xstrtoumax.o buffer.o compare.o create.o delete.o
> extract.o incremen.o list.o mangle.o misc.o names.o rtapelib.o tar.o
> update.o tar.1.gz tar.1.cat.gz
> *** Error code 1

You didn't check out or update your source tree with the -P flag
(mandatory).

Kris

- --RnlQjJ0d97Da+TV1
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+UBHXWry0BWjoQKURAu9ZAKDsQYYk/2J3u5ftCEw3NTJ8B5mRxQCgkqfB
nWvIhdmcCi/B0JQp0O1UG44=
=sFLy
- -----END PGP SIGNATURE-----

- --RnlQjJ0d97Da+TV1--

------------------------------

Date: Sun, 16 Feb 2003 20:56:21 -0500
From: AlanE <al...@geeksrus.net>
Subject: ncurses and terminfo

Is it possible to build the base system ncurses with a full terminfo database?
- --
AlanE (Alan Eldridge)
Unix/C(++) IT Pro for 20 yrs, likes fixing weird distributed systems bugs.
KDE, KDE-FreeBSD Teams (http://www.kde.org, http://freebsd.kde.org/)

------------------------------

Date: Sun, 16 Feb 2003 21:42:41 -0500
From: "Louis A. Mamakos" <lo...@TransSys.COM>
Subject: UHCI/USB related panic while

I just upgraded a machine to this morning's version of the RELENG_4
branch of FreeBSD. I had problems booting it, where it would hang for
a bit, and then panic while probing for USB peripherals.

There was a USB hub plugged into the UHCI 2-port built-in "hub", and a USB
mouse plugged into the external hub. Attempting to boot with just the
external hub or just the external USB mouse seemed to break the same
way. As this machine has a somewhat critical role, I couldn't spend
a lot of time experimenting. I did jot down some of the information,
and it seems like uhci_idone() is invoked with a null pointer; the
fault virtual address is 0x4, which happens to be the offset of
ii->xfer in the structure..

What's interesting is that after the system is booted, I can plug
in the USB mouse, and things work just fine.

Does this ring a bell for anyone?

(kgdb) x/i 0xc02afecc
0xc02afecc <uhci_idone+12>: mov 0x4(%eax),%ebx
(kgdb) list *0xc02afecc
0xc02afecc is in uhci_idone (/usr/src/sys/dev/usb/uhci.c:1065).
1060
1061 /* Called at splusb() */
1062 void
1063 uhci_idone(uhci_intr_info_t *ii)
1064 {
1065 usbd_xfer_handle xfer = ii->xfer;
1066 struct uhci_pipe *upipe = (struct uhci_pipe *)xfer->pipe;
1067 uhci_soft_td_t *std;
1068 u_int32_t status = 0, nstatus;
1069 int actlen;
(kgdb)


When the system boots, I see this much on the console:

uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xdce0-0xdcff irq 2 at device 7.2 on pci0
usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered

and then there's this ominious hang followed by the panic.

louie

------------------------------

Date: Sun, 16 Feb 2003 20:49:29 -0800 (PST)
From: Rhett Monteg Hollander <victory...@yahoo.com>
Subject: Re: ECC memory error reporting

>Tritium has a 12.5 year half life and gives off a low energy beta
>particle and no gamma. IIRC, a sheet of paper is supposed to stop
>betas.
Alphas, not betas. Alpha particle consists of a He nucleus (2 neutrons + 2
protons), and since it carries positive charge and is relatively massive, it
can be halted by a single sheet of paper. Absolutely no danger to human health.
But beta particle (an electron) is much less charged\massive; high-charged
betas like from P-32 or P-33 can cause slight damage to human health, but
low-charged like you mentioned from H-3 cannot even penetrate through skin. You
can wash you hands in D2O (aka "heavy water"), and won't get any harm.

>Radium, which was used in the early glow-in-the-dark watches, mostly
>gives off energetic alphas and gammas. Some isotopes of radium have
>half lives in seconds and some in K years. The daughter products
>aren't any nicer. When it comes to being nasty, Tritium isn't even
>on the same planet.
Though radium was used there, but mostly phosphorus including some radioactive
isotopes. Those people at the military factories were usually damaged by
chemical solutions of phosphorus and hydrargyrum (when skin or air contact took
place). Co-60 and Zn-65 can emit gamma radiation (photons), but in relatively
low quantities. Several grams of Ra-226 when located close to human body for an
hour can definitely make him a potential client of local undertaking service.

- ---
Regards,
Rhett

>Kent

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

------------------------------

Date: Mon, 17 Feb 2003 10:01:31 +0200
From: "Doron Shmaryahu" <do...@crc.co.za>
Subject: Date: Mon, 17 Feb 2003 10:01:31 +0200

subscribe freebsd-stable

------------------------------

Date: Mon, 17 Feb 2003 22:07:02 +1100
From: Peter Jeremy <peter...@optushome.com.au>
Subject: Re: ECC memory error reporting

On Fri, Feb 14, 2003 at 12:58:34PM -0800, Matthew Dillon wrote:
> Find old WW2 bomber instrumentation. The government used fairly
> serious radioactive material in the glow-in-the-dark phospher
> instrumentation markings. I forget what it was exactly.
> It isn't enough to hurt you (though bomber pilots staring at rows upon
> rows of these instruments for long periods of time might be a different
> story),

The life-expectancy of a WW2 bomber pilot (at least RAF) was low
enough that it's unlikely that staring at the radium-coated
instrumentation would have made things detectably worse. (I suspect
that you'd have needed a radiation dose in the 100-200 rem range to
show up in the statistics).

> but they should be sufficient to mess up any high density memory
> placed in close proximity (less then an inch away).

I recall the big fuss when 64k DRAMS first appeared - the cell size
had dropped to the point where a single alpha particle could flip a
bit. There was lots of press about which manufacturers has the best
packaging to protect against hits. (And I suspect the biggest source
was the ceramic or CER-DIP package itself). RAM densities are now
3 orders of magnitude higher and there's virtually no mention of
radiation dangers...

Peter

------------------------------

Date: Mon, 17 Feb 2003 12:28:09 +0100
From: Ruben van Staveren <ru...@verweg.com>
Subject: Re: ECC memory error reporting

I heard something of a Cray creating such a disruptive field that it would
render a beowolf cluster, which was housed nearby, totally useless.

When the cray was phased out and removed from the premises suddenly all the
"signal 11" errors in that cluster disappeared ;)

- - Ruben

------------------------------

Date: Mon, 17 Feb 2003 22:29:24 +1100
From: Peter Jeremy <peter...@optushome.com.au>
Subject: Re: ECC memory error reporting

On Sun, Feb 16, 2003 at 08:49:29PM -0800, Rhett Monteg Hollander wrote:
>Alphas, not betas. Alpha particle consists of a He nucleus (2 neutrons + 2
>protons), and since it carries positive charge and is relatively massive, it
>can be halted by a single sheet of paper. Absolutely no danger to human health.

As long as it's outside the body. You don't want to ingest or inhale an
alpha-emitter if you value your health. And whilst the skin will stop
alpha particles, you could still wind up with an unattractive melanoma.

> You
>can wash you hands in D2O (aka "heavy water"), and won't get any harm.

Deuterium (H-2) isn't radioactive _at_all_ so there's no danger of
radiation poisoning. (It is, however, a biological poison because
deuterium is sufficiently different to hydrogen to gum up some of the
metabolic pathways). BTW, normal tap water is ~0.1% D2O or DHO.

Tritium (H-3) is a totally different animal. T20 _would_ be quite
dangerous - it will poison some biological pathways because it's
much heavier than hydrogen and if it does wind up in a cell, the
radioactive decay will kill the cell.

Peter

------------------------------

Date: 17 Feb 2003 16:16:54 +0100
From: Jukka Simila <ho...@jukkis.net>
Subject: Re: ECC memory error reporting

Althou I do enjoy this thread, a question that should've been asked long
time ago:

Isn't there anyone else who thinks this REALLY belongs to -chat?

------------------------------

Date: Mon, 17 Feb 2003 18:30:50 +0100 (CET)
From: mb...@solnet.ch
Subject: Re: Diffserv tagging in stable?

> Hi,
> Is there a way to do differv tagging in FreeBSD. I have a need to tag
> some
> packets that are routed by a FreeBSD machine. I just need to tag the
> packets
> as they exit the FreeBSD machine.

> Any pointers?

Hi,

i have a patch against the ipfw code which allows you to modify
different parameters on ip packets. It only works on routed packet,
not on packets destinated or originated from the machine self.

I will implement the modifikations on the new ipfw2 soon.

- --
Markus Binz, mb...@solnet.ch

------------------------------

Date: Mon, 17 Feb 2003 12:37:25 -0600
From: "Chris Byrnes" <ch...@JEAH.net>
Subject: Intel E5700

Does FreeBSD 4.x/5.x support the Intel E5700 chipset?

[Please cc: in replies, not subscribed. Thank you!]

------------------------------

Date: Mon, 17 Feb 2003 16:12:35 -0500
From: "Peter C. Lai" <sir...@cowbert.2y.net>
Subject: opendchub from ports fails to build

THe Open DC Hub 0.7.4 port fails to build on a 4.6.2-R-p6 machine.
(/usr/ports/net/opendchub)
The following errors appear:

cc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/libdata/perl/5.00503/mach/CORE -O -pipe -c perl_utils.c
In file included from /usr/libdata/perl/5.00503/mach/CORE/perl.h:1937,
from perl_utils.c:26:
/usr/libdata/perl/5.00503/mach/CORE/perly.h:14: warning: `PACKAGE' redefined
../config.h:70: warning: this is the location of the previous definition
cc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/libdata/perl/5.00503/mach/CORE -O -pipe -c utils.c
cc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/libdata/perl/5.00503/mach/CORE -O -pipe -c xs_functions.c
In file included from /usr/libdata/perl/5.00503/mach/CORE/perl.h:1937,
from xs_functions.c:28:
/usr/libdata/perl/5.00503/mach/CORE/perly.h:14: warning: `PACKAGE' redefined
../config.h:70: warning: this is the location of the previous definition
xs_functions.c:37: warning: `EXTERN_C' redefined
/usr/libdata/perl/5.00503/mach/CORE/perl.h:151: warning: this is the location of the previous definition
cc -O -pipe -o opendchub commands.o fileio.o main.o network.o perl_utils.o utils.o xs_functions.o -Wl,-R/usr/lib -Wl,-E -lperl -lm /usr/libdata/perl/5.00503/mach/auto/DynaLoader/DynaLoader.a -L/usr/libdata/perl/5.00503/mach/CORE -lperl -lm -lc -lcrypt -lperl -lm
perl_utils.o: In function `sub_to_script':
perl_utils.o(.text+0xc77): undefined reference to `call_pv'
gmake[2]: *** [opendchub] Error 1

Anyone else have issues before I submit a pr?
- --
Peter C. Lai
University of Connecticut
Dept. of Molecular and Cell Biology
Yale University School of Medicine
SenseLab | Research Assistant
http://cowbert.2y.net/

------------------------------

Date: Mon, 17 Feb 2003 16:15:02 -0500
From: "Scott M. Nolde" <sc...@smnolde.com>
Subject: Re: ipfw1 or ipfw2 in STABLE?

Claus Guttesen(cgut...@yahoo.dk)@2003.02.14 09:15:44 +0000:
> Hi.
>
> > man-page for ipfw(8) I get the impression that
> > STABLE only uses ipfw1 by
> > default and I'll have to enable ipfw2 by adding
> > "IPFW2=TRUE" to
> > /etc/make.conf and adding "options IPFW2" to the
> > kernel config. But I can't
>
> You're assumption is correct. I am running ipfw (in
> combination with ipfilter), ipfw for traffic-shaping
> (dummynet).
>
> I wanted to prioritize both outcoming and returning
> traffic, but ipfw (ver. 1) only allowed me to
> prioritize on the port, but not distinguish on the
> direction. The keyword ipfw2 has is src- and dst-port
> as well. So I recompiled my world and kernel and
> rebooted and everything went smoothly.
>
> As an example I've pasted my setup from
> /etc/rc.firewall (firewall type [Oo][Pp][Ee][Nn]:
>
> # do some traffic-shaping, configure a pipe
> ${fwcmd} pipe 10 config bw 1Mbit/s
> ${fwcmd} pipe 20 config bw 1Mbit/s
>
> # create some queues with various weight
> ${fwcmd} queue 11 config pipe 10 weight 50
> ${fwcmd} queue 12 config pipe 10 weight 25
> ${fwcmd} queue 13 config pipe 10 weight 5
> ${fwcmd} queue 21 config pipe 20 weight 50
> ${fwcmd} queue 22 config pipe 20 weight 25
> ${fwcmd} queue 23 config pipe 20 weight 5
>
> # create some rules that will be applied to the queues
> # inside-interface
> ${fwcmd} add 340 queue 11 tcp from 192.168.1.0/24 to
> any dst-port http in recv xl0
> ${fwcmd} add 340 queue 11 tcp from 192.168.1.0/24 to
> any dst-port ssh in recv xl0
> ${fwcmd} add 340 queue 12 tcp from 192.168.1.0/24 to
> any dst-port smtp in recv xl0
> ${fwcmd} add 340 queue 12 tcp from 192.168.1.0/24 to
> any dst-port pop3 in recv xl0
> ${fwcmd} add 340 queue 13 ip from 192.168.1.0/24 to
> any in recv xl0
> # outside-interface
> ${fwcmd} add 350 queue 21 tcp from any to
> 192.168.1.0/24 src-port http in recv xl1
> ${fwcmd} add 350 queue 21 tcp from any to
> 192.168.1.0/24 src-port ssh in recv xl1
> ${fwcmd} add 350 queue 22 tcp from any to
> 192.168.1.0/24 src-port smtp in recv xl1
> ${fwcmd} add 350 queue 22 tcp from any to
> 192.168.1.0/24 src-port pop3 in recv xl1
> ${fwcmd} add 350 queue 23 ip from any to
> 192.168.1.0/24 in recv xl1
>
> Hope this helps.
>
> regards
> Claus

FWIW, I use ipfw with dummynet in combination with ipf/ipnat for packet
filtering. I've written a script which might help a causal dummynet user
set up a queuing and bandwidth limiting packet filter.

It's kinda crude, and I based it on my DHCP-using firewall. Queues and
pipes are specified by setting some parameters and running the script.
The script can be found at http://www.smnolde.com/ipfw/ipfw-queue-bw-only

- --
Scott Nolde
GPG Key 0xD869AB48

------------------------------

Date: Mon, 17 Feb 2003 16:17:18 -0500
From: "Scott M. Nolde" <sc...@smnolde.com>
Subject: Re: ipfw1 or ipfw2 in STABLE?

Scott M. Nolde(sc...@smnolde.com)@2003.02.17 16:15:02 +0000:
> FWIW, I use ipfw with dummynet in combination with ipf/ipnat for packet
> filtering. I've written a script which might help a causal dummynet user
> set up a queuing and bandwidth limiting packet filter.
>
> It's kinda crude, and I based it on my DHCP-using firewall. Queues and
> pipes are specified by setting some parameters and running the script.
> The script can be found at http://www.smnolde.com/ipfw/ipfw-queue-bw-only
>

Make that https://www.smnolde.com/ipfw/ipfw-queue-bw-only

- --
Scott Nolde
GPG Key 0xD869AB48

------------------------------

Date: Mon, 17 Feb 2003 13:44:49 -0800
From: Kris Kennaway <kr...@obsecurity.org>
Subject: Re: opendchub from ports fails to build

- --qtZFehHsKgwS5rPz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Feb 17, 2003 at 04:12:35PM -0500, Peter C. Lai wrote:
> THe Open DC Hub 0.7.4 port fails to build on a 4.6.2-R-p6 machine.
> (/usr/ports/net/opendchub)

> Anyone else have issues before I submit a pr?

Firstly, 4.6.2 is not a supported release. However, checking
http://bento.freebsd.org shows that this is a known problem

http://bento.freebsd.org/errorlogs/i386-4-latest/opendchub-0.7.3.log

and the port has no maintainer, so send-pr'ing would not be useful
unless you have a fix. Instead, I suggest reporting the problem to
the developers.

Kris


- --qtZFehHsKgwS5rPz
Content-Type: application/pgp-signature
Content-Disposition: inline

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+UVfRWry0BWjoQKURAsftAJ9KZ0Je4UARpyNwECexUc8zCddzjQCg7NMY
seDFvQOIrf8qxrdEAxqhBAQ=
=OjQl
- -----END PGP SIGNATURE-----

- --qtZFehHsKgwS5rPz--

------------------------------

Date: Mon, 17 Feb 2003 17:06:25 -0500
From: "Peter C. Lai" <sir...@cowbert.2y.net>
Subject: Re: opendchub from ports fails to build

Thanks, I have a fix (albeit one that disables some features but allows
building).

If you do 'configure --disable-perl' it builds successfully, although
this means perl scripts will not be functional with the application.

On Mon, Feb 17, 2003 at 01:44:49PM -0800, Kris Kennaway wrote:
> and the port has no maintainer, so send-pr'ing would not be useful
> unless you have a fix. Instead, I suggest reporting the problem to
> the developers.
>
> Kris
>

- --
Pete

------------------------------

Date: Mon, 17 Feb 2003 14:15:01 -0800
From: "Glendon M. Gross" <gr...@xinetd.com>
Subject: Re: Buildworld error

I just updated my sources after installing a new version of cvsup, and
am now updating them with the cvs -P flag, which I did not know about.

I will let you know if it works, and if I am unsuccessful I will post
the error output. Thanks to all who responded.

Regards,

Glendon Gross

Kris Kennaway wrote:
> On Sat, Feb 15, 2003 at 08:23:02PM -0800, Glendon M. Gross wrote:
>
>
>>===> gnu/usr.bin/tar
>>rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o
>>exclude.o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o
>>hash.o human.o mktime.o modechange.o prepargs.o print-copyr.o quotearg.o
>>safe-read.o save-cwd.o savedir.o unicodeio.o xgetcwd.o xmalloc.o
>>xstrdup.o xstrtoul.o xstrtoumax.o buffer.o compare.o create.o delete.o
>>extract.o incremen.o list.o mangle.o misc.o names.o rtapelib.o tar.o
>>update.o tar.1.gz tar.1.cat.gz
>>*** Error code 1
>
>
> You didn't check out or update your source tree with the -P flag
> (mandatory).
>
> Kris

------------------------------

Date: Mon, 17 Feb 2003 17:37:02 -0500
From: Chuck Swiger <csw...@mac.com>
Subject: buildworld failure in OpenSSL....

I'll retry cvsup'ing, but:

[ ... ]
cc -O -pipe -march=pentium -DTERMIOS -DANSI_SOURCE
- -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl
- -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/crypto
- -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/crypto/
engine -I/usr/obj/usr/src/secure/usr.bin/openssl -DOPENSSL_NO_IDEA
- -DL_ENDIAN -DMONOLITH -I/usr/src/secure/usr.bin/openssl -DNO_IDEA -c
/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/apps/x509.c
cc -O -pipe -march=pentium -DTERMIOS -DANSI_SOURCE
- -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl
- -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/crypto
- -I/usr/src/secure/usr.bin/openssl/../../../crypto/openssl/crypto/
engine -I/usr/obj/usr/src/secure/usr.bin/openssl -DOPENSSL_NO_IDEA
- -DL_ENDIAN -DMONOLITH -I/usr/src/secure/usr.bin/openssl -DNO_IDEA -o
xopenssl app_rand.o apps.o asn1pars.o ca.o ciphers.o crl.o crl2p7.o
gst.o dh.o dhparam.o dsa.o dsaparam.o enc.o engine.o errstr.o gendh.o
gendsa.o genrsa.o nseq.o ocsp.o openssl.o passwd.o pkcs12.o pkcs7.o
pkcs8.o rand.o req.o rsa.o rsautl.o s_cb.o s_client.o s_server.o
s_socket.o s_time.o sess_id.o smime.o speed.o spkac.o verify.o version.o
x509.o -lssl -lcrypto
gzip -cn /usr/src/secure/usr.bin/openssl/man/CA.pl.1 > CA.pl.1.gz
gzip -cn /usr/src/secure/usr.bin/openssl/man/asn1parse.1 > asn1parse.1.gz
gzip -cn /usr/src/secure/usr.bin/openssl/man/ca.1 > ca.1.gz
[ ... ]
gzip -cn /usr/src/secure/usr.bin/openssl/man/verify.1 > verify.1.gz
gzip -cn /usr/src/secure/usr.bin/openssl/man/version.1 > version.1.gz
gzip -cn /usr/src/secure/usr.bin/openssl/man/x509.1 > x509.1.gz
===> secure/usr.bin/scp
cc -O -pipe -march=pentium
- -I/usr/src/secure/usr.bin/scp/../../../crypto/openssh
-DNO_IDEA -c /usr/src/secure/usr.bin/scp/../../../crypto/openssh/scp.c
cc -O -pipe -march=pentium
- -I/usr/src/secure/usr.bin/scp/../../../crypto/openssh
-DNO_IDEA -o scp scp.o -lssh
/usr/obj/usr/src/i386/usr/lib/libssh.so: undefined reference to
`EVP_aes_128_cbc'
/usr/obj/usr/src/i386/usr/lib/libssh.so: undefined reference to
`EVP_aes_192_cbc'
/usr/obj/usr/src/i386/usr/lib/libssh.so: undefined reference to
`EVP_aes_256_cbc'
/usr/obj/usr/src/i386/usr/lib/libssh.so: undefined reference to
`HMAC_CTX_cleanup'
*** Error code 1
Stop in /usr/src/secure/usr.bin/scp.
*** Error code 1
Stop in /usr/src/secure/usr.bin.
*** Error code 1
Stop in /usr/src/secure.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.

- -Chuck

------------------------------

End of stable-digest V5 #796
****************************

To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-stable-digest in the body of the message

0 new messages