When deploying the query resource limiting project across
a variety of OS's and Ingres's versions a bug(?)/diversity occurred relating to the 'seterr' procedure.
In all environments the compilation succeeded but in some there was a linking error :
Ingres II 9.2.0 (int.lnx/118)NPTL
openSUSE 11.0 (i586)
Ingres II 9.2.0 (int.lnx/118)NPTL
CentOS release 5.2 (Final)
Ingres II 2.0/9808 (usl.us5/00)
5 7.1.1 i386 x86at SCO UNIX_SVR5
Ingres II 2.0/0308 (hpb.us5/00)
HP-UX 11.00
Of course there might be other specs that it has not been tested on.It seems that especially Linux'es are vulnerable to it.
Specs where there was no problem :
Ingres II 2.5/0011
SCO_SV 3.2 5.0.7 i386
Ingres II 2.5/0011
SCO_SV 3.2 5.0.5 i386
Ingres II 2.0/0308 (hpb.us5/00)
HP-UX 11.00
A request was send out to our local Ingres support who subsequently forwarded the issue to the Ingres Service desk, which replied. The reply was to
'nm $II_SYSTEM/ingres/lib/libingres.a | grep iiset
err' and look for the following entry
iiseterr.o:
00000a5f T iiseterr_',
which existed. And the next step was to check the contents of abfdyn.opt and abflnk.opt for some entries
(-linterp.1,-lframe.1,0lq.1 ...) which were also in tact.
It did not solve the problem though.
The problem lies in calling the 'iiseterr' function.Apparently, the linker on the machines with the problem cannot find a reference to it.
The related entry in the manual (r3 Documentation, Forms-based Application Development Tools, User Guide Runtime Error Processing M–3, Using iiseterr() in Ingres Applications,page 1243)
seterr ()
{
extern int myhandler();
iiseterr (myhandler);
return;
}
which in some specs links ok and in some not!
In examining some C header (eqpname.h in particular) files I've noticed that all references to iiseterr were IIseterr. Subsequently changing the entry to IIseterr solved the problem, the linking succeeded plus it did not break the specs that had no problem to begin with.
a variety of OS's and Ingres's versions a bug(?)/diversity occurred relating to the 'seterr' procedure.
In all environments the compilation succeeded but in some there was a linking error :
Building runnable image of gryl00010aqep . . . seterr.obj: In function `seterr': seterr.c:(.text+0xe): undefined reference to `iiseterr' collect2: ld returned 1 exit status E_AB0020 Link failed The link failed with status '69891'. This could mean either that the linker could not be run or that it ran and returned an error. E_AI0002 The application image was NOT built. An earlier error prevents the application image from being built. Correct the cause of the earlier error and then run imageapp again.The error occured using the following specifications:
Ingres II 9.2.0 (int.lnx/118)NPTL
openSUSE 11.0 (i586)
Ingres II 9.2.0 (int.lnx/118)NPTL
CentOS release 5.2 (Final)
Ingres II 2.0/9808 (usl.us5/00)
5 7.1.1 i386 x86at SCO UNIX_SVR5
Ingres II 2.0/0308 (hpb.us5/00)
HP-UX 11.00
Of course there might be other specs that it has not been tested on.It seems that especially Linux'es are vulnerable to it.
Specs where there was no problem :
Ingres II 2.5/0011
SCO_SV 3.2 5.0.7 i386
Ingres II 2.5/0011
SCO_SV 3.2 5.0.5 i386
Ingres II 2.0/0308 (hpb.us5/00)
HP-UX 11.00
A request was send out to our local Ingres support who subsequently forwarded the issue to the Ingres Service desk, which replied. The reply was to
'nm $II_SYSTEM/ingres/lib/libingres.a | grep iiset
err' and look for the following entry
iiseterr.o:
00000a5f T iiseterr_',
which existed. And the next step was to check the contents of abfdyn.opt and abflnk.opt for some entries
(-linterp.1,-lframe.1,0lq.1 ...) which were also in tact.
It did not solve the problem though.
The problem lies in calling the 'iiseterr' function.Apparently, the linker on the machines with the problem cannot find a reference to it.
The related entry in the manual (r3 Documentation, Forms-based Application Development Tools, User Guide Runtime Error Processing M–3, Using iiseterr() in Ingres Applications,page 1243)
seterr ()
{
extern int myhandler();
iiseterr (myhandler);
return;
}
which in some specs links ok and in some not!
In examining some C header (eqpname.h in particular) files I've noticed that all references to iiseterr were IIseterr. Subsequently changing the entry to IIseterr solved the problem, the linking succeeded plus it did not break the specs that had no problem to begin with.
Comments