Hi - I have two complex (for me at least) make files. The older one creates a succesful executable. The later one uses if statements to conditionally make different versions of the executable. The 2nd produces an executable that fails. I have "eyeballed" the differences in the Make files and run make -n to try and spot the differences but cannot find my mistake. Is there a Unix command that will give me a summary of the contents of the two executables ie what libraries are linked etc..
Thank you
Mike
Do you mean conditional compilation using preprocessor #if or makefile if statements.
Thanks gersh99.
Shamrock - at present Makefile ifeq and ifneq statements. Later I will be using preprocessor statements in my C++ code. But at present I just want to ensure I can reproduce the code as it stands. I'm linking a program that uses a third party API and there is a new version of the API. I need to be able to produce my executable for both the old and new versions of the api, hence the conditional makefile.
I set an environmental variable MYVERSN and then
ifeq ($(MYVERSN), 5000)
case new API detail
else
case B old API detail
endif
at various parts of the makefile
I know this mechanism is working by including echo statements in the target commands.
No, it's just in the detail of what include and library files and directories are used. I can't reduce that to a simple example and I wouldn't expect anyone else to plough through all the detail for me.
I was just hoping that there was some utility that would summaries the two executables so that I could spot the differences. I have looked at nm and concluded that this is probabably at too low level of detail to help me.
I think its back to manually inspecting the two make files. Ho hum!
You can list dynamic dependencies with ldd...it shows all the shared libs loaded by the executable at runtime. If the new version is not running then maybe there is something wrong with the new APIs. So what errors you are getting and can you post them.
I' confident that the API works because they supply example programs that I have compiled, linked and run
I ran ldd against the two executables
It listed 22 so's mainly in the same order. However the two that were not in the same order, although the left hand side and rhs text were identical the hex number at the end was different. Is that significant?
I'd make sure your 'LD_LIBRARY_PATH' env var are set the same for both makefile-s AND the shells you're running your executables in.
I don't know how output of ldd looks like on Linux. My AIX system lists the shlibs needed by any executable in a single column while my HPUX shows 2 columns separated by => sign. So on HPUX the lhs of => shows the shlib as recorded in the executable while the rhs is the physical location (on disk) of that shlib. Also ldd won't show any shlibs that have been loaded explicitly by calling dlopen in the code.
Within the two sessions I am running I have:
env > env.txt
then run diff on the two files. The only differences are related to the directories I'm running in and LD_LIBRARY_PATH is identical.
Well they look the same...not any difference. Can you post the errors you are getting with the new version.
Are there any recommended compiler option for the new APIs specified in the doc?
Are there any new required environment variables recommended for the new APIs?
New Version
linux-gate.so.1 => (0xffffe000)
libXm.so.2 => /usr/lib/libXm.so.2 (0x55556000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x00944000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00c99000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00101000)
libclntsh.so.8.0 => /site/gngapps/lgc/03.12/Linux/lib/libclntsh.so.8.0 (0x556f2000)
libnsl.so.1 => /lib/libnsl.so.1 (0x02367000)
libdl.so.2 => /lib/libdl.so.2 (0x00b76000)
libg2c.so.0 => /usr/lib/libg2c.so.0 (0x55ca9000)
libgpr_ctk.so => /site/gngapps/lgc/03.12/Linux/SeisWorks/lib/libgpr_ctk.so (0x55cc7000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00b7c000)
libm.so.6 => /lib/libm.so.6 (0x00b3f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0099e000)
libc.so.6 => /lib/libc.so.6 (0x009e1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00b26000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x55e08000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x001e9000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x001cd000)
libXp.so.6 => /usr/lib/libXp.so.6 (0x55ec2000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00c94000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00c8c000)
libwtc8.so => /site/gngapps/lgc/03.12/Linux/lib/libwtc8.so (0x55eca000)
/lib/ld-linux.so.2 (0x009c3000)
Old (working version)
linux-gate.so.1 => (0xffffe000)
libXm.so.2 => /usr/lib/libXm.so.2 (0x55556000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x00944000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00c99000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00101000)
libgpr_ctk.so => /site/gngapps/lgc/03.12/Linux/SeisWorks/lib/libgpr_ctk.so (0x556f2000)
libclntsh.so.8.0 => /site/gngapps/lgc/03.12/Linux/lib/libclntsh.so.8.0 (0x55833000)
libnsl.so.1 => /lib/libnsl.so.1 (0x02367000)
libg2c.so.0 => /usr/lib/libg2c.so.0 (0x55de9000)
libdl.so.2 => /lib/libdl.so.2 (0x00b76000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00b7c000)
libm.so.6 => /lib/libm.so.6 (0x00b3f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0099e000)
libc.so.6 => /lib/libc.so.6 (0x009e1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00b26000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x55e08000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x001e9000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x001cd000)
libXp.so.6 => /usr/lib/libXp.so.6 (0x55ec2000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00c94000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00c8c000)
libwtc8.so => /site/gngapps/lgc/03.12/Linux/lib/libwtc8.so (0x55eca000)
/lib/ld-linux.so.2 (0x009c3000)
Sorry about that. Cut and Paste from Linux from terminal emulator to windows is unreliable and I ended up posting to identical Paste Buffers. Apolgies again
Thank you very much for your help Shamrock. I'm afraid I have to leave now as 17:30 in UK and have to get somewhere else on time.
Once again thank you - Mike
What errors are you getting with the new version...post them here please.
The server program I am linking, when executed is spawned from an IDL client program. THe client opens a two way pipe using STDIN and STDOUT to communicate. The IDL client issues command strings to the server and the server responds; data passes both ways, as do return codes. I follow every call to an API routine with a status code returned to the client. One dissadvantage of the pipe is that messages issued by the API on STDOUT go down the pipe rather than to the terminal.
To get round this Status codes that I send down the pipe are always preceded by the CHR(2) which I can look for as the start of what I have sent and I read away any "extraneous" messages preceding my status code and my associated message. In debug I can access the extraneous message that is usually just read away.
In this case however I call an API routine (with a debug print before it) and it never returns from the call, the server apparently terminates gracefully, and no message is issued either to STDOUT or STDERR.
Use gdb to debug runtime errors like the one you are facing...run the server program within a debugger and see it that helps any bit.
Shamrock and vgersh99 Thank you for all the help.
In the end I started with my original makefile and made incremental edits, checking that at each stage I got a successful result. At the end of that process I have a makefile that works; nothing went wrong. I admit that I still do not know what was wrong with my first attempt that was edited all in one big hit, but don't have the time to look at it further. This does not mean that I do not appreciate the time that you have spent; on the contrary I am most grateful.
Mike