Problem building 1.4.5

Mike Frysinger vapier.adi at gmail.com
Tue Jun 22 22:14:03 CEST 2010


On Tue, Jun 22, 2010 at 05:07, Werner Koch wrote:
> On Mon, 21 Jun 2010 18:24, vapier.adi at gmail.com said:
>> at any rate, if we sent a patch that turned src/libgcrypt.vers into a
>> src/libgcrypt.vers.in and then ran `sed` on it, would you guys take it
>
> As I said, this uglifies the version file and the version file is part
> of the ABI: It defines which symbols belong to which ABI.  Thus it is
> really important.

running a manual sed on it wouldnt uglify it.  the contents wouldnt
change at all.  as long as the current style is adhered to, it's quite
trivial.

in the Makefile.am:
libgcrypt.vers: libgcrypt.vers.in
    sed -r 's:\<(gcry_):@SYMBOL_PREFIX@&:g' $< > $@

> Of course that reises a related problem: As soon as we need do change
> the API we won't can't support Blackfin anymore.  This is actually the
> same as with platforms where we don't have a GNU (or Solaris) linker -
> we would need to break the ABI on those platform.
>
> Given that we are using the GNU toolchain, it is very unfortunate that
> we can't support Blackfin in the same way as other GNU platforms.  I
> guess that this problem has not been raised earlier is due to the
> there-is-only-intel-and-linux-in-the-world believe of one well-known
> glibc hacker.

well, some clarifications here:
 - Solaris does support symbol versioning and if my history is
correct, it had it before the GNU toolchain
 - Blackfin only supports uClibc because glibc isnt interested in
supporting nommu systems, and uClibc does not support symbol
versioning
-mike



More information about the Gcrypt-devel mailing list