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