On Tue, Nov 10, 2020 at 06:34:21PM +0100, Christopher Gregory via blfs-support wrote: > Hello, > > I am working through another installation, and have found that libsoup will > not compile against sysprof. The following error occurs: > > /usr/bin/ld: /usr/lib/libsysprof-capture-4.a(sysprof-collector.c.o): in > function `use_single_trace': > /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:119: > undefined reference to `pthread_getspecific' > > The only way that I could get libsoup to compile and install was by going > into the meson_options.txt and setting the option to use sysprof to disabled. > > Has anyone actually tested and got this combination to work? > > I notice that arch have dropped the need to make sysprof a requirement. I > have not found any patch to date to actually get it to work. I am using the > svn version of systemd blf from 2020-11-01. There has been no update to > sysprof so I could not see if a later version worked. >
Hi, Christopher. I asked on -dev last month *why* sysprof was recommended. The answer was that if sysprof is not present, libsoup's build will now download and install it as a sub-module. In my case I'd had problems because of static modules (I hide them so that I know what needs to be rebuilt if a package has a vulnerability - the old, old zlib problem from years ago). For me, sysprof builds ok. It looks as if in your build it is not finding libpthread. I can't see any references to pthread i nthe meson files I looked at, but in verbose builds (ninja -v) it magically appears for me, in the case of sysprof I see it in -fPIC -pthread -DSYSPROF_CAPTURE_COMPILATION for the first target (src/libsysprof-capture/libsysprof-capture-4.a.p/sysprof-address.c.o). Quoting https://mesonbuild.com/howtox.html | Enable threads | | Lots of people seem to do this manually with | find_library('pthread') or something similar. Do not do that. It | is not portable. Instead do this. | | thread_dep = dependency('threads') | executable(..., dependencies : thread_dep) From that, the configuration information re 'threads' is what matters. Im my case (just before glib-2.0) - Program gdbus-codegen found: YES Found pkg-config: /usr/bin/pkg-config (0.29.2) Program gdbus-codegen found: YES Program gdbus-codegen found: YES Configuring sysprof-version.h using configuration Run-time dependency threads found: YES Run-time dependency glib-2.0 found: YES 2.66.2 Did meson find it on your system ? I'm guessing that perhaps meson only looks for the header file. The library comes from glibc. In LFS we have a symlink from /usr/lib/libpthread.so to /lib. There is also a static lib (which I hide). > Re-installing sysprof made no difference to the above error. I have only > used the commands listed in the book and not added anything extra to the > build commands, ie nothing optional. > > Regards, > > Christopher. I'm sorry, I'm not well up on all the details of how meson works. But this seems an uncommon problem and makes me wonder if something has trashed either the /usr/lib/libpthread.so symlink or /lib/libpthread.so ? I would epect the static libpthread.a to get used, but this is all turning into guesses and hypotheses on my part. ĸen -- Brave Sir Nigel ran away! When reality reared its ugly head, Sir Nigel turned his tail and fled. Brave brave brave Sir Nigel. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
