On Tue, Nov 10, 2020 at 08:19:26PM +0100, Christopher Gregory via blfs-support
wrote:
>
>
> > Sent: Wednesday, November 11, 2020 at 7:30 AM
> > From: "Ken Moffat via blfs-support"
> > <blfs-support@lists.linuxfromscratch.org>
> > To: "BLFS Support List" <blfs-support@lists.linuxfromscratch.org>
> > Cc: "Ken Moffat" <zarniwh...@ntlworld.com>
> > Subject: Re: [blfs-support] libsoup will not build with sysprof
> >
> > 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
I've just noticed (after looking at libsoup output) that this is
NOT -lpthread, which I had assumed, but -pthread. That is actually
one of the CXXFLAGS which it uses. From a reply on stackoverflow
that causes '%{pthread:' items from 'gcc -dumpspecs' to be used on
linux gcc systems, which turns on -D_REENTRANT (errno calls become
a function returning a thread-local location) and adds -lpthread.
So this is more portable.
[https://stackoverflow.com/questions/2127797/significance-of-pthread-flag-when-compiling]
> > 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
> >
>
> Hello Ken,
>
> sysprof does successfully build and install for me. It is libsoup that is
> allergic to sysprof. I have successfully build and installed libsoup, by
> disabling the need for it in the meson_options.txt file in libsoup's source
> code.
>
Ah, I started by lookign at libsoup, then noticed the reference to
sysprof in the pthread issue and thought I was looking at the wrong
package. I've just looked again and I see that although it was
indeed libsoup which failed to build, the problem was in linking to
/usr/lib/libsysprof-capture-4.a which could not find libpthread.
That is maybe looking only for libpthread.a. But I assume that is
available to your user.
Unfortunately, my log from libsoup only mentions 'thread' in the
'-pthread' references from the vernbose ninja build.
> The mentioned symlink on my system looks like this:
>
> lrwxrwxrwx 1 root root 25 Nov 2 20:32 /usr/lib/libpthread.so ->
> ../../lib/libpthread.so.0
>
> I used jhalf to build lfs, as I always do.
>
I assume the symlink is working, otherwise everything which uses
libpthread.so would break. Out of ideas.
No experience of jhalfs (my sources, unlike the book's default layout,
are on an nfs mount - I don't want to build there, and anyway I
might be buildign the same package on two systems at the same time,
e.g. when building a new version of firefox because of
vulnerabilities).
> I did not notice libsoup downloading anything even though it does indeed
> appear in the sub-modules as a wrapper to download from git.
>
> I just attempted the build of libsoup again, and added the -v switch to ninja
> and these are the relevant lines:
>
> /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'
> /usr/bin/ld: /usr/lib/libsysprof-capture-4.a(sysprof-collector.c.o): in
> function `sysprof_collector_get':
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:395:
> undefined reference to `pthread_getspecific'
> /usr/bin/ld:
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:413:
> undefined reference to `pthread_setspecific'
> /usr/bin/ld:
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:434:
> undefined reference to `pthread_getspecific'
> /usr/bin/ld:
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:438:
> undefined reference to `pthread_setspecific'
> /usr/bin/ld:
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:445:
> undefined reference to `pthread_setspecific'
> /usr/bin/ld: /usr/lib/libsysprof-capture-4.a(sysprof-collector.c.o): in
> function `collector_init_cb':
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:465:
> undefined reference to `pthread_key_create'
> /usr/bin/ld:
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:467:
> undefined reference to `pthread_key_create'
> /usr/bin/ld: /usr/lib/libsysprof-capture-4.a(sysprof-collector.c.o): in
> function `sysprof_collector_init':
> /sources/sysprof-3.38.1/build/../src/libsysprof-capture/sysprof-collector.c:476:
> undefined reference to `pthread_once'
> collect2: error: ld returned 1 exit status
>
With a verbose build I hope to see the command (sometimes a very
long line) which triggered those errors. For a failed link, perhaps
a compile line just previously. But I guess that had '-pthread' so
I'm really out of ideas.
Certainly I had fun and games with libsoup, but only because I
rename static libs.
> This is the relevant section in meson's options in libsoup's source tarball
> that I changed from auto to disabled:
>
> option('sysprof',
> type: 'feature',
> value: 'auto',
> description: 'enable sysprof-capture support for profiling'
>
> Perhaps that is why it did not get downloaded, and yet was able to
> successfully build and install.
>
> Regards,
>
> Christopher
I'd like to look at that in detail, but I've got too much else to do
or to look at. If it works for you then I guess the "why do the
books instructions not build for me" question will have to remain
unanswered.
I'll wish you plain sailing with the remainder of your build.
ĸ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
