Unexpected external library dependencies on linux
Locked
Unexpected external library dependencies on linux
 
|
Hi All, I tried to upgrade a VM on a server, and found that recently built VMs on bintray have extra dependencies. The original VM from 2019 (sqlinux.2019030800022) depends on the following according to ldd: linux-vdso.so.1 libdl.so.2 libm.so.6 libpthread.so.0 libc.so.6 /lib64/ld-linux-x86-64.so.2 All dependencies are available on the server. However, recent VMs (202003050026 from March, 202004160240 from April) also depend on the following: libuuid.so.1 libutil.so.1 libpulse-simple.so.0 libasound.so.2 The last two are the most worrying as servers usually don't need or have sound installed. So, without pulseaudio installed, these VMs won't start. Does anyone know how and why those new dependencies got there? (These are the dependencies of the VM binary itself not dependencies of external plugins). Levente |
Re: Unexpected external library dependencies on linux
|
|
On Thu, Apr 16, 2020 at 06:53:51PM +0200, Levente Uzonyi wrote: > > Hi All, > > I tried to upgrade a VM on a server, and found that recently built VMs on > bintray have extra dependencies. > The original VM from 2019 (sqlinux.2019030800022) depends on the following > according to ldd: > > linux-vdso.so.1 > libdl.so.2 > libm.so.6 > libpthread.so.0 > libc.so.6 > /lib64/ld-linux-x86-64.so.2 > > All dependencies are available on the server. > However, recent VMs (202003050026 from March, 202004160240 from April) > also depend on the following: > > libuuid.so.1 > libutil.so.1 > libpulse-simple.so.0 > libasound.so.2 > > The last two are the most worrying as servers usually don't need or have > sound installed. So, without pulseaudio installed, these VMs won't start. > Does anyone know how and why those new dependencies got there? > > (These are the dependencies of the VM binary itself not dependencies of > external plugins). Hi Levente, I don't know the answer to your question, but the sound dependencies are likely associated with the VM plugin modules vm-sound-*.so as opposed to any of the conventional VM plugins such as UUIDPlugin.so. It is quite likely that specifying the -vm-sound-null parameter to the VM will bypass any problems. Otherwise, deleting the offending vm-sound-* modules should be harmless. Dave |
Re: Unexpected external library dependencies on linux
|
|
> On 2020-04-16, at 2:42 PM, David T. Lewis <[hidden email]> wrote: > > > On Thu, Apr 16, 2020 at 06:53:51PM +0200, Levente Uzonyi wrote: >> >> However, recent VMs (202003050026 from March, 202004160240 from April) >> also depend on the following: >> >> libuuid.so.1 >> libutil.so.1 >> libpulse-simple.so.0 >> libasound.so.2 >> >> The last two are the most worrying as servers usually don't need or have >> sound installed. So, without pulseaudio installed, these VMs won't start. >> Does anyone know how and why those new dependencies got there? >> >> (These are the dependencies of the VM binary itself not dependencies of >> external plugins). > > Hi Levente, > > I don't know the answer to your question, but the sound dependencies are > likely associated with the VM plugin modules vm-sound-*.so as opposed to > any of the conventional VM plugins such as UUIDPlugin.so. It is quite > likely that specifying the -vm-sound-null parameter to the VM will bypass > any problems. Otherwise, deleting the offending vm-sound-* modules should > be harmless. Is it possible some edit to the build files made the pulse audio stuff a default (this was discussed recently) and set it to link to the VM instead of the (expected to be) separate vm-sound-* module? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: CSD: Charge Surreptitiously to DOE |
Re: Unexpected external library dependencies on linux
|
|
On Thu, Apr 16, 2020 at 02:55:46PM -0700, tim Rowledge wrote: > > > On 2020-04-16, at 2:42 PM, David T. Lewis <[hidden email]> wrote: > > > > > > On Thu, Apr 16, 2020 at 06:53:51PM +0200, Levente Uzonyi wrote: > >> > >> However, recent VMs (202003050026 from March, 202004160240 from April) > >> also depend on the following: > >> > >> libuuid.so.1 > >> libutil.so.1 > >> libpulse-simple.so.0 > >> libasound.so.2 > >> > >> The last two are the most worrying as servers usually don't need or have > >> sound installed. So, without pulseaudio installed, these VMs won't start. > >> Does anyone know how and why those new dependencies got there? > >> > >> (These are the dependencies of the VM binary itself not dependencies of > >> external plugins). > > > > Hi Levente, > > > > I don't know the answer to your question, but the sound dependencies are > > likely associated with the VM plugin modules vm-sound-*.so as opposed to > > any of the conventional VM plugins such as UUIDPlugin.so. It is quite > > likely that specifying the -vm-sound-null parameter to the VM will bypass > > any problems. Otherwise, deleting the offending vm-sound-* modules should > > be harmless. > > Is it possible some edit to the build files made the pulse audio stuff > a default (this was discussed recently) and set it to link to the VM > instead of the (expected to be) separate vm-sound-* module? > Pulse audio /is/ one of the vm-sound-* modules, so the idea there was just to put it first in the search list because that's what makes sense on most Linux platforms today. But I see now that Levente was asking about library dependencies in the actual VM executable itself (which you can see with "$ ldd squeak" in the libarary directory with the VM and plugins). It has dependencies on the pulse audio and alsa sound libraries. That makes no sense at all, and I don't know the reason for it. I also see that the plugins have lots of unnecessary dependencies. For example, the UUID plugin depends on pulse audio and alsa sound libraries, which is obviously not right. Dave |
Re: Unexpected external library dependencies on linux
|
|
> On 17.04.2020, at 01:28, David T. Lewis <[hidden email]> wrote: > > > On Thu, Apr 16, 2020 at 02:55:46PM -0700, tim Rowledge wrote: >> >>> On 2020-04-16, at 2:42 PM, David T. Lewis <[hidden email]> wrote: >>> >>> >>> On Thu, Apr 16, 2020 at 06:53:51PM +0200, Levente Uzonyi wrote: >>>> >>>> However, recent VMs (202003050026 from March, 202004160240 from April) >>>> also depend on the following: >>>> >>>> libuuid.so.1 >>>> libutil.so.1 >>>> libpulse-simple.so.0 >>>> libasound.so.2 >>>> >>>> The last two are the most worrying as servers usually don't need or have >>>> sound installed. So, without pulseaudio installed, these VMs won't start. >>>> Does anyone know how and why those new dependencies got there? >>>> >>>> (These are the dependencies of the VM binary itself not dependencies of >>>> external plugins). >>> >>> Hi Levente, >>> >>> I don't know the answer to your question, but the sound dependencies are >>> likely associated with the VM plugin modules vm-sound-*.so as opposed to >>> any of the conventional VM plugins such as UUIDPlugin.so. It is quite >>> likely that specifying the -vm-sound-null parameter to the VM will bypass >>> any problems. Otherwise, deleting the offending vm-sound-* modules should >>> be harmless. >> >> Is it possible some edit to the build files made the pulse audio stuff >> a default (this was discussed recently) and set it to link to the VM >> instead of the (expected to be) separate vm-sound-* module? >> > > Pulse audio /is/ one of the vm-sound-* modules, so the idea there was > just to put it first in the search list because that's what makes sense on > most Linux platforms today. > > But I see now that Levente was asking about library dependencies in the > actual VM executable itself (which you can see with "$ ldd squeak" in the > libarary directory with the VM and plugins). It has dependencies on the > pulse audio and alsa sound libraries. That makes no sense at all, and I > don't know the reason for it. > > I also see that the plugins have lots of unnecessary dependencies. For > example, the UUID plugin depends on pulse audio and alsa sound libraries, > which is obviously not right. There might be a problem with the way the linker flags are being collected. Namely, that they're built up while configuring the individual plugins but then used throughout the entire process. That bit me for some other flags on FreeBSD. Unser Bausystem ist Mist ;) Best regards -Tobias |
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've noticed in the Solaris build the following issue. Squeak V5 64bit (built with autoconf "configure" configuration) in directory /usr/lib/squeak/5.0-202004101155-solaris bash-4.4$ ldd SqueakSSL.so | grep ssl bash-4.4$ ldd squeak | grep ssl libssl.so.1.0.0 => /lib/64/libssl.so.1.0.0 Squeak V4 32bit (built with "cmake" configuration) in directory /usr/lib/squeak/4.16.7-3775 bash-4.4$ ldd squeakvm | grep ssl bash-4.4$ ldd so.SqueakSSL | grep ssl libssl.so.1.0.0 => /lib/libssl.so.1.0.0 So in Squeak V4 the squeak binary has no dependency on ssl while in Squeak V5 the squeak binary does ... And for the modules it is the other way around. I would say that the Squeak V4 configuration is "most likely" the right one. However this is just an observation in the Solaris case, which could be Solaris specific side effects of linker flags wrong on the Solaris binaries compilation ... David. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJemVTXAAoJEAwpOKXMq1Mad20H/iqXe1CSlHLjBv41V0QK9/RU juTg6o1TSks02fJDayXX08J1FoPne0w7Gadnq08Mdhf+ZBGeY1qa7yCFhBLhzyHf BXy5SntX0iNLQxANus9Dp12cmeqnSQOnA1ajb/K+ELfe6InmbTJekMFoK0GNfpqw RdBUmyBKULzCzl5/l6GljD+C7k0lsRCy0kOpqam/Q5WMAiFFEABirf2spvyDlsbs zCTR+nkeDW5/QprSWLQfzVLtjMhG5nGgepesjltG7ccjxdwpBbnxeUFYqdc6LwwX mqoOXk3bKAoFEoscYi3UQuiaZp4xtR+s3pOWlItW8gyr2v0FHjDlXUNkyRtmCp0= =Nb/T -----END PGP SIGNATURE----- -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
Re: Unexpected external library dependencies on linux
|
|
In reply to this post by Tobias Pape
Hi Tobias, On Fri, 17 Apr 2020, Tobias Pape wrote: > > >> On 17.04.2020, at 01:28, David T. Lewis <[hidden email]> wrote: >> >> >> On Thu, Apr 16, 2020 at 02:55:46PM -0700, tim Rowledge wrote: >>> >>>> On 2020-04-16, at 2:42 PM, David T. Lewis <[hidden email]> wrote: >>>> >>>> >>>> On Thu, Apr 16, 2020 at 06:53:51PM +0200, Levente Uzonyi wrote: >>>>> >>>>> However, recent VMs (202003050026 from March, 202004160240 from April) >>>>> also depend on the following: >>>>> >>>>> libuuid.so.1 >>>>> libutil.so.1 >>>>> libpulse-simple.so.0 >>>>> libasound.so.2 >>>>> >>>>> The last two are the most worrying as servers usually don't need or have >>>>> sound installed. So, without pulseaudio installed, these VMs won't start. >>>>> Does anyone know how and why those new dependencies got there? >>>>> >>>>> (These are the dependencies of the VM binary itself not dependencies of >>>>> external plugins). >>>> >>>> Hi Levente, >>>> >>>> I don't know the answer to your question, but the sound dependencies are >>>> likely associated with the VM plugin modules vm-sound-*.so as opposed to >>>> any of the conventional VM plugins such as UUIDPlugin.so. It is quite >>>> likely that specifying the -vm-sound-null parameter to the VM will bypass >>>> any problems. Otherwise, deleting the offending vm-sound-* modules should >>>> be harmless. >>> >>> Is it possible some edit to the build files made the pulse audio stuff >>> a default (this was discussed recently) and set it to link to the VM >>> instead of the (expected to be) separate vm-sound-* module? >>> >> >> Pulse audio /is/ one of the vm-sound-* modules, so the idea there was >> just to put it first in the search list because that's what makes sense on >> most Linux platforms today. >> >> But I see now that Levente was asking about library dependencies in the >> actual VM executable itself (which you can see with "$ ldd squeak" in the >> libarary directory with the VM and plugins). It has dependencies on the >> pulse audio and alsa sound libraries. That makes no sense at all, and I >> don't know the reason for it. >> >> I also see that the plugins have lots of unnecessary dependencies. For >> example, the UUID plugin depends on pulse audio and alsa sound libraries, >> which is obviously not right. > > > There might be a problem with the way the linker flags are being collected. > Namely, that they're built up while configuring the individual plugins but > then used throughout the entire process. That bit me for some other flags > on FreeBSD. Just checked what library flags are passed when the VM binary is linked, and they are: -ldl -lutil -lpulse-simple -lasound -ldl -lm So, you're right, the flags are wrong. Levente > > Unser Bausystem ist Mist ;) > > Best regards > -Tobias |
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Regarding the SSL I should add that 1) I built the vm V5 using --disable-dynamicopenssl 2) both configurations vm V4 and vm V5 work They work because in Squeak V4 and V5 I can send a message like : SqueakSSL google:'squeak' and this works in both Squeak V4 and Squeak V5. But I think the Squeak V4 executable which has no "ldd" dependency on libssl is more logical; it is strange that the V5 executable has bash-4.4$ ldd squeak | grep ssl libssl.so.1.0.0 => /lib/64/libssl.so.1.0.0 which is different in V4. Also for other libraries similar oddities : in V5 bash-4.4$ ldd squeak | grep uuid libuuid.so.1 => /lib/64/libuuid.so.1 while in V4 bash-4.4$ ldd squeakvm | grep uuid in the Squeak V4 (which is built with 'cmake') the only uuid reference is in the module itself. bash-4.4$ ldd so.UUIDPlugin libuuid.so.1 => /lib/libuuid.so.1 DAvid. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJemazOAAoJEAwpOKXMq1Ma3N0IAI/+SRL9MESflw+Fg4TmaFgl IKLQSxEasqeN0FT7sMi/Zxp6xV0doztE3JiGUJxw2nUu60HnDJTX8GHziiiASQ+m +TzAiTcwvqcGUYZ0z+t0VSLsvU7/DIXo/3UgMD7BNdY1fanrDV3GNYcZwIfJ0Ydq qTbYaXidhxM9XFOwNaYgqIqFfLi2+DbvWMWg7OD3SvzsXSbCKezM6iJZ98CkoQdL uMMq+d9bokYQKy4d1R3w2ggGVBrHzDtvpZnptDaazc68pHLTt5g/E7W8mG4woNJB LYi7W4d5yrdvMFKI3Y4mqAr/HCPaQ0/3X+d9RLxyKRVAMkQbZ/5ltslZZ79O2PY= =9xmv -----END PGP SIGNATURE----- -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
Re: Unexpected external library dependencies on linux
|
|
On Fri, Apr 17, 2020 at 08:21:28AM -0500, stes wrote: > > Regarding the SSL I should add that > > 1) I built the vm V5 using --disable-dynamicopenssl > 2) both configurations vm V4 and vm V5 work > > They work because in Squeak V4 and V5 I can send a message like : > > SqueakSSL google:'squeak' > > and this works in both Squeak V4 and Squeak V5. > > But I think the Squeak V4 executable which has no "ldd" > dependency on libssl is more logical; it is strange that the V5 > executable has > > bash-4.4$ ldd squeak | grep ssl > libssl.so.1.0.0 => /lib/64/libssl.so.1.0.0 > > which is different in V4. > > Also for other libraries similar oddities : > > in V5 > bash-4.4$ ldd squeak | grep uuid > libuuid.so.1 => /lib/64/libuuid.so.1 > > while in V4 > > bash-4.4$ ldd squeakvm | grep uuid > > > in the Squeak V4 (which is built with 'cmake') the only uuid reference > is in the module itself. > > bash-4.4$ ldd so.UUIDPlugin > libuuid.so.1 => /lib/libuuid.so.1 > For the traditional VM, Ian Piumarta implemented a different build system that solved a lot of issues like this. At the time, things were quite messy as Linux systems were transitioning from 32-bit to 64-bit and the library configuration. The oscog branch on which all of the modern VMs are based was forked from the squeakvm.org trunk a couple of years before that time (IIRC), and does not use Ian's replacement build system. BTW, you could make a good argument for either approach. The Cmake based system is reliable and trouble free, but it does introduce a dependency on the Cmake system, which could get to be a problem if its corporate sponsor ever went out of business. Dave |
Re: Unexpected external library dependencies on linux
|
|
In reply to this post by Levente Uzonyi
I just checked the binaries on bintray. The last good version is 201909292337 (even though it has no plugins), the next one, which is broken, is 201910302214. I checked commits between those dates and the only suspicious one was the gcc to clang change. I compiled a VM on my machine with clang and one with gcc (by uncommenting the CC=clang line in mvm), and found that clang causes the dependency problems. The gcc version has the correct dependencies, the clang one has all the extra dependencies. I also noticed that the fixes I made[1] to the CryptographyPlugins have not been applied. The code in the repository was still generated from an old version of the package (CryptographyPlugins-eem.14). And the plugins I asked to be included[2] have not been added. Levente [1] http://squeaksource.com/Cryptography/CryptographyPlugins-ul.22.mcz [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2020-March/033114.html On Fri, 17 Apr 2020, Levente Uzonyi wrote: > > Hi Tobias, > > On Fri, 17 Apr 2020, Tobias Pape wrote: > >> >> >>> On 17.04.2020, at 01:28, David T. Lewis <[hidden email]> wrote: >>> >>> >>> On Thu, Apr 16, 2020 at 02:55:46PM -0700, tim Rowledge wrote: >>>> >>>>> On 2020-04-16, at 2:42 PM, David T. Lewis <[hidden email]> wrote: >>>>> >>>>> >>>>> On Thu, Apr 16, 2020 at 06:53:51PM +0200, Levente Uzonyi wrote: >>>>>> >>>>>> However, recent VMs (202003050026 from March, 202004160240 from April) >>>>>> also depend on the following: >>>>>> >>>>>> libuuid.so.1 >>>>>> libutil.so.1 >>>>>> libpulse-simple.so.0 >>>>>> libasound.so.2 >>>>>> >>>>>> The last two are the most worrying as servers usually don't need or > have >>>>>> sound installed. So, without pulseaudio installed, these VMs won't > start. >>>>>> Does anyone know how and why those new dependencies got there? >>>>>> >>>>>> (These are the dependencies of the VM binary itself not dependencies of >>>>>> external plugins). >>>>> >>>>> Hi Levente, >>>>> >>>>> I don't know the answer to your question, but the sound dependencies are >>>>> likely associated with the VM plugin modules vm-sound-*.so as opposed to >>>>> any of the conventional VM plugins such as UUIDPlugin.so. It is quite >>>>> likely that specifying the -vm-sound-null parameter to the VM will > bypass >>>>> any problems. Otherwise, deleting the offending vm-sound-* modules > should >>>>> be harmless. >>>> >>>> Is it possible some edit to the build files made the pulse audio stuff >>>> a default (this was discussed recently) and set it to link to the VM >>>> instead of the (expected to be) separate vm-sound-* module? >>>> >>> >>> Pulse audio /is/ one of the vm-sound-* modules, so the idea there was >>> just to put it first in the search list because that's what makes sense on >>> most Linux platforms today. >>> >>> But I see now that Levente was asking about library dependencies in the >>> actual VM executable itself (which you can see with "$ ldd squeak" in the >>> libarary directory with the VM and plugins). It has dependencies on the >>> pulse audio and alsa sound libraries. That makes no sense at all, and I >>> don't know the reason for it. >>> >>> I also see that the plugins have lots of unnecessary dependencies. For >>> example, the UUID plugin depends on pulse audio and alsa sound libraries, >>> which is obviously not right. >> >> >> There might be a problem with the way the linker flags are being collected. >> Namely, that they're built up while configuring the individual plugins but >> then used throughout the entire process. That bit me for some other flags >> on FreeBSD. > > Just checked what library flags are passed when the VM binary is linked, > and they are: -ldl -lutil -lpulse-simple -lasound -ldl -lm > So, you're right, the flags are wrong. > > > Levente > >> >> Unser Bausystem ist Mist ;) >> >> Best regards >> -Tobias > |
Re: Unexpected external library dependencies on linux
|
|
Le mer. 22 avr. 2020 à 15:31, Levente Uzonyi <[hidden email]> a écrit :
Hi Levente, Tthat's unfortunate... Stupid guess: could it be related to the fact that we want to export all symbols? Anyway, that means that those .so appeared on the command line when they shouldn't. We might be able to fix the makefiles... Hmm thru configure, that ain't gonna be easy (not my cup of tea). I also noticed that the fixes I made[1] to the CryptographyPlugins have not |
Re: Unexpected external library dependencies on linux
|
|
Hi Nicolas On Wed, 22 Apr 2020, Nicolas Cellier wrote: > Hi Levente, > Tthat's unfortunate... > Stupid guess: could it be related to the fact that we want to export all symbols? > Anyway, that means that those .so appeared on the command line when they shouldn't. > We might be able to fix the makefiles... Hmm thru configure, that ain't gonna be easy (not my cup of tea). I just checked what libraries are passed to the build command when building the VM binary. It's independent of the CC flag, so it's the same with both gcc and clang: -ldl -lutil -lpulse-simple -lasound -ldl -lm. I suspect that gcc is able to detect unused dependencies but clang is not. Here's what ldd says when clang is used: $ ldd -u squeak Unused direct dependencies: /lib/x86_64-linux-gnu/libutil.so.1 /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 /usr/lib/x86_64-linux-gnu/libasound.so.2 $ ldd -u SHA2Plugin/.libs/SHA2Plugin.so Unused direct dependencies: /lib/x86_64-linux-gnu/libpthread.so.0 However, both outputs are empty with gcc. I couldn't find any clang flags to fix this, so I'm afraid the only solution is to make autoconf generate proper dependencies because that seems to be the actual bug here but it was hidden by gcc. Levente |
Re: Unexpected external library dependencies on linux
|
|
Hi > On 22.04.2020, at 22:42, Levente Uzonyi <[hidden email]> wrote: > > Hi Nicolas > > On Wed, 22 Apr 2020, Nicolas Cellier wrote: > >> Hi Levente, >> Tthat's unfortunate... >> Stupid guess: could it be related to the fact that we want to export all symbols? >> Anyway, that means that those .so appeared on the command line when they shouldn't. >> We might be able to fix the makefiles... Hmm thru configure, that ain't gonna be easy (not my cup of tea). > > I just checked what libraries are passed to the build command when building the VM binary. It's independent of the CC flag, so it's the same with both gcc and clang: > -ldl -lutil -lpulse-simple -lasound -ldl -lm. > I suspect that gcc is able to detect unused dependencies but clang is not. > > Here's what ldd says when clang is used: > > $ ldd -u squeak > Unused direct dependencies: > /lib/x86_64-linux-gnu/libutil.so.1 > /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 > /usr/lib/x86_64-linux-gnu/libasound.so.2 > > $ ldd -u SHA2Plugin/.libs/SHA2Plugin.so > Unused direct dependencies: > /lib/x86_64-linux-gnu/libpthread.so.0 > > However, both outputs are empty with gcc. > > I couldn't find any clang flags to fix this, so I'm afraid the only solution is to make autoconf generate proper dependencies because that seems to be the actual bug here but it was hidden by gcc. I think I found the culprit: 1. AC_SEARCH_LIBS(function, libraries-list, action-if-found, action-if-not-found, extra-libraries) 2. "In this instance, each will be called at most once, and the default action-if-found code, adding the library to the LIBS variables, is always executed, even if a parameter is passed." (https://autotools.io/autoconf/finding.html) 3. platform/unix/config/acinclude.m4 -------------%<-------------- AC_DEFUN([AC_PLUGIN_SEARCH_LIBS],[ AC_SEARCH_LIBS($1,$2,, AC_MSG_RESULT([******** disabling ${plugin} due to missing libraries]) disabled_plugins="${disabled_plugins} ${plugin}")]) ------------->&-------------- 4. platform/unix/vm-sound-ALSA/acinclude.m4 AC_PLUGIN_SEARCH_LIBS([snd_pcm_open],[asound]) platform/unix/vm-sound-pulse/acinclude.m4 AC_PLUGIN_SEARCH_LIBS([pa_simple_new],[pulse-simple pulse]) 5. % git blame vm-sound-ALSA/acinclude.m4 ba0f02c8f6 (Eliot Miranda 2010-06-26 05:12:25 +0000 1) # -*- sh -*- ba0f02c8f6 (Eliot Miranda 2010-06-26 05:12:25 +0000 2) 696b4ebd01 (Tobias Pape 2018-03-05 16:41:11 +0100 3) ba0f02c8f6 (Eliot Miranda 2010-06-26 05:12:25 +0000 4) AC_MSG_CHECKING([for Advanced Linux Sound Architecture]) 696b4ebd01 (Tobias Pape 2018-03-05 16:41:11 +0100 5) AC_CHECK_HEADERS(alsa/asoundlib.h,,AC_PLUGIN_DISABLE) 696b4ebd01 (Tobias Pape 2018-03-05 16:41:11 +0100 6) AC_PLUGIN_SEARCH_LIBS([snd_pcm_open],[asound] -=-=-=-=-=-=-=- Fixed in https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/491 Best regards -Tobias |
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The file platforms/unix/vm-sound-OSS/acinclude.m4 has an interesting option or flag: AC_ARG_WITH([vm-sound-OSS], AS_HELP_STRING([--without-vm-sound-OSS], [disable OSS vm sound support (default=enabled)]), [with_vm_sound_OSS="$withval"], [with_vm_sound_OSS="yes"]) if test "$with_vm_sound_OSS" = "no"; then AC_PLUGIN_DISABLE_PLUGIN(vm-sound-OSS); else ... fi So for vm-sound-OSS it is possible to use configure --without-vm-sound-OSS. Unfortunately it seems that the other vm-sound directories do not have this. Would it be an option to add a AC_PLUGIN_DISABLE_PLUGIN(vm-sound-pulse); AC_PLUGIN_DISABLE_PLUGIN(vm-sound-Sun); AC_PLUGIN_DISABLE_PLUGIN(vm-sound-ALSA); etc. options similar like the one for vm-sound-OSS but then for ALSA,pulse,Sun? This could be useful because then it would be possible to configure configure --without-vm-sound-ALSA for example, just as it is possible nowadays to do this --without-vm-sound-OSS. David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJeoS3tAAoJEAwpOKXMq1MaKEgH/3gnQvvvrNnc/Ol8Bt2syF7q 34dipq7hVdGNBvVA7uywNt0e743Ek+VbGpH9jBovUXf3Vctk/93o1tsDP/63YlX1 WOzsco8I64zsZvJK7Un2SWRToJRyUufPzbQGC0yA/YAPLw1Dlo4Z1nYEoVLr+koE VEFOJvqJAvhrEd46UixqNE3a53oy5X2QqaJlYcdiOHvRpDBj01D2OjJt20nt3Tjd cQAUGElxWUS/UQ9YlqIr/UJIiyo/IQTmxR1kj9JNFBh6qYkSt8uNuxcQR7imJjVx DeS6SqwlcRorI0NlTqgvrckKXNPs+DLlYnSkql4PoMh324mjOdSlBPYHoKNI0aE= =44PD -----END PGP SIGNATURE----- -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
Re: Unexpected external library dependencies on linux
|
|
In reply to this post by Tobias Pape
On Thu, 23 Apr 2020, Tobias Pape wrote: > > Hi > >> On 22.04.2020, at 22:42, Levente Uzonyi <[hidden email]> wrote: >> >> Hi Nicolas >> >> On Wed, 22 Apr 2020, Nicolas Cellier wrote: >> >>> Hi Levente, >>> Tthat's unfortunate... >>> Stupid guess: could it be related to the fact that we want to export all symbols? >>> Anyway, that means that those .so appeared on the command line when they shouldn't. >>> We might be able to fix the makefiles... Hmm thru configure, that ain't gonna be easy (not my cup of tea). >> >> I just checked what libraries are passed to the build command when building the VM binary. It's independent of the CC flag, so it's the same with both gcc and clang: >> -ldl -lutil -lpulse-simple -lasound -ldl -lm. >> I suspect that gcc is able to detect unused dependencies but clang is not. >> >> Here's what ldd says when clang is used: >> >> $ ldd -u squeak >> Unused direct dependencies: >> /lib/x86_64-linux-gnu/libutil.so.1 >> /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 >> /usr/lib/x86_64-linux-gnu/libasound.so.2 >> >> $ ldd -u SHA2Plugin/.libs/SHA2Plugin.so >> Unused direct dependencies: >> /lib/x86_64-linux-gnu/libpthread.so.0 >> >> However, both outputs are empty with gcc. >> >> I couldn't find any clang flags to fix this, so I'm afraid the only solution is to make autoconf generate proper dependencies because that seems to be the actual bug here but it was hidden by gcc. > > I think I found the culprit: > > 1. AC_SEARCH_LIBS(function, libraries-list, action-if-found, action-if-not-found, extra-libraries) > 2. "In this instance, each will be called at most once, and the default action-if-found code, adding the library to the LIBS variables, is always executed, even if a parameter is passed." (https://autotools.io/autoconf/finding.html) > > 3. platform/unix/config/acinclude.m4 > -------------%<-------------- > AC_DEFUN([AC_PLUGIN_SEARCH_LIBS],[ > AC_SEARCH_LIBS($1,$2,, > AC_MSG_RESULT([******** disabling ${plugin} due to missing libraries]) > disabled_plugins="${disabled_plugins} ${plugin}")]) > > ------------->&-------------- > > 4. > platform/unix/vm-sound-ALSA/acinclude.m4 > AC_PLUGIN_SEARCH_LIBS([snd_pcm_open],[asound]) > platform/unix/vm-sound-pulse/acinclude.m4 > AC_PLUGIN_SEARCH_LIBS([pa_simple_new],[pulse-simple pulse]) > > 5. % git blame vm-sound-ALSA/acinclude.m4 > ba0f02c8f6 (Eliot Miranda 2010-06-26 05:12:25 +0000 1) # -*- sh -*- > ba0f02c8f6 (Eliot Miranda 2010-06-26 05:12:25 +0000 2) > 696b4ebd01 (Tobias Pape 2018-03-05 16:41:11 +0100 3) > ba0f02c8f6 (Eliot Miranda 2010-06-26 05:12:25 +0000 4) AC_MSG_CHECKING([for Advanced Linux Sound Architecture]) > 696b4ebd01 (Tobias Pape 2018-03-05 16:41:11 +0100 5) AC_CHECK_HEADERS(alsa/asoundlib.h,,AC_PLUGIN_DISABLE) > 696b4ebd01 (Tobias Pape 2018-03-05 16:41:11 +0100 6) AC_PLUGIN_SEARCH_LIBS([snd_pcm_open],[asound] > > > -=-=-=-=-=-=-=- > > Fixed in https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/491 Awesome, thanks! I can confirm that the sound-related unexpected dependencies are gone. Only libutil, libuuid for the VM, and libpthread for the plugins reamain. Levente > > Best regards > -Tobias |
Re: Unexpected external library dependencies on linux
|
|
> On 23.04.2020, at 15:55, Levente Uzonyi <[hidden email]> wrote: > > On Thu, 23 Apr 2020, Tobias Pape wrote: > >> Hi >> […] >> >> Fixed in https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/491 > > Awesome, thanks! welcome :) > I can confirm that the sound-related unexpected dependencies are gone. Only libutil, libuuid for the VM, and libpthread for the plugins reamain. Great! Best regards -Tobias |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |