Based on your comments, I've changed it back to using the shared library, though I am still building a static library as well.
Thanks a lot for all your help! comments? PS: yes, uwebsockets did go from 0.17.6 to 18.1.0 Aisha On 6/3/20 11:14 AM, Stuart Henderson wrote: > 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. >
purritobin-0.2.1.tgz
Description: application/compressed-tar
uwebsockets-18.1.0.tgz
Description: application/compressed-tar
usockets-0.4.0.tgz
Description: application/compressed-tar
