What happens when an exe/lib links to another shared one:

UNIX for Advanced & Expert Users
1

We build our code on all platforms Sol, Hp, Aix, Sgi & linux.

Some base libraries have changed.
All the dependent exe & lib which use those base libraries have changed in all platforms in terms of size/checksum or both except linux.

No code has changed in these.

We have a post utility which compares them from the previous ones on the basis of size & checkum. This thing is failing in linux as they are not getting changed.

As far as i know, when a library or exe has build time dependency on another shared library:
It keeps the name of the shared library in its table somewhere and uses the symbol name of the function or variable which it requires.
If its an archive library then it copies the stuff it requires.

Am i right? :slight_smile:

I don't have any meaningful reason about this anomaly in Linux.

Can you suggest some? :confused:

Thanks

2

The library in Linux is actually a link? eg. mylib.so is a link and is not updated to point to mylib.so.1.3

You should not depend on checksums to validate libraries. There should be a simple module in there, call it getversion(), with a static what string

static char *pvcsmodulename="@(#)mycompany modulename v 1.5   13 Jun 2003 14:06 $";
char  *getversion(void)
{
    return pvcsmodulename;
}

You can run what against the library to see the version, and your code can internally call getversion() if it needs it.

3

Sorry,

I couldn't get you.

Can you explian a bit in detail.

Thanks

4

All a checksum tells you is one thing: different checksums mean the files are different somehow. It is slightly possible for files to be different and return the same checksums.

Use another method to indentify your libraries and executables. You need positive indentification, not checksums, especially since this app is compiled on a lot of platforms. checksums are good for detecting data integrity. They are not always good as "file version identifiers". If they were, apps would use checksums as version numbers, IMO.

5

To be precise we use MD5 checkum. We calculate that via perl library.

The problem is that there are different on all platforms except linux.

That's what creating some problems.

6

Okay. Let's assume the linux box had a different, earlier version of the source you are compiling - by accident. How can you tell you're building the app from the correct source? Since the result is the same, your methods say nothing changed, then you are left with one answer: compiling the wrong version of code.

7

That i can gurantee that the source code in all is the same.

We use clearcase and the view has the same config spec.

8

Alright.
This is what you've said, correct me where it's wrong:

  1. Source is verifed as correct
  2. Source compiles with no errors
  3. The resulting library(ies) have the same checksum as the library(ies)
    you had before.
  4. The new libraries do not work.
  5. New libraries do work fine in another environment

a priori something failed in the process or the libraries would work in the Linux env.

There aren't a lot of other conclusions to make except that some of your base assumptions or observations have a problem.

  1. The libraries do link and work correctly - fix pathnames & links for example
  2. The libraries were not replaced for whatever reason. Try a build in
    a wholly different Linux box.
  3. There were compilation errors - make sure the makefile or script isn't
    doing some redirecting of error messages
  4. Source is wrong. If you have history in the source files, edit some and verify they
    the newer files.

You have to take a meta-step around the problem and break and test your assumptions or it'll never get solved. IMO.

9

Your second table does not apply.
We have all the correct procedure there.

The 4th point of first table is not yet confirmed.
4. The new libraries do not work.

QA is working on them.

Do you still remember that so are different in all other platforms except linux.