[Vm-dev] Unexpected external library dependencies on linux

[David T. Lewis]

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