Re: Informix Upgrade : Compilation Problems

Yes John , 1. 7.20UD2 to 7.32FC@ is the 4gl compiler version. 2. The holiday.o is a c file(part of the library datefun.a) in apps01/xyz/dev/src/tools/. I recompiled all the files, inluding holiday.o (the c files and 4gl files) . When I compile the C files , I get a lot of "warning :implicit function declaration: retint " and similar warning messages. 3. The 'Undefined symbols checksum,soundex,reverse_ascii are function names in my C file , checksum.c, and soundex.c. They are part of the library "datefun.a". Compiling them in the new system did not give me any errors. I only had "warning:implicit function declaration" 4.load_holiday_array and validate_date also are C function names defines in files holiday.c and a program infrmxtoc.c. Again compilation gave only warnings. 5. I get this error in every module that I compile and the error message is the same. --- Question : 1.Once I compile , based on the object file, how can I say whether it was compiled using 32 bit or 64 bit ? 2.The error says "Undefined symbol" whereas they are really functions ? Is it not able to resolve the function definitions in the C library ? If yes, then there should have been a problem in the creation of the library, which I did not notice. 3.Is there a way to compile the C programs alone using a 32 bit Sun Studio 8 compiler and then link to the object code of 4gl files ? Will that still work in a 64 bit OS ? 4.What good is it going to a 64 bit OS and 64 bit IDS , if the application is not changed to take advantage of that ? 5. Is going to 32bit Solaris 8 , IDS 9.40 32 bit and Sun C compiler for 32 bit a good idea ? 6.Anyone knows what a crc table is (I know crc is cyclic redundacy check but I am not aware why it is exactly used in a application. My application in one of the C programs has a CRC table listing all values e.g as shown below. Also this is the function checksum which apparently the compiler says "Undefined Symbol" As always, Thanks a ton John, Rajib for your inputs, hopefully we resolve it. Waiting to hear from you. Bkr ================================================================= unsigned generate_crc(); /* globals */ static int crc_table[] = /* CRC lookup table */ { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, 0xC601, 0x06C0, 0x0780, 0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440, 0xCC01, 0x0CC0, 0x0D80, 0xCD41, 0x0F00, 0xCFC1, 0xCE81, 0x0E40, 0x0A00, 0xCAC1, 0xCB81, 0x0B40, 0xC901, 0x09C0, 0x0880, 0xC841, 0xD801, 0x18C0, 0x1980, 0xD941, 0x1B00, 0xDBC1, 0xDA81, 0x1A40, 0x1E00, 0xDEC1, 0xDF81, 0x1F40, 0xDD01, 0x1DC0, 0x1C80, 0xDC41, 0x1400, 0xD4C1, 0xD581, 0x1540, 0xD701, 0x17C0, 0x1680, 0xD641, 0xD201, 0x12C0, 0x1380, 0xD341, 0x1100, 0xD1C1, 0xD081, 0x1040, 0xF001, 0x30C0, 0x3180, 0xF141, 0x3300, 0xF3C1, 0xF281, 0x3240, 0x3600, 0xF6C1, 0xF781, 0x3740, 0xF501, 0x35C0, 0x3480, 0xF441, 0x3C00, 0xFCC1, 0xFD81, 0x3D40, 0xFF01, 0x3FC0, 0x3E80, 0xFE41, 0xFA01, 0x3AC0, 0x3B80, 0xFB41, 0x3900, 0xF9C1, 0xF881, 0x3840, 0x2800, 0xE8C1, 0xE981, 0x2940, 0xEB01, 0x2BC0, 0x2A80, 0xEA41, 0xEE01, 0x2EC0, 0x2F80, 0xEF41, 0x2D00, 0xEDC1, 0xEC81, 0x2C40, 0xE401, 0x24C0, 0x2580, 0xE541, 0x2700, 0xE7C1, 0xE681, 0x2640, 0x2200, 0xE2C1, 0xE381, 0x2340, 0xE101, 0x21C0, 0x2080, 0xE041, 0xA001, 0x60C0, 0x6180, 0xA141, 0x6300, 0xA3C1, 0xA281, 0x6240, 0x6600, 0xA6C1, 0xA781, 0x6740, 0xA501, 0x65C0, 0x6480, 0xA441, 0x6C00, 0xACC1, 0xAD81, 0x6D40, 0xAF01, 0x6FC0, 0x6E80, 0xAE41, 0xAA01, 0x6AC0, 0x6B80, 0xAB41, 0x6900, 0xA9C1, 0xA881, 0x6840, 0x7800, 0xB8C1, 0xB981, 0x7940, 0xBB01, 0x7BC0, 0x7A80, 0xBA41, 0xBE01, 0x7EC0, 0x7F80, 0xBF41, 0x7D00, 0xBDC1, 0xBC81, 0x7C40, 0xB401, 0x74C0, 0x7580, 0xB541, 0x7700, 0xB7C1, 0xB681, 0x7640, 0x7200, 0xB2C1, 0xB381, 0x7340, 0xB101, 0x71C0, 0x7080, 0xB041, 0x5000, 0x90C1, 0x9181, 0x5140, 0x9301, 0x53C0, 0x5280, 0x9241, 0x9601, 0x56C0, 0x5780, 0x9741, 0x5500, 0x95C1, 0x9481, 0x5440, 0x9C01, 0x5CC0, 0x5D80, 0x9D41, 0x5F00, 0x9FC1, 0x9E81, 0x5E40, 0x5A00, 0x9AC1, 0x9B81, 0x5B40, 0x9901, 0x59C0, 0x5880, 0x9841, 0x8801, 0x48C0, 0x4980, 0x8941, 0x4B00, 0x8BC1, 0x8A81, 0x4A40, 0x4E00, 0x8EC1, 0x8F81, 0x4F40, 0x8D01, 0x4DC0, 0x4C80, 0x8C41, 0x4400, 0x84C1, 0x8581, 0x4540, 0x8701, 0x47C0, 0x4680, 0x8641, 0x8201, 0x42C0, 0x4380, 0x8341, 0x4100, 0x81C1, 0x8081, 0x4040 }; /* ------------------------------------------------------ */ checksum(numvars) int numvars; { int i, index, length; unsigned crc; char *textptr,text[512]; popquote(text,sizeof(text)); crc = 0; /* crc starts at zero for each message */ length = strlen(text); textptr = &text[0]; for (i = 0; i < length; i++, textptr++) { index = ( (crc ^ *textptr) & 0x00FF); crc = ( (crc >> 8) & 0x00FF) ^ crc_table[index]; } retint(crc); return(1); } Jonathan Leffler <jleffler@earthlink.net> wrote in message news:<vdOac.10115$Dv2.7104@newsread2.news.pas.earthlink.net>... > Bkr wrote: > > We are migrating from IDS 7.20UD2 to 7.32FC2, Solaris 2.6 to > > Solaris 2.8 64 bit, Sun Workshop C compiler from 5.0 to 5.5, > > Informix 9.30 to 9.40. I am tryng to recompile the same programs in > > the new envirnoment. > > I assume you mean I4GL (c-code) 7.20.UD2 to 7.32.FC2 - if you meant > the former version of IDS, you're years overdue to upgrade, and the > second version doesn't exist. And the 9.30 to 9.40 comment supports > this hypothesis. > > > However I come across the following errors in compiling. > > Has someone faced the same problem before and solved it ? What could > > be the problem here ? > > snapshot of the error : > > ___________________________________ > > ld: warning: file /apps01/xyz/dev/src/tools/datefun.a(holiday.o): > > wrong ELF > > class: ELFCLASS32 > > So, at the very least, you need to recompile the holiday.o file in the > datefun.a library with the 64-bit flags -- you can't link 32-bit ELF > files with 64-bit ELF files. Most likely, you need to rebuild that > whole library. > > > Undefined first referenced > > symbol in file > > checksum info_pldg.o > > soundex arbcase.o > > reverse_ascii > > /apps01/xyz/dev/src/tools/xyzlib.a(ban > > ner_help.o) > > Dunno about these - they don't look very much like date functions. > > > load_holiday_array > > /apps01/xyz/dev/src/tools/xyzlib.a(crt > > ools.o) > > validate_date > > /apps01/xyz/dev/src/tools/xyzlib.a(val > > idate.o) > > These two do look like date functions. > > > ld: fatal: Symbol referencing errors. No output written to case_local > > *** Error code 1 > > The following command caused the error: > > c4gl -O case_local.o info_pldg.o info_legl.o close.o defic.o > > consol.o notes.o > > arbcase.o /apps01/xyz/dev/src/tools/xyzlib.a /apps01/xyz/dev/src/tools > > /datefun.a /apps01/xyz/dev/src/tools/xyzdb.a -o case_local@

Bkr wrote: > Yes John , > 1. 7.20UD2 to 7.32FC@ is the 4gl compiler version. > 2. The holiday.o is a c file(part of the library datefun.a) in > apps01/xyz/dev/src/tools/. I recompiled all the files, including > holiday.o (the c files and 4gl files). When I compile the C files, > I get a lot of "warning :implicit function declaration: retint " > and similar warning messages. Fix that by adding this near the top of the C file: #include "fglsys.h" > 3. The 'Undefined symbols checksum,soundex,reverse_ascii are function > names in my C file , checksum.c, and soundex.c. They are part of > the library "datefun.a". Compiling them in the new system did not > give me any errors. I only had "warning:implicit function > declaration" OK - but the link phase may have stopped processing the library after the first 'wrong ELF class' error - and hence never picked up those names. > 4.load_holiday_array and validate_date also are C function names > defines in files holiday.c and a program infrmxtoc.c. Again > compilation gave only warnings. Same fix. > 5. I get this error in every module that I compile and the error > message is the same. > > --- > Question : > 1.Once I compile, based on the object file, how can I say whether it > was compiled using 32 bit or 64 bit ? file object.o will usually tell you. > 2.The error says "Undefined symbol" whereas they are really functions? Same thing - sort of. Technically, a symbol might be a function or a global variable, but it usually sorts itself out. > Is it not able to resolve the function definitions in the C library? > If yes, then there should have been a problem in the creation of the > library, which I did not notice. Not necessarily - it depends a bit on the archive tool. There's actually nothing to stop you putting source code into an archive; indeed, once upon an aeon ago, that was common practice (ask Art Kagel; he's one of the few people I know who still does do it). So, the library creation process is not going to complain. However, the linker can, and does, complain about a mixture of 32-bit and 64-bit object files. > 3.Is there a way to compile the C programs alone using a 32 bit Sun > Studio 8 compiler and then link to the object code of 4gl files ? Will > that still work in a 64 bit OS ? The easiest way is to use the c4gl script in lieu of the C compiler - it ensures that the correct options are passed. Failing that, you choose -xarch=v9 (or -xarch=sparcv9) to select a 64-bit compile, or omit that or say -xarch=v8 to do a 32-bit compile. > 4.What good is it going to a 64 bit OS and 64 bit IDS, if the > application is not changed to take advantage of that? Two separate issues. (1) The application can be made to work in 64-bit mode. (2) There are two main benefits to using a 64-bit application - you can connect to a 64-bit server using shared memory, and you might get slightly better performance some of the time. > 5. Is going to 32bit Solaris 8, IDS 9.40 32 bit and Sun C compiler > for 32 bit a good idea? It's what I happen to use, but I'm too lazy (and short of disk space) to install the 64-bit version as well. IDS benefits from being a 64-bit application; it is less clear that I4GL programs benefit. > 6.Anyone knows what a crc table is (I know crc is cyclic redundacy > check but I am not aware why it is exactly used in a application. My > application in one of the C programs has a CRC table listing all > values e.g as shown below. Also this is the function checksum which > apparently the compiler says "Undefined Symbol" It's an older-fashioned, less secure way of verifying that your input data matches what you expected - the newer, more fashionable ways being things like MD5 and SHA1 digests (check sums). > As always, Thanks a ton John, Rajib for your inputs, hopefully we > resolve it. > > Waiting to hear from you. > > Bkr > > ================================================================= #include "fglsys.h" > unsigned generate_crc(); > > /* globals */ > static int crc_table[] = /* CRC lookup table */ Add a const in here - no-one is allowed to change the table: static const int crc_table[] = > { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, > 0xC601, 0x06C0, 0x0780, 0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440, > [...snip...] > 0x4400, 0x84C1, 0x8581, 0x4540, 0x8701, 0x47C0, 0x4680, 0x8641, > 0x8201, 0x42C0, 0x4380, 0x8341, 0x4100, 0x81C1, 0x8081, 0x4040 > }; > > /* ------------------------------------------------------ */ > checksum(numvars) > int numvars; > { Get used to writing C99 code - which requires an explicit return type - and always use prototype notation (int checksum(int numvars) { ... } And it is good practice to declare your functions in a header before defining them (though I4GL is not going to pick up your header, so it is an exercise of limited value). > int i, index, length; > unsigned crc; > char *textptr,text[512]; > > popquote(text,sizeof(text)); > crc = 0; /* crc starts at zero for each message */ > > length = strlen(text); > textptr = &text[0]; > > for (i = 0; i < length; i++, textptr++) { > index = ( (crc ^ *textptr) & 0x00FF); > crc = ( (crc >> 8) & 0x00FF) ^ crc_table[index]; > } > retint(crc); > return(1); > } > > Jonathan Leffler <jleffler@earthlink.net> wrote in message news:<vdOac.10115$Dv2.7104@newsread2.news.pas.earthlink.net>... > >>Bkr wrote: >> >>>We are migrating from IDS 7.20UD2 to 7.32FC2, Solaris 2.6 to >>>Solaris 2.8 64 bit, Sun Workshop C compiler from 5.0 to 5.5, >>>Informix 9.30 to 9.40. I am tryng to recompile the same programs in >>>the new envirnoment. >> >>I assume you mean I4GL (c-code) 7.20.UD2 to 7.32.FC2 - if you meant >>the former version of IDS, you're years overdue to upgrade, and the >>second version doesn't exist. And the 9.30 to 9.40 comment supports >>this hypothesis. >> >> >>>However I come across the following errors in compiling. >>>Has someone faced the same problem before and solved it ? What could >>>be the problem here ? >>>snapshot of the error : >>>___________________________________ >>>ld: warning: file /apps01/xyz/dev/src/tools/datefun.a(holiday.o): >>>wrong ELF >>>class: ELFCLASS32 >> >>So, at the very least, you need to recompile the holiday.o file in the >>datefun.a library with the 64-bit flags -- you can't link 32-bit ELF >>files with 64-bit ELF files. Most likely, you need to rebuild that >>whole library. >> >> >>>Undefined first referenced >>> symbol in file >>>checksum info_pldg.o >>>soundex arbcase.o >>>reverse_ascii >>>/apps01/xyz/dev/src/tools/xyzlib.a(ban >>>ner_help.o) >> >>Dunno about these - they don't look very much like date functions. >> >> >>>load_holiday_array >>>/apps01/xyz/dev/src/tools/xyzlib.a(crt >>>ools.