On 2020/06/02 15:55, Aisha Tammy wrote:
> > All these static libraries mean that things won't get updated
> > automatically when a library is updated. Say you install purritobin
> > and there is a later security fix to usockets; purritobin won't be
> > updated unless you manually force it (e.g. by bumping REVISION).
> > The normal way of handling this with almost everything else in ports
> > is to use shared libraries.
> >
> I totally agree but upstream has mandated that this library is to be used
> static only and with -flto -O3 (which Brian has removed stating unsupported archs, thanks brian!).
that could just be changed in the port like you did before (but then
actually make use of it). I don't think we honestly care about the
difference upstream talks about in the ticket (160k req/sec with
shared libs, to 215k req/sec with static+lto, on some unspecified OS).
https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325
Packagers for at least some other OS will want this too if they're
going to include it in their package systems.
> Upstream have also rejected my patch to add shared libraries :( and is adamant
> on using both the above flags (which was a separate issue that was raised, to
> remove the flags and make them optional depending on distribution)
>
> Does ports not handle such an automated revision bump for static libraries
> that get updated? (am just asking, I don't know the intricacies and details
> of shared/static library things)
If there was a shared library as well you could list it as a "fake" WANTLIB
entry (it would show as "extra" so we add a comment to say what's going on)
and then it would at least get updated if the shared library version number
(.so.X.Y) changes though that doesn't force it for every update either.
Really with static libs you need to bump all the downstream users or
set a tight dependency on the particular version number.
> I am not sure how to resolve this conflict...
>
>
> an aside: why was -O3 removed, upstream has it present and wants it to be there?
Higher opt levels increase risk of hitting compiler bugs (maybe only
on certain architectures). If the code implements anything which is
undefined behaviour that can cause problems with optimisers too,
especially at higher opt levels.
Ports policy is to respect what is set by the user / ports infrastructure,
usually -O2, but sometimes it's necessary to change that on certain arches.
No comments:
Post a Comment