Update libstdc++ library on another system

mazel · 07-31-2012, 09:06 AM

Hello all,

I have 2 drives in one PC with debian OS each. First provides wide range of tools for development and work (including make, cmake, dev IDEs, apt-get, dpkg etc.). Second one is realy limited port of the first one (without make, cmake apt-get, dpkg, IDEs, g++, gcc ... etc.) Architecture of both systems are identical (same hw .. in fact the dev system is connected to the destination machine)

Because I had to update libstdc++ on dev (first) system, due to the requirements of the application Im develooping, there is no longer possible to run the application on the second (simple linux) system.

Static linking of libraries including libstdc++ seems to be usless (already tried)..

I dont see any other way out, than update the libstdc++ on the second system ... but on this system is not anything that should make it possible (make, apt-get, dpkg, g++, gcc..)

- another think is that this action may affect another already installed applications (hope not, if it is upgrade to higher version :/)

Is it possible to workaround this somehow from the first system with the second system mounted as a drive?

Thank you for any advice ...

Reuti · 07-31-2012, 12:25 PM

Isn’t it possible to install both as they are named libstdc++.so.5 and libstdc++.so.6, i.e. just copy it to the other system and you have both in place?

mazel · 08-01-2012, 01:33 AM

That was maybe my first quess to just copy the library and edit symlink, but unfortunatelly it seems that there are some dependencies or other libraries that has to be resolved as well... so now Im looking for any solution (Including copying files) ... only one that is comming to my mind now is use the dev system to install standard c++ library to another drive, but I think I dont have enough experiences to figure it out somehow by myself ...

Does anybody know if the --prefix parameter of configure might help somehow (when building it from scratch)?
Because I think, that when I run make install ... then I think it installs all libraries to their default locations, or not ?
Is it possible to modify target locations for make install?

Reuti · 08-01-2012, 02:29 AM

You can have both installed with different versions. Just leave leave the name it is. The symlink from libstdc++.so to a version with a number is only necessary if you want to compile something new (at least this is the idea behind it). In the applications the name of the final target (called soname) incl. the major version number will be recorded and this way it always finds the correct version it needs even if the minor version changes.

Look for soname in this document.

mazel · 08-01-2012, 04:58 AM

Just tried to copy libstdc++.so.6.0.17 to /usr/lib then I ran ldconfig and symlink target was libstdc++.so.6.0.17 ...
so I tried to run the app and:

./TheApp: symbol lookup error: /lib/libstdc++.so.6: undefined symbol: _ZNSt8messagesIcE2idE, version GLIBCXX_3.4

then i executed: ldd -r /usr/lib/libstdc++.so.6

linux-gate.so.1 => (0xb8029000)
libm.so.6 => /lib/i686/cmov/libm.so6 (0xb7f10000)
libc.so.6 => /lib/i686/cmov/libc.so6 (0xb7db5000)
/lib/ld-linux.so.2 (0xb802a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7da7000)

any idea?
I tried to google the _ZNSt8messagesIcE2idE ... there are some mailing lists ... but im unable to find the solution there ...

Reuti · 08-01-2012, 05:44 AM

What do your symlinks now look like? This libstdc++.so.6.0.17 and created a symlink from libstdc++.so.6 thereto? The original libraries are still in place?

mazel · 08-01-2012, 05:56 AM

/usr/lib# ls -la libstdc++*
libstdc++.so.6 -> libstdc++.so.6.0.17
libstdc++.so.6.10
libstdc++.so.6.0.17

seems that symlink is ok ... it points to ver. 17 ... and also the output was changed ... because when i tried to run the app without libstdc++.so.6.0.17 on place (and ldconfig)
the output was :

./TheApp: /usr/lib/libstdc++.so.6 version 'GLIBCXX_3.4.14' not found (required by ./TheApp)
./TheApp: /usr/lib/libstdc++.so.6 version 'GLIBCXX_3.4.15' not found (required by ./TheApp)

NevemTeve · 08-01-2012, 06:27 AM

try this on both computers:

Code:

nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt8messagesIcE2id

mazel · 08-01-2012, 07:18 AM

dev system:
000ec1e0 u _ZNS8messagesIcE2idE

embeded system was not possible to run eg. nm command not found but i tried it from the dev system with modified path to libstdc++.so.6 (path to file on embeded system) and the output was the same: 000ec1e0 u _ZNS8messagesIcE2idE

Ive just realized, that I compiled the app with debug symbols (Debug profile) ... so i have to compile release version ... Im feeling that this might be the isuue
EDIT: No I have build and tried it with release version and the result was the same ...

Reuti · 08-01-2012, 02:43 PM

ibstdc++.so.6.10 should be more recent than ibstdc++.so.6.0.17, but the second was installed as an update on your development system?

mazel · 08-02-2012, 01:44 AM

yes, libstdc++.so.6.0.10 was the original version and then I had to update GCC on the dev system... so after that the version on the dev system is libstdc++.so.6.0.17
I tried to install yesterday the dev pkg of GCC 4.6 on the dev system and libstdc++.so.6.0.14 appeared so I compiled the app using g++-4.6 ... copied the libstdc++.so.6.0.14 to embeded system and tried to run the app ... but "ELF file OS ABI invalid" error appeared .... so Im not sure now if it is some move forward or not ...

Thank you very much for helping me out ...

I will be thankfull for any advice ...

NevemTeve · 08-02-2012, 02:21 AM

I think it means that libsdtc++ doesn't follow the standard, meaning version 6.0.17 isn't binary compatible with 6.0.10. (Also 6.0.10 isn't compatible with 6.0.17, but that's acceptable

But, just to be sure, install 'nm' on the other system, and repeat these steps:

Code:

nm -D /usr/lib/libstdc++.so.6.0.10 | grep _ZNSt8messagesIcE2id
nm -D /usr/lib/libstdc++.so.6.0.17 | grep _ZNSt8messagesIcE2id
ls -l /usr/lib/libstdc++.so.6

If the symbol is present in 6.0.10, but missing from 6.0.17 then the we are right, otherwise we have misunderstood something.

mazel · 08-02-2012, 04:15 AM

Quote:

Originally Posted by NevemTeve

I think it means that libsdtc++ doesn't follow the standard, meaning version 6.0.17 isn't binary compatible with 6.0.10. (Also 6.0.10 isn't compatible with 6.0.17, but that's acceptable

But, just to be sure, install 'nm' on the other system, and repeat these steps:

Code:

nm -D /usr/lib/libstdc++.so.6.0.10 | grep _ZNSt8messagesIcE2id
nm -D /usr/lib/libstdc++.so.6.0.17 | grep _ZNSt8messagesIcE2id
ls -l /usr/lib/libstdc++.so.6

If the symbol is present in 6.0.10, but missing from 6.0.17 then the we are right, otherwise we have misunderstood something.

Realy would like to do that ... but since there is no make, cc etc on embeded system I cant configure/ make / make install on embeded system binutils ... and if I copy the nm from dev system it requires other libraries ... one of them is libc.so.6 (glibcxx ....11) and it of course reboot imediatelly when I try to replace it ...

It is complicated ... the embeded system is quite obsolete (and any mandatory change is forbiden) and i have to run there aplication which has to support openssl 1.0 libxml2 further more in the app are included libraries which was compiled in gcc 4.5.1 and provider of these libraries claims that the whole app has to be compiled under gcc 4.5.1 ... but Im compiling it under 4.7 (and it works on dev system) ... so ... kind of problem that now I have a doubts if it is even posible...

NevemTeve · 08-02-2012, 04:25 AM

Aren't the embedded system's partitions mounted somewhere in the development system?

mazel · 08-02-2012, 04:32 AM

Quote:

Originally Posted by NevemTeve

Aren't the embedded system's partitions mounted somewhere in the development system?

yes, it is ... mounted in dev system /mnt/sda1/

This issue was raised when I had to install openssl 1.0 (0.9.8 was initialy on the both systems) and thus I had to upgrade gcc and other libraries (dependencies) to be able install v 1.0.0 ...