Re: [blfs-support] libsoup will not build with sysprof
On Fri, Nov 27, 2020 at 09:46:39PM +0100, Pierre Labastie via blfs-support wrote: > On Fri, 2020-11-27 at 17:50 +, Ken Moffat via blfs-support wrote: > > 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. > > > > > > 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. > > > > Starting a fresh sub-thread to reply to this, because we were > > floundering. I've just hit this, and apart from Christopher's post > > google found > > https://github.com/mesonbuild/meson/issues/7929 > > > > Seems to be a problem with meson-0.56.0, apparently will be fixed > > with 0.56.1 by > > https://github.com/mesonbuild/meson/commit/2b923f532c3e16687910fecb09cedb80a76597cf.diff > > but that didn't make any difference for me. > > Just to be sure: it is not enough to just patch meson and recompile > libsoup. Sysprof has to be recompiled to after the change to meson: the > problem is in the .pc file for sysprof (-pthread not present in the > "public" part of the .pc file). > Ah, I missed that (rebuilt meson, retried libsoup). But ... > I guess those of us who had built sysprof with a previous version of > meson could not see the problem, even if they were building libsoup > with meson 0.56... > > > > > I then tried Christopher's change to -Dsysprof=disabled and libsoup > > built. I agree with him that it shows no signs of downloading > > anything for sysprof. > > > > Meson reported: > > Dependency sysprof-capture-4 skipped: feature sysprof disabled > > and the verbose output from ninja did not mention sysprof. > > > > Pierre > With sysprof disabled (instead of auto, because I had a version of sysprof available, albeit a version with a defective .pc file) I see no indication from a verbose build of libsoup that anything to do with sysprof gets downloaded - ISTR there was mention of it installing a git version. ĸen -- Internal error in fortune program: fnum=2987 n=45 flag=1 goose_level=-232323 Please write down these values and notify fortune program admin. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] libsoup will not build with sysprof
On Fri, 2020-11-27 at 17:50 +, Ken Moffat via blfs-support wrote: > 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. > > > > 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. > > Starting a fresh sub-thread to reply to this, because we were > floundering. I've just hit this, and apart from Christopher's post > google found > https://github.com/mesonbuild/meson/issues/7929 > > Seems to be a problem with meson-0.56.0, apparently will be fixed > with 0.56.1 by > https://github.com/mesonbuild/meson/commit/2b923f532c3e16687910fecb09cedb80a76597cf.diff > but that didn't make any difference for me. Just to be sure: it is not enough to just patch meson and recompile libsoup. Sysprof has to be recompiled to after the change to meson: the problem is in the .pc file for sysprof (-pthread not present in the "public" part of the .pc file). I guess those of us who had built sysprof with a previous version of meson could not see the problem, even if they were building libsoup with meson 0.56... > > I then tried Christopher's change to -Dsysprof=disabled and libsoup > built. I agree with him that it shows no signs of downloading > anything for sysprof. > > Meson reported: > Dependency sysprof-capture-4 skipped: feature sysprof disabled > and the verbose output from ninja did not mention sysprof. > Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Kernel configuration observations/questions - BLFS 10.0/development
On Thu, Nov 26, 2020 at 04:58:17PM -0600, rhubarbpieguy--- via blfs-support wrote: Dear Mr Pie Guy (since I have no other way to call you), I'm afread such a long detailed post gets a long detailed reply. for some of the minor points I now think I agree with you, but for much of it I think the situation is more complex that what you are initially seeing (and that thought has developed during this reply, so what I say later is built upon, and developed from, my initial reply on autofs. Please read the whole reply before replying to any of it, otherwise I will have wasted 2½ hours. > > autofs > > File systems ---> > <*/M> Kernel automounter version 4 support (also supports v3) > [CONFIG_AUTOFS4_FS] > > I believe Kernel automounter support has no options. Should the above > lines be deleted? > As of 5.9.8 (I forget when it changed) CONFIG_AUTOFS_FS is the new option. In my case, on a fresh tarball it is selected by the old AUTOFS4_FS and it appears that it cannot be disabled or modularized. In the .config I'm using for this machine (updated for 5.9.1) # CONFIG_AUTOFS4_FS is not set CONFIG_AUTOFS_FS=y Looking back at the config for this machine, I have not always saved a new config for a new kernel version in my git tree. In this case, somewhere between 4.20.1 and 5.3.4 CONFIG_AUTOFS got enabled (unsure now if that was automatic or by my choice). Looking at my other machines, AUTOFS is enabled on all of them except for my desktop haswell (again, updated for 5.9.1) which has CONFIG_AUTOFS4_FS=m CONFIG_AUTOFS_FS=m So it looks as if AUTOFS (whether that or AUTOFS4 is the correct item to sepcify, I'm unsure - the 4 variant was supposed to be transitory, or for help in converting old configs - I think) can be a module. Not sure if it can be turned off nowadays (that would be nice, there is so much enabled in modern kernels which I don't need). > File systems ---> > [*] Network File Systems ---> [CONFIG_NETWORK_FILESYSTEMS] > <*/M> NFS client support > [CONFIG_NFS_FS] > <*/M> CIFS support (advanced network filesystem, SMBFS successor) > [CONFIG_CIFS] > > Should CIFS support (advanced network filesystem, SMBFS successor) be > SMB3 and CIFS support (advanced network filesystem)? I guess so. > -- > > > BlueZ > > [*] Networking support ---> [CONFIG_NET] > Bluetooth subsystem support ---> [CONFIG_BT] > > Is correct? Should it be ? <*/M>? > No idea. ISTR you have mentioned using bluetooth for input devices ? If so, can you build it in, and if so does it work better as built-in (e.g. easier pairing) or as a module (e.g. sometime need to rmmod and reload if it loses the connection) ? > <*/M> RF switch subsystem support ---> [CONFIG_RFKILL] > > Should RF switch subsystem support ---> be RF switch subsystem support > ? I don't understand, the words after 'Should' and 'be' look identical to me, maybe you didn't type what you intended ? > > [*] Networking support ---> [CONFIG_NET] > -*- Cryptographic API ---> [CONFIG_CRYPTO] > User-space interface for hash algorithms > [CONFIG_CRYPTO_USER_API_HASH] > User-space interface for symmetric key cipher algorithms > [CONFIG_CRYPTO_USER_API_SKCIPHER] > > I believe Cryptographic API has no options. Could [CONFIG_CRYPTO] be > deleted as in cryptsetup? > On 5.9.8 Cryptographic API has loads of options. Near the bottom are < > User-space interface for hash algorithms (NEW) < > User-space interface for symmetric key cipher algorithms (NEW) > As with the above, should the hash algorithms and key cipher lines be > ? <*/M>? > -- > > > lm-sensors > > [*] Enable loadable module support ---> [CONFIG_MODULES] > > Bus options (PCI etc.) ---> > [*] PCI support [CONFIG_PCI] > > Should Enable loadable module support and Bus options be reversed to > follow the order displayed with menuconfig? No idea. Where is MODULES found now ? I assume it is somewhere in General setup, but I can't see it and it seems to be enabled by default. According to the help (which might be out of date), PCI is somewhere under Device Drivers. > > Device Drivers ---> > I2C support ---> > <*/M> I2C device interface [CONFIG_I2C_CHARDEV] > I2C Hardware Bus support ---> > (configure all of them as modules) > <*/M> Hardware Monitoring support ---> [CONFIG_HWMON] > > I believe Hardware Monitoring support has no options. Should it be -*- > Hardware Monitoring Support? If so, could [CONFIG_HWMON] be deleted? Depends on your hardware for whether or not it gets selected: (From the help on a fresh 5.9.8 tree) Symbol: HWMON [=y] │ Type : tristate │ Defined at drive
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. > > 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. Starting a fresh sub-thread to reply to this, because we were floundering. I've just hit this, and apart from Christopher's post google found https://github.com/mesonbuild/meson/issues/7929 Seems to be a problem with meson-0.56.0, apparently will be fixed with 0.56.1 by https://github.com/mesonbuild/meson/commit/2b923f532c3e16687910fecb09cedb80a76597cf.diff but that didn't make any difference for me. I then tried Christopher's change to -Dsysprof=disabled and libsoup built. I agree with him that it shows no signs of downloading anything for sysprof. Meson reported: Dependency sysprof-capture-4 skipped: feature sysprof disabled and the verbose output from ninja did not mention sysprof. ĸen -- Internal error in fortune program: fnum=2987 n=45 flag=1 goose_level=-232323 Please write down these values and notify fortune program admin. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
