Compiling an app for PCLinuxOS installs that have the older toolchain

[chesstiger]

Hi all.


I develop a software written in C that I have to upload regularly to a few remote PCLinuxOS boxes and it runs on these boxes. I cannot do the full upgrade on these boxes. I could install a few files if necessary, but I cannot take the risk of upgrading them. The version of PCLinuxOS they have is the one of July 2008 or so (it's a PCLinuxOS 2007 upgraded until July 2008, remastered and installed from this remaster on these boxes).

Yesterday I fully upgraded PCLinuxOS on my dev box. It went quite well. This upgraded the toolchain to GCC 4.4.1. I knew this upgrade would happen but I had not anticipated one consequence that I have just discovered:

Now when I compile my C application it works locally but does not work anymore on these remote boxes. When I run the program I get this error message:
  ./myapp: /lib/i686/libc.so.6: version 'GLIBC_2.7' not found (required by ./myapp)

OK, so now my compiler targets the new version of glibc and it is not compatible with the older version.

My problem is: how do I run my application on the non-upgraded boxes?

I can think of 3 possible solutions:
- Use VMware. Install the remaster I have done before the full upgrade and compile my program from there. Not pretty.
- Instruct the compiler to target the older glibc (I'm using Kdevelop). The application will run on my PCLinuxOS and also on the remote machines. How do you do that?
- install the new glibc on the remote machines. Is it possible? I guess not...

Any help will be appreciated.

Thank you in advance.


// Christophe

[Old-Polack]

chesstiger:

Two questions come to mind. What is the nature of the software you've written, and could you compile it statically, so that it becomes self contained?

The resulting binary would, of course, be larger if compiled statically, but should then run on the other machines.

[chesstiger]

Thanks for answering and for your suggestion old-polack.

It's a number-crunching application that uses some of the processors of the target computers. All target computers are quads, using 3 processors on them does not slow them down for their usual tasks. It's a text mode application using ncurses. It has to be uploaded sometimes several times a day on the target computers because each run leads to a new batch of results which themselves lead to changes in the program (optimizing values and algorithms).

After posting my question I have been doing more research and indeed came to the conclusion that linking statically could be an acceptable solution. The time needed to send the executable would be longer, but I guess it will be OK.

So I am in the process of trying to link the application statically. I have installed the package glibc-static-devel (which I guess is needed in my case?).

Now when I compile the application I get a number of unresolved dependencies associated with ncurses:
  lib_mouse.c:(.text+0x862): undefined reference to `dlopen'

I'm investigating this, but I'm wondering if linking statically against ncurses is needed. Maybe linking statically only against glibc would be enough, but I do not know how to do that.

Actually I think I'm not doing this right, so any help with static linking will be welcome!


// Christophe

[Old-Polack]

Thanks for answering and for your suggestion old-polack.

It's a number-crunching application that uses some of the processors of the target computers. All target computers are quads, using 3 processors on them does not slow them down for their usual tasks. It's a text mode application using ncurses. It has to be uploaded sometimes several times a day on the target computers because each run leads to a new batch of results which themselves lead to changes in the program (optimizing values and algorithms).

After posting my question I have been doing more research and indeed came to the conclusion that linking statically could be an acceptable solution. The time needed to send the executable would be longer, but I guess it will be OK.

So I am in the process of trying to link the application statically. I have installed the package glibc-static-devel (which I guess is needed in my case?).

Now when I compile the application I get a number of unresolved dependencies associated with ncurses:
  lib_mouse.c:(.text+0x862): undefined reference to `dlopen'

I'm investigating this, but I'm wondering if linking statically against ncurses is needed. Maybe linking statically only against glibc would be enough, but I do not know how to do that.

Actually I think I'm not doing this right, so any help with static linking will be welcome!


// Christophe

Doing a bit of Googling, I came across someone complaining to the gcc maintainers about errors with statically linking. As part of one of the responses, I find this;

This is actually not a gcc issue.  This is a library issue.  On
GNU/Linux, the library is glibc.  The glibc maintainers have decided
that they do not want to support static linking (I personally disagree
with this position).  They only support dynamically linking against
libc.  Static linking sort of grudgingly works, but some things will
fail.  For example, if your statically linked program does DNS lookups,
it will generally fail on any system which is not running the precise
version of glibc as the system on which it was built.

My guess is that the problems you are encountering are problems
statically linking with glibc.  You can certainly bring these up with
the glibc maintainers--see http://sourceware.org/glibc .  However, they
will ignore you with prejudice.

You may want to consider using -Bstatic and -Bdynamic to statically link
everything except glibc.

http://gcc.gnu.org/ml/gcc/2009-07/msg00301.html

Might be that a different solution is in order.

[chesstiger]

(snipped)

Might be that a different solution is in order.

But it still sounds like the best choice.

I have tried statically linking glibc by doing it on one of my text mode utility. It's a simple utility but it already has a number of modules in common with the project I need to run on the remote non-upgraded PCLinuxOS computers.

Once statically linked, it works both locally and on the remote computers and I have found no problem so far. The executable is 640Kb instead of 40, but I knew it would be bigger and it's not a problem.

On this simple statically linked program, if I try to add the libncurses module and call a ncurses function, I get a number of linker errors. These are:
  lib_mouse.c:(.text+0x862): undefined reference to `dlopen'
  lib_mouse.c:(.text+0x87d): undefined reference to `dlsym'
  lib_mouse.c:(.text+0x897): undefined reference to `dlsym'
  lib_mouse.c:(.text+0x8b1): undefined reference to `dlsym'
  lib_mouse.c:(.text+0x8cb): undefined reference to `dlsym'
  lib_mouse.c:(.text+0x8e8): undefined reference to `dlclose'
They are exactly the same errors I get when I try to build a statically linked version of my number-crunching project.

I have googled more than several hours on this, and ultimately it looks like I need to link statically with a version of ncurses... designed to be statically linked. On many other distributions you have a package named ncurses-static, and here is its description:
  ncurses-static rpm build for : Fedora 12. For other distributions click here.
  Name : ncurses-static    
  Version : 5.7    Vendor : Fedora Project
  Release : 3.20090207.fc12    Date : 2009-07-27 06:34:56
  Group : Development/Libraries    Source RPM : ncurses-5.7-3.20090207.fc12.src.rpm
  Size : 2.72 MB    
  Packager : Fedora Project    
  Summary : Static libraries for the ncurses library
  Description :
  The ncurses-static package includes static libraries of the ncurses library.

(this is for Fedora 12, but this package is available on many other distros)

Unfortunately this package is not available for PCLinuxOS!

I guess I have to ask in the relevant section for this package to be added to the repositories. Until I get this package my project is almost totally stopped. 



// Christophe

[Old-Polack]

chesstiger:

Just a thought, but as you have total access to the remote machines, what about uploading a copy of the source code for the application to one of the machines and compiling it there? Or install the 2009.2 release to a VM, and don't upgrade it, just use it to compile the application with the old tool chain.

[chesstiger]

chesstiger:

Just a thought, but as you have total access to the remote machines, what about uploading a copy of the source code for the application to one of the machines and compiling it there? Or install the 2009.2 release to a VM, and don't upgrade it, just use it to compile the application with the old tool chain.

Naturally all of these solutions would work, and I could also set up a separate computer here to compile for the older toolchain, but it's adding a lot of complexity when a more elegant solution (produce a statically linked executable) exists.

The ncurses-static package is a classic it seems, so providing it would also fix an unfortunate omission. It would not only fix my problem in a more elegant way than having to use virtual machines or sending sources to the remote computers, it would also make PCLinuxOS package collection more "complete".

So unless a technical problem prevents ncurses-static to be built, I believe it's the best solution.


// Christophe

[aherkey]

What I have done in the past was compile normally and include the newer tool chain libraries in the package and use a wrapper script with the environment variable LD_LIBRARY_PATH that points to the new libraries. You can use ldd to find most of the dependencies.

For example:

/opt/mypackage/bin/wrapperscript
/opt/mypackage/bin/mybinary
/opt/mypackage/lib/lib.xxx.so

In the wrapper script:
export LD_LIBRARY_PATH=/opt/mypackage/lib
/opt/mypackage/mybinary $@


- Andy

[Old-Polack]

What I have done in the past was compile normally and include the newer tool chain libraries in the package and use a wrapper script with the environment variable LD_LIBRARY_PATH that points to the new libraries. You can use ldd to find most of the dependencies.

For example:

/opt/mypackage/bin/wrapperscript
/opt/mypackage/bin/mybinary
/opt/mypackage/lib/lib.xxx.so

In the wrapper script:
export LD_LIBRARY_PATH=/opt/mypackage/lib
/opt/mypackage/mybinary $@


- Andy

I like this one too. I saw something similar in a Google search, but you beat me in posting it.

[chesstiger]

What I have done in the past was compile normally and include the newer tool chain libraries in the package and use a wrapper script with the environment variable LD_LIBRARY_PATH that points to the new libraries. You can use ldd to find most of the dependencies.

For example:

/opt/mypackage/bin/wrapperscript
/opt/mypackage/bin/mybinary
/opt/mypackage/lib/lib.xxx.so

In the wrapper script:
export LD_LIBRARY_PATH=/opt/mypackage/lib
/opt/mypackage/mybinary $@


- Andy

I like this one too. I saw something similar in a Google search, but you beat me in posting it.

Thank you guys for the suggestions. It's cool to know that you can ask questions and actually get useful advice from the PCLinuxOS forums.

I have not tried to manually provide the libraries, but who knows, maybe I'll have to.

At this time I have managed to avoid the problem by statically linking and NOT using ncurses.

I write my applications so they are portable between DOS, Windows, Linux and sometimes even to PalmOS. So I have a module that manages console I/O. It's just a handful of functions that allow you to move the cursor, change the print color, output text and get a key or a mouse click. Under Linux, as you can guess, they are wrappers to ncurses functions.

I have modified this module (actually provided a dummy replacement for it) so now all functions are mapped to nothing except the text output function that is now mapped to printf and the get string function now mapped to gets.

The application still works, can be statically linked because it does not use ncurses anymore, and... spits out blobs of hard to read data.

So it's not funny because I have to make sense of this disorganized output, but at least I can keep on using this application until, I hope, the ncurses-static package is released.

I have added a request in the "Package suggest" section, but so far... nothing.

Wait and see.


// Christophe

[Old-Polack]

chesstiger:

I saw that request earlier. Good on you.