Problem building 1.4.5

[Mike Frysinger]

On Fri, Jun 18, 2010 at 12:28, Werner Koch wrote:
> On Fri, 18 Jun 2010 15:56, vapier.adi at gmail.com said:
>> neither exist today and likely wont for a long time (if someone were
>> to implement it today), and wouldnt be backwards compatible
>
> Well the symbol hiding is not really required and as long as we don't
> need to change the ABI there is no real need for it.

even if you change the ABI, symbol hiding isnt really necessary.  the
only functions you've guaranteed to be in the ABI are the ones you've
listed.  if other internal ones leak out and someone uses them and
they're later removed, that's not your concern.  a correctly
maintained ABI means exported symbols are only ever added, not
removed.

>> another option that isnt as clean is to add a Makefile target to run
>> `sed` on the .in file itself rather than configure.  then the contents
>> wouldnt change between the current version script and the renamed .in
>> version.
>
> Yeah. I was also thinking of this.  If we do it for one library we need
> to do it for all of the GnuPG related libs and thus I see no immediate
> need for it.  Let me discuss this with the libtool or binutils folks.

as soon as you use a version script to give to binutils, libtool takes
no part in the symbol munging.  had you used -export-symbols or
-export-symbols-regex, then we wouldnt really be bothering you guys
about these issues.  we'd be looking at libtool to hide the details
(and atm, it does a pretty good job of handling symbol prefixes).
-mike