LTO on Windows now working

[Rene Engelhard]

Am 25.09.20 um 12:54 schrieb Michael Meeks:
> 	I wonder if, ABI-wise, we could static link sal with libmerged for the
> purpose of LTO and get away with it =)

I disagree.

> 	Since there is no real C++ ABI, and no exported symbols, particuarly
> exceptions there - that could work across platforms and give a big win.
>
> 	Ideally we could get down the chain from the grey (cf. attached
> picture) to the bottom there: cppuhelper, xmlreader, cppu, salhelper, sal.

Nope :)

https://packages.debian.org/search?keywords=libuno-sal3

https://packages.debian.org/search?keywords=libuno-cppu3

https://packages.debian.org/search?keywords=libuno-cppuhelpergcc3-3

https://packages.debian.org/search?keywords=libuno-salhelpergcc3-3


Given it's a public library it has to be in /usr/lib. :)


And there is

https://packages.debian.org/search?keywords=uno-libs-private

as a hack given public libraries need said  xmlreader ...

  ...
> 	I imagine on Linux that would cause severe grief around exceptions -
> but I think Windows can handle that with string comparisons at some cost (?)
>
> 	I wonder if (assuming we still believe that C++ UNO plugins exists as a
> 'thing' ;-) We could try on Linux increasing libmerged to include all of
> the lower base code - too - and (perhaps) - symlink it to all of the old
> library names. I -think- (worth checking) that the library loader will
> resolve those through the symlink to the same library loaded once -
> arguably giving back-compatibility at the expense of some packaging
> changes (I guess).

With the expense of overhauling the whole package, merging all those
libs into

"ure" and/or make simple "ure" depend on the whole lot of libreoffice-core?

https://packages.debian.org/search?keywords=ure


One can use LTO (if one makes it work on Linux, but then as I know LO it
will only be kept working for x86-64 anyway...) but please don't merge
those public libraries :-)

Regards.


Rene