[Tntnet-general] error loading shared libraries

[c***@gmail.com]

I just downloaded cxxtools-2.2 and tntnet-2.2
I am using Ubuntu
I did ./configure, make and sudo make install for cxxtools ran into an
error on make for tntnet

tntnet/tntnet-2.2/sdk/tools/ecppc/.libs/lt-ecppc: error while loading
shared libraries: libcxxtools.so.9: cannot open shared object file: No such
file or directory

I noticed when repeating make install for cxxtools install
libcxxtools.so.9.0.0 and not libcxxtools.so.9
I am not sure how the naming and resolution for .so files work.

Can you send me in the right direction?

[Olaf Radicke]

Hi Anonymous!

Post by c***@gmail.com
I just downloaded cxxtools-2.2 and tntnet-2.2
I am using Ubuntu
I did ./configure, make and sudo make install for cxxtools ran into an
error on make for tntnet
tntnet/tntnet-2.2/sdk/tools/ecppc/.libs/lt-ecppc: error while loading
shared libraries: libcxxtools.so.9: cannot open shared object file: No such
file or directory
I noticed when repeating make install for cxxtools install
libcxxtools.so.9.0.0 and not libcxxtools.so.9
I am not sure how the naming and resolution for .so files work.
Can you send me in the right direction?

Do you have all ready configured the shared lib path? So do you have
added a file with name like /etc/ld.so.conf.d/tntdb.conf? And it is contained
your lib install path (like "/usr/local/lib/") and than, do you done the
command:
"ldconfig" after there?

Best regards

Olaf

[Oliver Rath]

The same issue happend to meva longer time ago, too. Wouldnt it be
sensefull to add the "ldconfig" to the "make install" script?

Regards,

Oliver

[Gerald Dachs]

Post by Oliver Rath
The same issue happend to meva longer time ago, too. Wouldnt it be
sensefull to add the "ldconfig" to the "make install" script?

I don't think so. Distributors use "make install" on the build host and
not on the target.
This would break the build on systems like lauchpad that builds
packages for Ubuntu,
because the build user has not the right to execute ldconfig.

Gerald

[c***@gmail.com]

I can't understand why tntnet requires some special ldconfig instead of
looking for includes and libs in the same place cxxtools does.
I tried the following:
cd $HOME/workspace/tntnet/cxxtools-2.2
./configure --prefix=$HOME/tntnet
make all install
cd $HOME/workspace/tntnet/tntnet-2.2
./configure --prefix=$HOME/tntnet
error: cxxtools headers not found

Post by Gerald Dachs

Post by Oliver Rath
The same issue happend to meva longer time ago, too. Wouldnt it be
sensefull to add the "ldconfig" to the "make install" script?

I don't think so. Distributors use "make install" on the build host and
not on the target.
This would break the build on systems like lauchpad that builds
packages for Ubuntu,
because the build user has not the right to execute ldconfig.
Gerald
------------------------------------------------------------------------------
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Tntnet-general mailing list
https://lists.sourceforge.net/lists/listinfo/tntnet-general

[Julian Wiesener]

Hi Corneil,

Post by c***@gmail.com
I can't understand why tntnet requires some special ldconfig instead of
looking for includes and libs in the same place cxxtools does.

and it doesnt, you'll need to set proper compiler/linker flags, the
following should work for you:

CPPFLAGS="-I$HOME/tntnet/include"
LDFLAGS="-L$HOME/tntnet/lib -Wl,-rpath=$HOME/tntnet/lib"
PATH="$HOME/tntnet/bin:$PATH"
export CPPFLAGS LDFLAGS PATH



Regards,
Julian

[c***@gmail.com]

The links are created as expected.
Running sudo ldconfig after make install resolved the problem.

Thanks Gerald

Hi,

This still doesn't explain why tntnet does not look for libcxxtools
where
it was installed with defaults i.e. no --prefix?

it did look for it, as configure and compile did not fail and thus it
found the headers. For some reason cxxtools 'make install' did not
create the symbolic links, which laed to a link error. Thats not common,
$ ls -la libcxxtools.so*
lrwxrwxrwx 1 jw users 20 Apr 12 00:15 libcxxtools.so ->
libcxxtools.so.9.0.0
lrwxrwxrwx 1 jw users 20 Apr 12 00:15 libcxxtools.so.9 ->
libcxxtools.so.9.0.0
-rwxr-xr-x 1 jw users 1754360 Apr 12 00:15 libcxxtools.so.9.0.0
I can't tell you why that did not happen on your system, but i suspect a
platform specifc libtool problem, it does work on most linux distros,
but apparently not on current ubuntu. You might look at
cxxtools-2.2/src/.libs there should be a libcxxtools.la, the library and
its symlinks.
# The name that we can dlopen(3).
dlname='libcxxtools.so.9'
# Names of this library.
library_names='libcxxtools.so.9.0.0 libcxxtools.so.9 libcxxtools.so'
Regards,
Julian

[Tommi Mäkitalo]

Hi,

thank you for all your help. Great that there are so good people on the
list, who are willing to help.

I wanted to add, that this can be found in the FAQ on the homepage but
just saw, that it can't. I thought I have added it, but somehow forgot.
I will do it now.

Tommi

Post by c***@gmail.com
The links are created as expected.
Running sudo ldconfig after make install resolved the problem.
Thanks Gerald
Hi,

This still doesn't explain why tntnet does not look for libcxxtools
where
it was installed with defaults i.e. no --prefix?

it did look for it, as configure and compile did not fail and thus it
found the headers. For some reason cxxtools 'make install' did not
create the symbolic links, which laed to a link error. Thats not common,
$ ls -la libcxxtools.so*
lrwxrwxrwx 1 jw users 20 Apr 12 00:15 libcxxtools.so ->
libcxxtools.so.9.0.0
lrwxrwxrwx 1 jw users 20 Apr 12 00:15 libcxxtools.so.9 ->
libcxxtools.so.9.0.0
-rwxr-xr-x 1 jw users 1754360 Apr 12 00:15 libcxxtools.so.9.0.0
I can't tell you why that did not happen on your system, but i suspect a
platform specifc libtool problem, it does work on most linux distros,
but apparently not on current ubuntu. You might look at
cxxtools-2.2/src/.libs there should be a libcxxtools.la
<http://libcxxtools.la>, the library and
its symlinks.
# The name that we can dlopen(3).
dlname='libcxxtools.so.9'
# Names of this library.
library_names='libcxxtools.so.9.0.0 libcxxtools.so.9 libcxxtools.so'
Regards,
Julian
------------------------------------------------------------------------------
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Tntnet-general mailing list
https://lists.sourceforge.net/lists/listinfo/tntnet-general

[Gerald Dachs]

Post by Tommi Mäkitalo
Hi,
thank you for all your help. Great that there are so good people on
the list, who are willing to help.
Hi,
thank you for all your help. Great that there are so good people on
the list, who are willing to help.

As a distributor it is in my own interest that the build doesn't break
in launchpad ;)

What makes me always wonder is that there is so little understanding
about what happens during compile and linking and during runtime. Even
under professionals. That was not always like this.

But what shall I expect from programmers that don't no make and have no
idea how to leave vi.

Of course I don't talk about you. It's only that I feel like a dinosaur.

Gerald


!DSPAM:52323a0b295431838048505!

[Olaf Radicke]

[...]

Post by Gerald Dachs
What makes me always wonder is that there is so little understanding
about what happens during compile and linking and during runtime. Even
under professionals. That was not always like this.
But what shall I expect from programmers that don't no make and have no
idea how to leave vi.

99.99% of user is never compile an application in his life. And 99.5%
of the web developer is programming with PHP, Ruby, Python, Perl, Java
and so on. And most using binary packets.

So the really interesting question is: How we can do this make easy
too install the latest version of TNT? Right? One way can be, is too
have a Build-Server how is generated in every night RPMs and DEBs.
Or we add a procedure in the Makefile and the user can generate self
RPMs or DEBs. By RPM install it can be a call for ldconfig set.

Best Regards

Olaf

[Gerald Dachs]

Post by Olaf Radicke
So the really interesting question is: How we can do this make easy
too install the latest version of TNT? Right?

No, that is not the question. It is already easy. Maybe you didn't
understand my explanation.
There is nothing complicated, or special with the installation of
tntnet. After you did "make install"
for installation of any software that installs shared libraries you
always have to call ldconfig.
It has always been like this. I suppose you normally install libraries
with the packaging system
of your distribution. Then this packaging system is doing it for you.
If you use apt-get for this task
it tells it even to you. That all means there is nothing to do. It is
just fine like it is now.

Post by Olaf Radicke
One way can be, is too
have a Build-Server how is generated in every night RPMs and DEBs.
Or we add a procedure in the Makefile and the user can generate self
RPMs or DEBs. By RPM install it can be a call for ldconfig set.

Of course is this a way. I do it just like this:
https://launchpad.net/~yavdr/+archive/main/+sourcepub/2021839/+listing-archive-extra
But generally this list is not the right place to ask for this. This is
the list of the tntnet developers, not the distributors.
A developer is very seldom a distributor. Tntnet is no exception to
this.

So ask the distributors of your distribution for a new tntnet package,
or provide it yourself using the services from launchpad or
https://build.opensuse.org/

If you don't want to do this, user ldconfig after "make install".

Gerald

[Tommi Mäkitalo]

Post by Olaf Radicke
[...]

Post by Gerald Dachs
What makes me always wonder is that there is so little understanding
about what happens during compile and linking and during runtime. Even
under professionals. That was not always like this.
But what shall I expect from programmers that don't no make and have no
idea how to leave vi.

99.99% of user is never compile an application in his life. And 99.5%
of the web developer is programming with PHP, Ruby, Python, Perl, Java
and so on. And most using binary packets.
So the really interesting question is: How we can do this make easy
too install the latest version of TNT? Right? One way can be, is too
have a Build-Server how is generated in every night RPMs and DEBs.
Or we add a procedure in the Makefile and the user can generate self
RPMs or DEBs. By RPM install it can be a call for ldconfig set.
Best Regards
Olaf

The easiest way to install tntnet is to use the repository. So we have
to take care to get tntnet into the repos. And tntnet is already at
least in debian, ubuntu, fedora and opensuse repositories. It can't be
easier than that.

One of the reasons I started using autotools is to make life easy for
the packagers. Packagers know autotools and if the see a package with a
configure script it is a no brainier to make a package out of it.

On the other hand, the 99.99% of the users (where do you have the number
from?), who never compile applications, are really not interested in
tntnet. We have to concentrate on the rest 0.01% users (btw. 0.01% of 6
billion people in the world are still 600.000 potential users;-) ).

Tommi

[unknown]

I cant understand why tntnet requires some special ldconfig instead
of
looking for includes and libs in the same place cxxtools does.

You are mixing build and installation. ldconfig has nothing to do with
the build.

The loader ld.so loads the shared libraries an executable needs. To
find this required library in the file system it looks into
/etc/ld.so.cache.
If a shared library is new, or it got a new version, then it is not in
the cache and the loader will not find it. ldconfig refreshes this
cache.

Gerald