Re: How do I resolve the error: munch: The input file ... is not valid in the current object mode.

Darrin Wolf wrote: > Question for the gurus out there--or at least anyone that knows more than I > do about AIX 5.2 and Visual Age 6.0! > > I have run into an error message that I cannot really identify. I really do > not know if it is AIX specific, or INFORMIX 64-bit specific, since the error > occurs when linking my application code to the INFORMIX ESQL libs. > > Here is a paste of the error from a terminal console: > > ------------------------------------------------------------------------ > > Compiling "rel.vjdinf72/dbifinf72.o" done. > Creating /testinf/viaware/htool/vjd/vjd143/lib/vjdinf72.so ... > rm -f /testinf/viaware/htool/vjd/vjd143/lib/vjdinf72.so > /usr/vacpp/bin/xlC_r \\ > -L/informix/lib -L/informix/lib/esql -lifsql -lifasf -lifgen -lifos -lifgls > -lnetstub -lc -lmsaa -lbsd -ldl -ltli \\ > /informix/lib/esql/checkapi.o -lifglx -L/testinf/viaware/htool/vjd/vjd143/li > b -lvjdcpp -lvjdsql \\ > ./rel.vjdinf72/dbifinf72.o \\ > -qmkshrobj=0 \\ > -e getSharedLibStartupInfo__Fv -brtl \\ > -o/testinf/viaware/htool/vjd/vjd143/lib/vjdinf72.so 2>&1 > munch: The input file /informix/lib/esql/libifsql.so is not valid in the > current object mode. > Creating /testinf/viaware/htool/vjd/vjd143/lib/vjdinf72.so done. The munch program is normally used by C++ compilers/linkers to sort out symbols etc. I forget all the ins and outs of it (been a few years since I encountered it), but it maybe to do with instantiating templates. Names such as getSharedLibStartupInfo__Fv (a function either taking or returning no data - or both - called getSharedLibStartupInfo() in the source) are strongly indicative of the use of C++. Note that you normally need to treat your ESQL/C source as C code (not C++), and arrange that the C++ code knows that your ESQL/C functions have C linkage. You can, if you are careful, compile with a C++ compiler - but there are hoops to jump through. Send me an email at the office; Appendix N of the Informix FAQ is dated 1997, and I'm pretty sure I have a more recent version of that - possibly even from this millennium. The main rules have not changed all that much though! As already nearly diagnosed (various later messages), you need to establish whether your compilation is expecting 32-bit or 64-bit object files, and you need to find out whether you have a 32-bit or 64-bit version of ESQL/C (esql -V; if the version is 9.xy.FCz, you have a 64-bit version; if 9.xy.UCz, then a 32-bit version). Similar conventions apply to the server versions too. If you've got the 'wrong' version of ESQL/C, you can simply obtain and use the other. Beware: you cannot use shared memory connections if you have a 32-bit client connecting to a 64-bit server, nor if you have a 64-bit client connecting to a 32-bit server. Network (loopback) connections should be fine. Finally, as also pointed out, there are different versions of code for some platforms (I think 64-bit) between AIX 4.3.3 and AIX 5.x; make sure your ESQL/C is really the version for AIX 5.x. It would be quite hard to tell (we're working on fixing that!). If you read the Informix FAQ, you should find that it recommends using the esql script to do the linking of an application using ESQL/C. You are not doing that. There are apt to be special options in there. If you've not dissected the link line in this version of ESQL/C - as opposed to any previous version - then you need to do that before attempting to link. Or, set INFORMIXC=xlC_r in the environment, and then use the esql script to do the linking - omit the Informix-specific libraries and flags from the link line. Note that the output from 'esql -libs' only reports on libraries and one object file; it does not report on other necessary linking options. > [...much snippage covering points answered above...] -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Thankyou for your help Jonathan and Nicholas, and as promised, I am posting what I found--I have reached a solution. Both of you have provided me valuable information that helped me resolve my problem. Special thanks for turning me on to 'nm' utility--this sort of UNIX utility should be known and including in every UNIX hacker's kit. :-) It removes the need to understand the particulars of an object/library versioning strategy. For example, in this case, one would need to know: "(esql -V; if the version is 9.xy.FCz, you have a 64-bit version; if 9.xy.UCz, then a 32-bit version)" if not familiar with 'nm'. Now, in summary here, I should kick myself for not knowing this, but on AIX, the compiler generates 32-bit code by default. It does not follow the architecture of your operating system. You always have to go out of your way, i.e., use CFLAGS and CPPFLAGS compiler/linker options to build 64-bit objects. Maybe this is quite universal, but regardless, one should never assume... enough said there! So it turns out, I pretty much determined that our software has never been ported to, nor does it check for 64-bit operating system architecture. There are no make rules or targets that check the architecture, and then turn an appropriate compiler/preprocessor directives for building 64-bit objects on such operating systems. All I simply had to do was add (for Visual Age compilers) '-q64 -qarch=auto' to CFLAGS and CPPFLAGS (and I tossed it into LDFLAGS). Also, we still incorporate the old AR and RANLIB utilities, and they both needed '-X64' added as well when using -q64 on AIX with the Visual Age compiler. After this, all is well, other than some unfortunate minor annoyances... like the fact that size_t is not an "unsigned int" in the sockets API under 64-bit mode, and so forth--so there is a bit of minor porting to be done. So thankyou, thankyou thankyou! I will definately take a closer look at our ESQL/C linking strategies, because Jonathan sort of implied that our current strategy may be nearing deprecation. -Darrin "Jonathan Leffler" <jleffler@earthlink.net> wrote in message news:3EF29F39.6070808@earthlink.net... > Darrin Wolf wrote: > > Question for the gurus out there--or at least anyone that knows more than I > > do about AIX 5.2 and Visual Age 6.0! > > > > I have run into an error message that I cannot really identify. I really do > > not know if it is AIX specific, or INFORMIX 64-bit specific, since the error > > occurs when linking my application code to the INFORMIX ESQL libs. > > > > Here is a paste of the error from a terminal console: > > > > ------------------------------------------------------------------------ > > > > Compiling "rel.vjdinf72/dbifinf72.o" done. > > Creating /testinf/viaware/htool/vjd/vjd143/lib/vjdinf72.so ... > > rm -f /testinf/viaware/htool/vjd/vjd143/lib/vjdinf72.so > > /usr/vacpp/bin/xlC_r \\ > > -L/informix/lib -L/informix/lib/esql -lifsql -lifasf -lifgen -lifos -lifgl s > > -lnetstub -lc -lmsaa -lbsd -ldl -ltli \\ > > /informix/lib/esql/checkapi.o -lifglx -L/testinf/viaware/htool/vjd/vjd143/li > > b -lvjdcpp -lvjdsql \\ > > ./rel.vjdinf72/dbifinf72.o \\ > > -qmkshrobj=0 \\ > > -e getSharedLibStartupInfo__Fv -brtl \\ > > -o/testinf/viaware/htool/vjd/vjd143/lib/vjdinf72.so 2>&1 > > munch: The input file /informix/lib/esql/libifsql.so is not valid in the > > current object mode. > > Creating /testinf/viaware/htool/vjd/vjd143/lib/vjdinf72.so done. > > > The munch program is normally used by C++ compilers/linkers to sort > out symbols etc. I forget all the ins and outs of it (been a few > years since I encountered it), but it maybe to do with instantiating > templates. Names such as getSharedLibStartupInfo__Fv (a function > either taking or returning no data - or both - called > getSharedLibStartupInfo() in the source) are strongly indicative of > the use of C++. Note that you normally need to treat your ESQL/C > source as C code (not C++), and arrange that the C++ code knows that > your ESQL/C functions have C linkage. You can, if you are careful, > compile with a C++ compiler - but there are hoops to jump through. > > Send me an email at the office; Appendix N of the Informix FAQ is > dated 1997, and I'm pretty sure I have a more recent version of that - > possibly even from this millennium. The main rules have not changed > all that much though! > > As already nearly diagnosed (various later messages), you need to > establish whether your compilation is expecting 32-bit or 64-bit > object files, and you need to find out whether you have a 32-bit or > 64-bit version of ESQL/C (esql -V; if the version is 9.xy.FCz, you > have a 64-bit version; if 9.xy.UCz, then a 32-bit version). Similar > conventions apply to the server versions too. If you've got the > 'wrong' version of ESQL/C, you can simply obtain and use the other. > Beware: you cannot use shared memory connections if you have a 32-bit > client connecting to a 64-bit server, nor if you have a 64-bit client > connecting to a 32-bit server. Network (loopback) connections should > be fine. > > Finally, as also pointed out, there are different versions of code for > some platforms (I think 64-bit) between AIX 4.3.3 and AIX 5.x; make > sure your ESQL/C is really the version for AIX 5.x. It would be quite > hard to tell (we're working on fixing that!). > > If you read the Informix FAQ, you should find that it recommends using > the esql script to do the linking of an application using ESQL/C. You > are not doing that. There are apt to be special options in there. If > you've not dissected the link line in this version of ESQL/C - as > opposed to any previous version - then you need to do that before > attempting to link. Or, set INFORMIXC=xlC_r in the environment, and > then use the esql script to do the linking - omit the > Informix-specific libraries and flags from the link line. > > Note that the output from 'esql -libs' only reports on libraries and > one object file; it does not report on other necessary linking options. > > > [...much snippage covering points answered above...] > > > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ >

Darrin Wolf wrote: > Now, in summary here, I should kick myself for not knowing this, but on AIX, > the compiler generates 32-bit code by default. It does not follow the > architecture of your operating system. That's right. AIX allows you to build both 32-bit and 64-bit apps on either type of kernel. You can also build 64-bit apps on 32-bit machines, you just can't run them. Fascinating concept, no? You always have to go out of your > way, i.e., use CFLAGS and CPPFLAGS compiler/linker options to build 64-bit > objects. That depends upon how you define "out of the way". You can also set OBJECT_MODE=64 in your environment, and all the app-dev tools will work on 64-bit apps. No need for -X64/-q64/etc. Of course, all this is documented :-) > > All I simply had to do was add (for Visual Age compilers) '-q64 -qarch=auto' Which is what I was about to add when I got to this end of the thread. That option was missing in you compile command line. > to CFLAGS and CPPFLAGS (and I tossed it into LDFLAGS). Also, we still > incorporate the old AR and RANLIB utilities, and they both needed '-X64' > added as well when using -q64 on AIX with the Visual Age compiler. The ranlib command is worthless on AIX. The linker behaves differently, so ranlib is not required. > After > this, all is well, other than some unfortunate minor annoyances... like the > fact that size_t is not an "unsigned int" in the sockets API under 64-bit > mode, and so forth--so there is a bit of minor porting to be done. No, it's not :-) There are other size changes as well, such as time_t. -- Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE ________________________________________________________________________