Hi Aisha -- ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, June 8, 2020 9:07 AM, Aisha Tammy <openbsd.po...@aisha.cc> wrote:
> 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. I made just tiny tweaks to usockets and purritobin; just WANTLIB and BDEP/LDEP fixes. Maybe it would be nice to upstream the usockets shared library building? ~Brian
purritobin.tgz
Description: application/compressed-tar
usockets.tgz
Description: application/compressed-tar
