Date: Thu, 24 Jan 2019 12:04:30 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 235158] lang/lua53 no longer linked against pthread Message-ID: <bug-235158-7788-Dd4B7qXjtW@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235158-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-235158-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235158 --- Comment #7 from i+fbsd@amlegion.org --- (comment #6) ldd /usr/local/lib/lua/5.3/_cqueues.so /usr/local/lib/lua/5.3/_cqueues.so: libssl.so.111 =3D> /usr/lib/libssl.so.111 (0x8006be000) libcrypto.so.111 =3D> /lib/libcrypto.so.111 (0x800e00000) libthr.so.3 =3D> /lib/libthr.so.3 (0x800753000) libm.so.5 =3D> /lib/libm.so.5 (0x80077e000) libc.so.7 =3D> /lib/libc.so.7 (0x800248000) When in a FreeBSD 12-RELEASE system, luarocks, installed from source, the latest release on their page, has an issue wherein unzip fails. Installing unzip from ports didn't seem to fix it, and can't remember what I actually = did to fix it. Only ran into this on one machine, on the other machine I think I took 3.0.1 and went with it to outright avoid the issue with luarocks. cqueues fails to build properly with libressl and openssl from ports (when installed from a repo that has set them as the default SSL library). cqueues was built from source (not luarocks for each of these tests). For libressl = and openssl it complained of an undefined symbol. For libressl the undefined sy= mbol was CRYPTO_THREAD_run_once. For openssl I sadly can't remember at this mome= nt, and likely would have to rebuild ports again against it just to pull back o= ut the error. The thing is, cqueues would build (make, make install), but when 'require("cqueues")' is ran it would complain about the aforementioned symb= ols. cqueues built with base ssl or openssl111 when built with luarocks. When lo= aded by lua however complained of missing 'inotify' symbols. That could be as si= mple as a badly configured luarocks but am not all too sure since I've never had luarocks consider itself running on linux and somehow directing things to be built against linux and being built against linux stuff work, and things be reduced to a runtime undefined symbol issue. On a FreeBSD 11.2-RELEASE jail, luarocks+cqueues (albeit an older version of luarocks) work and generate a working cqueues seemlessly (recently tested). This is actually with a lua53 from FreeBSD pkg repos, where "ldd lua" does = not show libthr. So consequently, it would seem that -pthread *is not needed* on FreeBSD 11.2-RELEASE? So we might can say that this bug only effects FreeBSD 12-RELEASE. With a system where libressl is the default ssl under FreeBSD 12-RELEASE, I built cqueues like so: "ALL_LDFLAGS=3D-L/usr/lib make all" then "make insta= ll". With a system where the ssl was base or openssl111 I just did "make all" th= en "make install". There was of course a fetch the release and untar it somewh= ere in there. The "make install" was ran as root.=20 When luarocks attempts to fetch cqueues for lua-http which I also use, I let it, then tell luarocks to "remove --force --local cqueues" and let luarocks complain about dependencies in the future. I basically get things working a= nd use luarocks where I can, and where I can't, install myself if possible. I = came up with this method when I saw a pull request still in the works in regards= to libressl but never merged over at wahern/cqueues and I had systems that were using libressl as default. (comment #4) I'll need to patch ports and do a poudriere run, but from a quick glimpse at the diff I'm guessing it will work. I'll update with information as to this after patching ports and generating a new package. (comment #5) I'll naively ask why it's important that lua-5.3.so not have a dependency on pthreads? I can't exactly think of a case where it would render a degradati= on in performance or cause an issue, but I'd like to understand the reasoning behind that. That said, the review linked gives the option of linking again= st pthreads. I would argue for it to be built against pthreads by default (the default option), since the FreeBSD pkg repos will use the defaults in the p= ort, and without it as default, everyone who uses lua at this point with threads will need to build lua from ports or from source. That won't effect me (I'll just build with pthreads on my own pkg repos) but would effect others. Also= I would assume the test code given in the review probably would work under lua 5.1 and 5.2. I'm pretty sure about 5.2, but I've actually actively avoided = lua 5.1 and came to lua using 5.2, so wouldn't know for sure. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235158-7788-Dd4B7qXjtW>