Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Jul 2014 16:27:44 -0700
From:      Kevin Oberman <rkoberman@gmail.com>
To:        Kurt Jaeger <lists@opsec.eu>
Cc:        jerry@seibercom.net, FreeBSD Ports <freebsd-ports@freebsd.org>
Subject:   Re: Bug 191256 - [PATCH] security/libgcrypt: update to 1.6.1
Message-ID:  <CAN6yY1sTHjFtC-GTPy%2BGVpncgyJgyRqSf_bHzoe7O4G1snzydw@mail.gmail.com>
In-Reply-To: <20140705225007.GD56726@home.opsec.eu>
References:  <20140704132332.7a09caa5@scorpio> <20140705080355.GB2586@home.opsec.eu> <CAN6yY1tK3zd8prfSug8dSnN8hJWyUk5p18oLdQzGMFqH_7%2BS8g@mail.gmail.com> <20140705225007.GD56726@home.opsec.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jul 5, 2014 at 3:50 PM, Kurt Jaeger <lists@opsec.eu> wrote:

> Hi!
>
> > > > I was just wondering if this port could please be committed.
> > >
> > > I tried to build it on 10.0-amd64 and it failed to compile.
> > >
> > > Log see http://people.freebsd.org/~pi/misc/build-libgcrypt.txt
>
> > You might try deleting the port and  re-installing.
>
> I tried that, no change for the build.
>
> > Looks a log like it is
> > building the new libgcrypt.so but linking to the old one which lacks the
> > listed symbols.
>
> I checked /usr/local/lib for any libgcrypt, nothing was found.
>
> --
> pi@opsec.eu            +49 171 3101372                         6 years to
> go !
>

Hmm. I'm a bit confused now. I checked the newly linked libgcrypt.so.20
(located in src/.libs) and it seems to have all of the "missing" symbols in
its symbol table, but all are undefined. I ran nm -D on the file and:
                 U _gcry_aes_amd64_decrypt_block
                 U _gcry_aes_amd64_encrypt_block
                 U _gcry_blowfish_amd64_cbc_dec
                 U _gcry_blowfish_amd64_cfb_dec
                 U _gcry_blowfish_amd64_ctr_enc
                 U _gcry_blowfish_amd64_decrypt_block
                 U _gcry_blowfish_amd64_do_encrypt
                 U _gcry_blowfish_amd64_encrypt_block
                 U _gcry_cast5_amd64_cbc_dec
                 U _gcry_cast5_amd64_cfb_dec
                 U _gcry_cast5_amd64_ctr_enc
                 U _gcry_cast5_amd64_decrypt_block
                 U _gcry_cast5_amd64_encrypt_block
                 U _gcry_salsa20_amd64_encrypt_blocks
                 U _gcry_salsa20_amd64_ivsetup
                 U _gcry_salsa20_amd64_keysetup
                 U _gcry_serpent_sse2_cbc_dec
                 U _gcry_serpent_sse2_cfb_dec
                 U _gcry_serpent_sse2_ctr_enc
                 U _gcry_sha1_transform_amd64_ssse3
                 U _gcry_twofish_amd64_cbc_dec
                 U _gcry_twofish_amd64_cfb_dec
                 U _gcry_twofish_amd64_ctr_enc
                 U _gcry_twofish_amd64_decrypt_block
                 U _gcry_twofish_amd64_encrypt_block

Looks like this is in the maze of twisty little passages called libtool. I
see cipher/cast5.c being compiled with no error using libtool. but I don't
see any indication that it is being linked when libtool actually builds
libgcrypt.so.20. But I don't know enough of libtool to be sure of much of
anything when it gets involved.

BTW, this bumps the version number of the shareable, so a note needs to be
put into UPDATING to be-build all dependent ports.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1sTHjFtC-GTPy%2BGVpncgyJgyRqSf_bHzoe7O4G1snzydw>