control: reopen -1
control: notfixed -1 1.14.0+repack-12
Hello,
On Sat, 5 Oct 2019 19:46:00 +0200 Alf Gaida wrote:
> On Wed, 4 Sep 2019 11:42:01 +0200 Gianfranco Costamagna
> wrote:
> > I don't think exporting such c++ symbols is a good idea, specially
> because they change between architectures,
> > and with different gcc optimization levels.
>
> I think it is a good idea - or the best idea right now. Tbh - i don't
> care much about different optimization levels (i know what you mean and
> i know the small derivative that uses O3 :P) - i don't care about
> architecture dependend symbols. Situation is not that nice, because the
> most of the differences was introduced by different compilers in some
> architectures.
>
>
> And yes, upstream should hide not needed symbols - but that's not my
> area of expertise - if any derivative think that these symbols are of no
> use - they can just delete the symbols file and be done with. So all i
> can do right now is to make some symbols optional.
>
thanks for your explanation!
Can you please update once again the symbols file?
https://buildd.debian.org/status/package.php?p=fswatch=unstable
Looks like also in Debian a new symbol appeared...
btw, if you want to have a look please at
https://launchpad.net/ubuntu/+source/fswatch/1.14.0+repack-12/+build/17976872
https://launchpad.net/ubuntu/+source/fswatch/1.14.0+repack-12/+build/17976873
and also mark such symbols as optional, it will fix the troubles for both
Debian and Ubuntu
Unfortunately the actual package will be RC buggy on almost each gcc major
update, because c++ symbols are really likely
to change...
Wrt the upstream change, does this link helps?
https://developer.ibm.com/articles/au-aix-symbol-visibility/#3-using-the-export-list
it is a matter of adding an exportmap file with all the symbols listed there,
and tell gcc to use this as reference...
Or something like that :)
This one is even simpler...
https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html
G.
