What is the meaning of the option -X32 ?
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 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. 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 .... ************************************************************************* * Errors from launching the make that includes all libraries * ************************************************************************* mauede@linux:/home/mokhov/restricted/mars15> make g77 -m32 -static -L/home/mauede/cernlib.32- 2005-ifh.de/2005/lib -L/home/mokhov/restricted/mars15/linux/lib -L/home/mokhov/restricted/mcnp4c/linux/lib -L/home/mokhov/restricted/mars15/linux/lib -L/home/mokhov/restricted/mars15/linux/lib -o rmars-bnab-fems-linux marsmain.o m1505.o -lm15gui_linux -lm15linux -lm15fems_linux -lm15trneu_linux -lm15treem_linux -lm15eve_linux -lm15cem03_linux -lm15ext_linux -lm15blb_linux -lm15mpino_linux -lm15linux -lpacklib -ltk8.3 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lnsl -lpthread /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lm15gui_linux collect2: ld returned 1 exit status make: *** [rmars-bnab-fems-linux] Error 1 -- Maura E.M
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 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? 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 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
On Sun, 23 Apr 2006 12:27:38 +0200 Roger Oberholtzer <roger@opq.se> 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. I think the \012 is simply a line feed result of a copy/paste.
While I would like to see everything 64-bit, it may be better for Maura if she were to reinstall SuSE as a 32-bit OS. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
But can anyone explain WHY the same Monte Carlo installation (MC routine + CERN library + Tcl/Tk files) is RUNNING in a research center in Japan where my supervisor has installed on a x86_64 Linux/Red-Hat clusters. He installed by recompiling everything on that cluster with the -m32 option, just like on my laptop. We remotely connected from here to the Japanese center. We compared the Makefiles etc .. They coincide. But there it works. Whereas for me it doesn't. Someone asked me about the Tcl/Tk source. The answer is "yes". The procedure that installes and generates the Tcl/Tk ".a" and ".h" files does that starting from Tcl/Tk 8.3 source. This is Linux mistery, isn't it ? Maura On Sun, 23 Apr 2006, Jerry Feldman wrote:
On Sun, 23 Apr 2006 12:27:38 +0200 Roger Oberholtzer <roger@opq.se> 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. I think the \012 is simply a line feed result of a copy/paste.
While I would like to see everything 64-bit, it may be better for Maura if she were to reinstall SuSE as a 32-bit OS. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Sun, 23 Apr 2006 10:40:12 -0500 (CDT) Maura Edeweiss Monville <memonvil@artsci.wustl.edu> wrote:
But can anyone explain WHY the same Monte Carlo installation (MC routine + CERN library + Tcl/Tk files) is RUNNING in a research center in Japan where my supervisor has installed on a x86_64 Linux/Red-Hat clusters. He installed by recompiling everything on that cluster with the -m32 option, just like on my laptop. We remotely connected from here to the Japanese center. We compared the Makefiles etc .. They coincide. But there it works. Whereas for me it doesn't.
Someone asked me about the Tcl/Tk source. The answer is "yes". The procedure that installes and generates the Tcl/Tk ".a" and ".h" files does that starting from Tcl/Tk 8.3 source.
This is Linux mistery, isn't it ? You just gave me a clue. Check the versions of GCC. What version of Red Hat is he using and what version of gcc. RHEL 3.0 (2.4 kernel) or RHEL 4.0 (2.6 kernel) There were a number of changes made in GCC. I forget exactly what version of GCC is installed on RHEL, but it is either 3.3.3 or 3.4.5 or possible even 3.2.x.
You can legitimately have multiple versions of gcc on the system. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
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
On Mon, 2006-04-24 at 05:18 -0500, Maura Edeweiss Monville wrote:
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>
Meaning that you get no .o files created? This does not sound correct. The command won't list anyhthing. It just extracts the files in the archive. Are you sure the library is OK? What do you get for: ar tv libm15gui_linux.a If that lists nothing then your library is not what it should be.
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
I did not mean the Tcl/Tk source. I meant your Monte Carlo stuff. My point is: why are you not simply compiling the Monte Carlo stuff locally instead of using a library with an uncertain pedigree? -- Roger
On Mon, 24 Apr 2006, Roger Oberholtzer wrote:
On Mon, 2006-04-24 at 05:18 -0500, Maura Edeweiss Monville wrote:
i> > > 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>
Meaning that you get no .o files created? This does not sound correct. The command won't list anyhthing. It just extracts the files in the archive. Are you sure the library is OK? What do you get for:
ar tv libm15gui_linux.a
I get the following: mauede@linux:/home/mokhov/restricted/mars15/linux/lib> ar tv libm15gui_linux.a rw-r--r-- 1000/100 49288 Apr 24 12:49 2006 m15gui.o
If that lists nothing then your library is not what it should be.
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
I did not mean the Tcl/Tk source. I meant your Monte Carlo stuff. My point is: why are you not simply compiling the Monte Carlo stuff locally instead of using a library with an uncertain pedigree?
It's because it generates all the .h and .a files that the Monte Carlo program needs and stores them in the right place. I do not know how to do that if I use anothe Tcl/Tk distribution. Thanks, Maura
-- 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
On Tuesday 25 April 2006 06:35, Maura Edeweiss Monville wrote:
On Mon, 24 Apr 2006, Roger Oberholtzer wrote:
On Mon, 2006-04-24 at 05:18 -0500, Maura Edeweiss Monville wrote:
i> > > 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>
Meaning that you get no .o files created? This does not sound correct. The command won't list anyhthing. It just extracts the files in the archive. Are you sure the library is OK? What do you get for:
ar tv libm15gui_linux.a
I get the following:
mauede@linux:/home/mokhov/restricted/mars15/linux/lib> ar tv libm15gui_linux.a rw-r--r-- 1000/100 49288 Apr 24 12:49 2006 m15gui.o
So, 'ar x libm15gui_linux' must have produced a file called m15gui.o. Right? What does file m15gui.o say? What happens if you remove the -lm15gui_linux option from your compile command and replace it with m15gui..o ? After you have gotten m15gui..o out of the archive (ar x libm15gui_linux.a) and put it where the compiler can find it.
If that lists nothing then your library is not what it should be.
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
I did not mean the Tcl/Tk source. I meant your Monte Carlo stuff. My point is: why are you not simply compiling the Monte Carlo stuff locally instead of using a library with an uncertain pedigree?
It's because it generates all the .h and .a files that the Monte Carlo program needs and stores them in the right place. I do not know how to do that if I use anothe Tcl/Tk distribution.
What is the 'it' that produces these files? Do you mean to say that the source is not distributed? Only a library? -- Roger Oberholtzer OPQ Systems AB
On Sunday 23 April 2006 09:08, Maura Edeweiss Monville wrote:
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bi n/ld: skipping incompatible /home/mokhov/restricted/mars15/linux/lib/libm15gui_linux.a when searching for -lm15gui_linux
This message is usually the result of a mixed environment. Like compiling a 32 bit application and trying to link to 64 bit libraries. Are the sources public? I have a 64 bit machine here and could try compiling it if I had access to it
participants (4)
-
Anders Johansson -
Jerry Feldman -
Maura Edeweiss Monville -
Roger Oberholtzer