Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Linux starkit with included dynamic libraries does not work on Linux Mint 18.3

42 views
Skip to first unread message

Harald Oehlmann

unread,
Jun 8, 2018, 11:04:31 AM6/8/18
to
Dear Team,

a client uses:

Linux Mint 18.3 Sylvia
Linux version 4.10.0-40-generic (buildd@lcy01-amd64-005) (gcc version
5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5) ) #44~16.04.1-Ubuntu
SMP Thu Nov 9 15:37:44 UTC 2017

When I use a 64 bit starpack with contained libtls.so file, the "load
$dir/tls.so" failes, as it can not load the system libssl.so.

When the libtls is outside of the starkit (e.g. starpack_executable,
libtls folder), the load works.

On CentOS 6.5, the load works well when the dll is contained in the starkit.

The error message is:

couldn't load file "/tmp/tcl_4yyJct": libssl.so.10: cannot open shared
object file: No such file or directory> (::main::ModulesUnLoad)
> couldn't load file "/tmp/tcl_4yyJct": libssl.so.10: cannot open shared
object file: No such file or directory
> while executing
> "tls::initlib /home/me/test/mystarkit.exe/ilib_linux64/tls_linux64
libtls1.6.7.so"
> ("package ifneeded tls 1.6.7" script)
> invoked from within
> "package require tls"

In addition, to start the starkit, this does not work on Mint but on
Cent-OS 6.5:
bash > cd /home/me/test
bash > ./mystarkit.exe
Error: this is a folder
bash > /home/me/test/mystarkit.exe
-> starts the starkit.

Apparently, there are new security measurement on Mint Linux.

Any explication welcomed, just curious...

Thanks,
Harald

Rich

unread,
Jun 8, 2018, 11:41:50 AM6/8/18
to
Harald Oehlmann <wort...@yahoo.de> wrote:
> Dear Team,
>
> a client uses:
>
> Linux Mint 18.3 Sylvia
> Linux version 4.10.0-40-generic (buildd@lcy01-amd64-005) (gcc version
> 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5) ) #44~16.04.1-Ubuntu
> SMP Thu Nov 9 15:37:44 UTC 2017
>
> When I use a 64 bit starpack with contained libtls.so file, the "load
> $dir/tls.so" failes, as it can not load the system libssl.so.
>
> When the libtls is outside of the starkit (e.g. starpack_executable,
> libtls folder), the load works.
>
> On CentOS 6.5, the load works well when the dll is contained in the starkit.
>
> The error message is:
>
> couldn't load file "/tmp/tcl_4yyJct": libssl.so.10: cannot open shared
> object file: No such file or directory> (::main::ModulesUnLoad)
>> couldn't load file "/tmp/tcl_4yyJct": libssl.so.10: cannot open shared
> object file: No such file or directory
>> while executing
>> "tls::initlib /home/me/test/mystarkit.exe/ilib_linux64/tls_linux64
> libtls1.6.7.so"
>> ("package ifneeded tls 1.6.7" script)
>> invoked from within
>> "package require tls"
> ...
> Apparently, there are new security measurement on Mint Linux.
>
> Any explication welcomed, just curious...

It looks like the starkit contains libtls1.6.7.so, but the load fail
message is for libssl.so.10, so it looks like the Mint system is
lacking a dependent library that libtls requests be loaded.

Does Mint use openssl or a different ssl library? It might be that the
startkit for Mint needs a libtls that is compiled against whatever ssl
library Mint uses.

Robert Heller

unread,
Jun 8, 2018, 12:11:14 PM6/8/18
to
More likely, an incompatible or missing shared library under Mint/Ubuntu 16.04.

Do this:

Use sdx to extract the shared library ("sdx unwrap mystarkit.exe" will do that),
then do "ldd mystarkit.exe.vfs/ilib_linux64/tls_linux64/libtls1.6.7.so" --
this will list the shared libraries libtls1.6.7.so depends on. It is likely
you will get one (or more) missing or otherwise not compatible. I'm guessing
libssl.so.10, libcrypto.so.10, or libk5crypto.so.3 are likely. You might be
able to do something like install an older "compatible" version on your Mint
machine. Otherwise, you will have to fire up a Mint or Ubuntu 16.04 VM and
rebuild the library with whatever version(s) ship with Mint or Ubuntu 16.04.

You *might* be able to cheat and create a symlink for the version mismatch (eg
cd /usr/lib/.../; ln -s libssl.so.<mumble> libssl.so.10, etc.).

>
> Any explication welcomed, just curious...
>
> Thanks,
> Harald
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Robert Heller

unread,
Jun 8, 2018, 1:22:11 PM6/8/18
to
"apt-get install libssl1.0.0" might cure things. I think Mint 18/Ubuntu 16.04
is using libssl 1.1.x, where CentOS 6 is still on libssl 1.0.x. The Ubuntu
package libssl1.0.0 is the (older) libssl 1.0.x, which is available for
compatibility purposes (eg older software that has not be re-compiled with the
newer libssl yet).

undro...@gmail.com

unread,
Jun 8, 2018, 4:09:36 PM6/8/18
to
An alternate approach could be a runtime environment which tries to equalize platform variations, like (biased am I) undroidwish or vanillawish from www.androwish.org. The plan there is, to build things statically enough on an old, well known system to count on binary compatibility regarding the OS interfaces. In your case, a dependency on a specific version of an openssl shared library wouldn't exist, since the runtime environment has its libressl on board. For distributing software which has to support a broad spectrum of similar say Linuxen and for a longer term use of that software, this might be an almost stress free road for software development and support.

Harald Oehlmann

unread,
Jun 10, 2018, 10:50:00 AM6/10/18
to
Dear Christian, Rich and Robert,

thank you all for your valuable contributions to solve dependency on the
openssl package.
I was already in this hell with the Macintosh where Christian Gollwitzer
helped.

The point in this post was, that tcltls.so loads if outside of a
starkit, but not inside. E.G. the presence of the right library should
not be the issue. But I have to double-check...

I did not get the post of Christian Werner in depth. Well, that is
normal, Christian is very high level.
I refuse (up to now) to link openssl statically, as this breaks
security. Openssl is to critical... Christian Werner may convince me.
Christian Gollwitzer proposed the same thing on the MAC.

Thank you all,
Harald

Robert Heller

unread,
Jun 10, 2018, 2:59:20 PM6/10/18
to
At Sun, 10 Jun 2018 16:47:23 +0200 Harald Oehlmann <wort...@yahoo.de> wrote:

>
> Dear Christian, Rich and Robert,
>
> thank you all for your valuable contributions to solve dependency on the
> openssl package.
> I was already in this hell with the Macintosh where Christian Gollwitzer
> helped.
>
> The point in this post was, that tcltls.so loads if outside of a
> starkit, but not inside. E.G. the presence of the right library should
> not be the issue. But I have to double-check...

Does tcltls.so load outside of a starkit *on the Mint 18* system. The fact
that it works on the CentOS 6 system is immaterial. The error suggests that
the tcltls.so was linked with libssl.so.10 (OpenSSL 1.0.<mumble>), but Mint
18/Ubunti 16.04 ships with OpenSSL 1.1.<mumble> (libssl.so.11). This means
you have three options:

1) Install the (older) OpenSSL 1.0.<mumble> library on the Mint 18.
2) Build tcltls.so *statically* with OpenSSL 1.0.<mumble>
3) Rebuild tcltls.so on Ubunti 16.04 for use with Mint 18.

>
> I did not get the post of Christian Werner in depth. Well, that is
> normal, Christian is very high level.
> I refuse (up to now) to link openssl statically, as this breaks
> security. Openssl is to critical... Christian Werner may convince me.
> Christian Gollwitzer proposed the same thing on the MAC.
>
> Thank you all,
> Harald
>

0 new messages