
On Sun, 23 Apr 2006, Roger Oberholtzer wrote:
On Sun, 2006-04-23 at 02:08 -0500, Maura Edeweiss Monville wrote:
I tried to get some info for the Tcl/Tk library file that is not linked because it is regarded by the linker as "incompatible". .
mauede@linux:/home/mokhov/restricted/mars15/linux/lib> file -k libm15gui_linux.a libm15gui_linux.a: current ar archive\012- archive file\012- Assembler source
I do not recognize the "\012- archive file\012- Assembler source" part. Seems the arhive is containing more than expected. The "current ar archive" part is all that I would have expected.
Then I enquired about "ar". I remember Dr.Mockov typing "ar" during our Monte Carlo code installation attempt. In fact I had never seen such a command before and asked him about it. He said it archives files.
I just typed in "man ar" and read the following:
mauede@linux:~/cernlib.32-2005-ifh.de/2005/lib> man ar NAME ar - create, modify, and extract from archives
...................................................................... ...................................................................... ar ignores an initial option spelt -X32_64, for compatibility with AIX. The behaviour produced by this option is the default for GNU ar. ardoes not support any of the other -X options; in particular, it does not support -X32 which is the default for AIX ar.
ar is simply an archiver. All libxxx.a files are created with it. It is similiar in concept to tar, except ar can add useful object file info to the lib. I guess on some systems the archive could contain stuff for multiple architectures, the required one being sensed automatically, or selected via -X.
You can easily get all the .o files (the stuff you really want) out of a libxxx.a file using:
ar x libxxx.a
Actually I get nothing out of this command: mauede@linux:/home/mokhov/restricted/mars15/linux/lib> ar x libm15gui_linux.a mauede@linux:/home/mokhov/restricted/mars15/linux/lib>
Then, you can just use these .o files when linking your program, skiping the libxxx.a file. The downside is that all .o files you specify this way will be included in your program, not only the ones you really used, as would be the case with the libxxx.a method. But it is a fully functional way to make a program.
So, maybe you can try this to get past the library compatibility problem by brute force.
Did you ever tell if you have the source for the library?
Yes I do have the source of Tcl/Tk 8.3. It's public stuff. Anyone can download that from the Tcl Tk site
What do you get from:
ar tv libm15gui_linux.a
You can very easily remake the archive by extracting all the files it contains (whatever they may be):
ar x libm15gui_linux.a
mauede@linux:/home/mokhov/restricted/mars15/linux/lib> ar x libm15gui_linux.a
When you have identified the .o files you think you should be linking with, make a new archive:
ar c libm15gui_linux-maura.a *.o
Replace *.o with whatever the .o files are. Then link with libm15gui_linux-maura.a instead. The result should be similiar to the brute force method listed above where you used all the .o files, except that now only the .o files you really used are included in your final program.
Hope this sheds some light. Of course, if the .o files themselves are incompatile, you will have no choice but to get the source. But this should eliminate any oddness by the libxxx.a file itself.
What is the meaning and consequence of not supporting the option "-X32" ? I do not know what this option does (never seen before) and am caught by phobia at reading he magic number "32" .... I wonder if there is any relation with this unsupported option and the linker regarding the file "libm15gui_linux.a" as incompatible with the rest of the objects being generated by compiling with the option -m32 .... See the following errors returned by the linker ....
The significance is only that a single GNU/ar archive can contain only one version of the code. Only 32-bit. Or only 64-bit. To get both requires mutliple libraries. Not one library with both. This is more a housekeeping thing than a real limitation. Perhaps an unfortunate bit of bad planning on the part of GNU/ar.
-- Roger
-- To unsubscribe, email: suse-programming-e-unsubscribe@suse.com For additional commands, email: suse-programming-e-help@suse.com Archives can be found at: http://lists.suse.com/archive/suse-programming-e