Re: Blade for blob size

Decided I needed to recompile the blade with gcc. I edited the "makeinc.solaris64" file. Specifically, I changed the compiler variables ("gcc" instead of "cc"), and made sure that "- fPIC", "-m64". and "-mcpu=ultrasparc" were included in the compiler options. I also found it necesssary (and I wonder if this is a clue) to add "-L /usr/lib/sparc9 -L /usr/ucblib/sparcv9" to the line in the make file ("sblob_infoU.mak", supplied with the blade) that invoked the linker. I did this to force it to encounter the 64 bit libraries first, before 32 bit ones. If I did not add those explicit "-L" arguments, I would get an error message when making the blade (wrong ELF class [32 bit])-- even though I had specified "-m64" and "mcpu=ultrasparc" in the invocation of gcc. I presumed (mistakenly) that gcc would pass along its "knowledge" of the proper ELF class, but I was wrong and needed the explicit "-L" switches. Anyway, I successfully produced a 64 bit shared library (see below). informix@defiant>pwd /opt/informix/extend/sblob_info.1.5 informix@defiant>file sblob_info.bld sblob_info.bld: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, UltraSPARC1 Extensions Required, dynamically linked, not stripped informix@defiant> Then, I successfully registered the blade with the database: informix@defiant>blademgr play1shm>register sblob_info.1.5 acoms Register module sblob_info.1.5 into database acoms? [Y/n]Y Registering DataBlade module... (may take a while). DataBlade sblob_info.1.5 was successfully registered in database acoms. Then, I used dbaccess to execute a SELECT statement that contained one of the blade functions [SblobStatSize()]. It failed. Examining the log: 11:18:39 Loading Module <$INFORMIXDIR/extend/sblob_info.1.5/ sblob_info.bld> 11:18:39 The C Language Module <$INFORMIXDIR/extend/sblob_info.1.5/ sblob_info.bld> can't load reason: ld.so.1: oninit: fatal: /usr/ucblib/libucb.so.1: wrong ELFclass: ELFCLASS32 11:18:39 (-1): ERROR: Loading Module <$INFORMIXDIR/extend/sblob_info. 1.5/sblob_info.bld> It would appear that ld, which according to the man pages should automatically detect the ELF class and link properly, is trying to use the 32 bit ucb shared object. So, I have a 64-bit blade that "ld" is trying to link with 32-bit library. Why is this happening, and WHAT CAN I DO TO FIX IT? Since the Informix invocation of "ld" happens internally, I can't get to the command line to add an "-L" option to force it to find a 64-bit library before 32-bit. I have tried setting LD_LIBRARY_PATH environment var, but that has no effect. Thank you for any suggestions. Regards, DG

Have you bounced the Informix engine after modifying the LD_LIBRARY_PATH? I'm assuming that this is a 64bit version of Informix, yes?? Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Mar 22, 2011 at 4:02 PM, pretzel <davidegrove@gmail.com> wrote: > Decided I needed to recompile the blade with gcc. > > I edited the "makeinc.solaris64" file. Specifically, I changed the > compiler variables ("gcc" instead of "cc"), and made sure that "- > fPIC", "-m64". and "-mcpu=ultrasparc" were included in the compiler > options. I also found it necesssary (and I wonder if this is a clue) > to add "-L /usr/lib/sparc9 -L /usr/ucblib/sparcv9" to the line in the > make file ("sblob_infoU.mak", supplied with the blade) that invoked > the linker. I did this to force it to encounter the 64 bit libraries > first, before 32 bit ones. If I did not add those explicit "-L" > arguments, I would get an error message when making the blade (wrong > ELF class [32 bit])-- even though I had specified "-m64" and > "mcpu=ultrasparc" in the invocation of gcc. I presumed (mistakenly) > that gcc would pass along its "knowledge" of the proper ELF class, but > I was wrong and needed the explicit "-L" switches. > > Anyway, I successfully produced a 64 bit shared library (see below). > > informix@defiant>pwd > /opt/informix/extend/sblob_info.1.5 > informix@defiant>file sblob_info.bld > sblob_info.bld: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, > UltraSPARC1 Extensions Required, dynamically linked, not stripped > informix@defiant> > > > Then, I successfully registered the blade with the database: > > informix@defiant>blademgr > play1shm>register sblob_info.1.5 acoms > Register module sblob_info.1.5 into database acoms? [Y/n]Y > Registering DataBlade module... (may take a while). > DataBlade sblob_info.1.5 was successfully registered in database > acoms. > > > Then, I used dbaccess to execute a SELECT statement that contained one > of the blade functions [SblobStatSize()]. It failed. Examining the > log: > > 11:18:39 Loading Module <$INFORMIXDIR/extend/sblob_info.1.5/ > sblob_info.bld> > 11:18:39 The C Language Module <$INFORMIXDIR/extend/sblob_info.1.5/ > sblob_info.bld> can't load > reason: ld.so.1: oninit: fatal: /usr/ucblib/libucb.so.1: wrong ELF> class: ELFCLASS32 > 11:18:39 (-1): ERROR: Loading Module <$INFORMIXDIR/extend/sblob_info. > 1.5/sblob_info.bld>> > > It would appear that ld, which according to the man pages should > automatically detect the ELF class and link properly, is trying to use > the 32 bit ucb shared object. > > So, I have a 64-bit blade that "ld" is trying to link with 32-bit > library. Why is this happening, and WHAT CAN I DO TO FIX IT? > > Since the Informix invocation of "ld" happens internally, I can't get > to the command line to add an "-L" option to force it to find a 64-bit > library before 32-bit. I have tried setting LD_LIBRARY_PATH > environment var, but that has no effect. > > Thank you for any suggestions. > > Regards, > > DG > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list >

On Mar 22, 1:24 pm, Art Kagel <art.ka...@gmail.com> wrote: > Have you bounced the Informix engine after modifying the LD_LIBRARY_PATH? > I'm assuming that this is a 64bit version of Informix, yes?? > > Art 1) No. I'll try it. (Currently workingin my "play" database. Production will have to wait.) 2) Yes. A little more info. I find that "file" is a liar: informix@defiant>file sblob_info.bld sblob_info.bld: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, UltraSPARC1 Extensions Required, dynamically linked, not stripped informix@defiant> Yet, from "ldd": informix@defiant>ldd sblob_info.bld libucb.so.1 => /usr/ucblib/libucb.so.1 - wrong ELF class: ELFCLASS32 libresolv.so.2 => /lib/64/libresolv.so.2 libsocket.so.1 => /lib/64/libsocket.so.1 libnsl.so.1 => /lib/64/libnsl.so.1 libelf.so.1 => /lib/64/libelf.so.1 libc.so.1 => /lib/64/libc.so.1 libmp.so.2 => /lib/64/libmp.so.2 libmd.so.1 => /lib/64/libmd.so.1 libscf.so.1 => /lib/64/libscf.so.1 libdoor.so.1 => /lib/64/libdoor.so.1 libuutil.so.1 => /lib/64/libuutil.so.1 libgen.so.1 => /lib/64/libgen.so.1 libm.so.2 => /lib/64/libm.so.2 /platform/SUNW,Ultra-250/lib/sparcv9/libc_psr.so.1 /platform/SUNW,Ultra-250/lib/sparcv9/libmd_psr.so.1 Note the first library! Yet, "file" declares the blade to be 64 bit. What a social pathology. I guess I need to revisit the gcc command to figure out why that single 32-bit library is making it in. Any suggestions welcome. Sidebar: why would "ld" even work this way? I thought you couldn't mix ELF classes. DG

Victory. The trick was to use the -R switch (which made the search path available at runtime, when Informix was loading the blade) in the ld command line, rather than -L (which applies during the command line execution of ld). I still don't know why I was getting the 32-bit library linked in, as described above. It still seems strange that, for at lest 10 years, IBM has never added a SIZE function for blobs as a built-in feature. Thank you all, for your comments. DG

On Wed, Mar 23, 2011 at 12:23 AM, pretzel <davidegrove@gmail.com> wrote: > Victory. > > The trick was to use the -R switch (which made the search path > available at runtime, when Informix was loading the blade) in the ld > command line, rather than -L (which applies during the command line > execution of ld). > > I still don't know why I was getting the 32-bit library linked in, as > described above. > Probably because you have a 32bit version and a 64bit version of the library, and the 32bit location appears first in the ld search path (LD_LIBRARY_PATH set?) > It still seems strange that, for at lest 10 years, IBM has never added > a SIZE function for blobs as a built-in feature. > > Thank you all, for your comments. > Being this easy I tend to agree. But in fact I haven't see so much interest on this except in the latest weeks. But looking into internal KB there are questions about this since long time ago. Just for curiosity, why do you need this? One of the latest posters was trying to identify empty (but not NULL) blobs... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

> > I still don't know why I was getting the 32-bit library linked in, as > > described above. > > Probably because you have a 32bit version and a 64bit version of the > library, and the 32bit location appears first in the ld search path > (LD_LIBRARY_PATH set?) > informix@defiant>echo $LD_LIBRARY_PATH /usr/lib/sparcv9:/usr/ucblib/sparcv9:/opt/informix/lib informix@defiant> > But in fact I haven't see so much interest > on this except in the latest weeks. But looking into internal KB there are > questions about this since long time ago. A search of cdi also shows interest going quite a way back. > Just for curiosity, why do you need this? One of the latest posters was > trying to identify empty (but not NULL) blobs Yes, we have an application that stores photos in blobs ini an sbspace. We have a table that has a row for each photo. For a while, the application was permitting the creation of rows in the table with an empty blob in the "photo" column. So, we have a bunch of rows in the photograph table that have empty blobs. For our purposes, that is similar to having a null PK (if you can make any sense out of that analogy). In other words, the PK of the row in the photograph table is actuaolly sort of surogate key for the photo. But, because the photo column in the table really contains a blob handle, and the blob itself could be empty, we have a situation where existence of a photo i asserted (a row exists in the table), yet there is no photo. Sort of like an ObjectID in an OO database, in that an OID exists independently of the entity (as opposed to the Relational Model, in which the PK IS data, and IS existence). Anyway, we want to "search and destroy" rows in the photograph table which have no photograph, so being able to include a "SIZE(<blob- column>)=0" in a WHERE clause is very helpful. Thank you for your comments. Regards, DG

On Wed, Mar 23, 2011 at 4:54 PM, pretzel <davidegrove@gmail.com> wrote: > > > > I still don't know why I was getting the 32-bit library linked in, as > > > described above. > > > > Probably because you have a 32bit version and a 64bit version of the > > library, and the 32bit location appears first in the ld search path > > (LD_LIBRARY_PATH set?) > > > > informix@defiant>echo $LD_LIBRARY_PATH > /usr/lib/sparcv9:/usr/ucblib/sparcv9:/opt/informix/lib > informix@defiant> > > I recall that on many systems (Solaris is one of them), setuid programs don't follow LD_LIBRARY_PATH (for -good- security reasons) Maybe that's the problem. In that case the system seach path should be used. Why a 32bit location appears first (if it does) in a 64 bit system is beyond my understanding... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...