Re: [Info-Ingres] abf problems on fortran program
Martin Bowes
Hi All,
After some hacking and reading of manuals and consulting venerable Fortran Gurus…I've managed to get the blasted thing to compile.
Sadly when I attempt to build the application image I get link errors:
abextract.obj:(.data+0x1728): undefined reference to `add_cr'
add_cr.obj: In function `add_cr__':add_cr.f:(.text+0x4c): undefined reference to `f_open'
:add_cr.f:(.text+0x69): undefined reference to `f_open'
:add_cr.f:(.text+0xa4): undefined reference to `s_rsfe'
:add_cr.f:(.text+0xd0): undefined reference to `do_fio'
:add_cr.f:(.text+0xeb): undefined reference to `e_rsfe'
…etc…
Anyone got any idea about these?
Marty
From: Martin Bowes
Sent: 21 January 2009 15:22
To: 'Ingres and related product discussion forum'
Subject: abf problems on fortran program
Hi All,
I'm trying to relocate a database and its applications from a VMS box running II2.6 to a linux box running 9.1.1.
By and large it seems to have gone well, but I have a fortran procedure returning integer which refuses to compile in the Linux version.
Any advice would be appreciated.
Attachment hold the source.
Errors are as follows:
Compiling 'add_cr.sf' . . .
E_AB001E Compilation failed
The compilation of '/user/ingres/dba/addtrial/add_cr.sf' failed with
status '1'. This could mean either that the compiler could not be run
or that it ran and returned an error.
ESQL add_cr.sf:
add_cr.f: In function `add_cr':
add_cr.f:13:
parameter (carriage_return = char(13))
^
Invalid declaration of or reference to symbol `char' at (^) [initially seen at (^)]
add_cr.f:18:
open (unit = main_channel, file = filename, status = 'old',
^
Unsupported OPEN control item at (^) -- ACTION=, ASSOCIATEVARIABLE=, BLOCKSIZE=, BUFFERCOUNT=, CARRIAGECONTROL=, DEFAULTFILE=, DELIM=, DISPOSE=, EXTENDSIZE=, INITIALSIZE=, KEY=, MAXREC=, NOSPANBLOCKS, ORGANIZATION=, PAD=, POSITION=, READONLY=, RECORDTYPE=, SHARED=, and USEROPEN= are not supported
add_cr.f:21:
open (unit = temp_channel, file = filename//'tmp',
1 2
Concatenation operator at (2) must operate on two scalar (not array) subexpressions, two function invocations returning character scalars, or a combination of both -- but the subexpression at (1) is of indeterminate length
add_cr.f:21:
open (unit = temp_channel, file = filename//'tmp',
1
add_cr.f:23: (continued):
1 status = 'scratch', carriagecontrol = 'list',
2
Conflicting I/O control specifications at (1) and (2)
add_cr.f:21:
open (unit = temp_channel, file = filename//'tmp',
^
Unsupported OPEN control item at (^) -- ACTION=, ASSOCIATEVARIABLE=, BLOCKSIZE=, BUFFERCOUNT=, CARRIAGECONTROL=, DEFAULTFILE=, DELIM=, DISPOSE=, EXTENDSIZE=, INITIALSIZE=, KEY=, MAXREC=, NOSPANBLOCKS, ORGANIZATION=, PAD=, POSITION=, READONLY=, RECORDTYPE=, SHARED=, and USEROPEN= are not supported
add_cr.f:45:
open (unit = main_channel, file = filename, status = 'old',
^
Unsupported OPEN control item at (^) -- ACTION=, ASSOCIATEVARIABLE=, BLOCKSIZE=, BUFFERCOUNT=, CARRIAGECONTROL=, DEFAULTFILE=, DELIM=, DISPOSE=, EXTENDSIZE=, INITIALSIZE=, KEY=, MAXREC=, NOSPANBLOCKS, ORGANIZATION=, PAD=, POSITION=, READONLY=, RECORDTYPE=, SHARED=, and USEROPEN= are not supported
Compilation failed.
Martin Bowes
MikeT
> Hi All,
>
> After some hacking and reading of manuals and consulting venerable
>
> Sadly when I attempt to build the application image I get link errors:
>
> :add_cr.f:(.text+0x69): undefined reference to `f_open'
> :add_cr.f:(.text+0xa4): undefined reference to `s_rsfe'
> :add_cr.f:(.text+0xd0): undefined reference to `do_fio'
> :add_cr.f:(.text+0xeb): undefined reference to `e_rsfe'
>
>
> Anyone got any idea about these?
>
> Marty
Marty,
IIRC abf compilation uses sepfortr, or maybe it's just for testing? At
any rate, a sample run is below.
$ sepfortr quel apxd
EQUEL apxd:
/usr/bin/f77 -o apxd.exe apxd.f -rdynamic /devsrc/main/toumi01/install/
build/ingres/lib/libingres.a -lpthread -lrt -lm -lc -lcrypt -ldl /lib/
libgcc_s.so.1
The unresolved symbols you listed should be in libg2c.a, and I'm under
the impression that g77 (a.k.a. f77) will use this without any -l
specification needed.
That said, since I'm under 60 years old, I'm no FORTRAN guru. ;)
MikeT
Martin Bowes
I have a two possibilities:
1. /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a
2. /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/32/libg2c.a
I'm running on II 9.1.1 (a64.lnx/105)NPTL so I assumed I needed the former.
I altered abflnk.opt to include:
-L/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3
-lg2c
The abfimage command has now resolved almost all the undefined references...
Building runnable image of addtrial . . .
abextract.obj:(.data+0x1728): undefined reference to `add_cr'
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.
But add_cr is the name of the fortran procedure that caused all this nonsense to begin with.
So I blew away the abf directory holding the application and rebuilt the image...and got the same result.
I can't find an abextract.* program in the source or in the application definition. What is it and why is it pissing me off?
Marty
Marty,
MikeT
_______________________________________________
Info-Ingres mailing list
Info-...@kettleriverconsulting.com
http://www.kettleriverconsulting.com/mailman/listinfo/info-ingres
nikosv
I was in a similar migration situation with a C procedure some time
ago and was getting the same error.
Please take a look at my post, just in case that it can help
http://groups.google.com/group/comp.databases.ingres/browse_thread/thread/57c1497f5504d8bd/bcec53592a5fc7fb?hl=en#bcec53592a5fc7fb
Michael Touloumtzis
> Hi Mike,
>
> I have a two possibilities:
> 1. /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/libg2c.a
> 2. /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/32/libg2c.a
>
> I'm running on II 9.1.1 (a64.lnx/105)NPTL so I assumed I needed the former.
> I altered abflnk.opt to include:
> -L/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3
> -lg2c
>
> The abfimage command has now resolved almost all the undefined references...
> 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.
>
> But add_cr is the name of the fortran procedure that caused all this nonsense to begin with.
>
> So I blew away the abf directory holding the application and rebuilt the image...and got the same result.
>
>
> Marty
Marty,
Still fighting this battle?
The abextract program is generated by abf. As for add_cr, I assume
your program is generating that link need? Is this for a crypto
function?
MikeT
Martin Bowes
> Still fighting this battle?
Yes. Plus I decided to raise an issue with the Corp about this as well.
> The abextract program is generated by abf.
Guessed that bit.
> As for add_cr, I assume your program is generating that link need?
> Is this for a crypto function?
It must be. But add_cr is not a crypto function, its actually taking a
report and making sure there are carriage returns at the end of the
lines. I'm not sure why its necessary, it might be something peculiar to
VMS, but given that its part of the application I'm hesitant to try and
unpick it at this point.
Marty
OldSchool
wrote:
this may have been asked elsewhere, if so apologies....
so add_cr has been defined in the abf app as a procedure, with the
correct return type?
Martin Bowes
Well done to Kristoff Picard in Tech support, who pointed out that due to a quirk in the g77 compiler the object was defined with a trailing underscore! So all I had to do was edit the procedure definition and alter the 'Symbol' field to inclde the trailing underscrore.
But, g77 wasn't quite done with us...the name add_cr already has an underscore, so g77 defines a symbol with TWO trailing underscores!!
A quick edit of the Symbol field to 'add_cr__' and now the blasted thing links beautifully!
Yay Team! Now that's why I pay for support!
Marty
-----Original Message-----
From: info-ingr...@kettleriverconsulting.com [mailto:info-ingr...@kettleriverconsulting.com] On Behalf Of OldSchool
Sent: 29 January 2009 16:38
To: info-...@kettleriverconsulting.com
Subject: Re: [Info-Ingres] abf problems on fortran program
nikosv
great!!
it seems that it was a naming conflict like the IIseterr and iiseterr
case.
Thanks for replying as I got more insight on it;I will check the
compilers on the machines that the problem occurred
OldSchool
>
> - Show quoted text -
Marty,
That's kind of the direction I was headed. Ran into similar problems
w/ Ingres 6.2 (or was it 6.4?) on DGUX many moons ago, but couldn't
recall the exact details. When the opportunity presents, you might
take a gander at the "-fno_underscoring" option
discussed in the g77 man page. I'm not sure if that would help or
hurt in your situation.....or if sleeping dogs should be let lie.
as I recall, similar problems exist in a *lot* of mixed language
calling conventions.
Best wishes....
Martin Bowes
I've been warned off that option as it might cause lots of damage to all the hidden internals.
This seems to be a case of letting sleeping dogs lie.
Marty
Marty,
Best wishes....
Kristoff
underscoring is not recommended unless ....." (see the man pages)
However, I tested it anyway by changing utcom.def. When you do this
you run immediateley into a new problem, missing several functions in
libingresetc, because of a missing underscore. (they are defined with
that underscore ....)
Cheers
Kristoff
OldSchool
i kinda suspected as much....thx
nikosv
A bit off topic but still relevant in the broader sense....
Elaborating more on the IIseterr/iiseterr naming conflict by doing
some research on the symbol tables inside archive library libingres.a
The following entry is from the library implementation that will
compile with 'iiseterr'
libingres.a:iiuflibq.o:00000cf0 T iiseterr_
libingres.a:iiuflbqL.o:00000cf0 T iiseterr
libingres.a:iiaclibq.o:000008a0 T IIpseterr
we see that there are three implementations of iiseterr each one in a
different library, thus any of the three can be used in the source
code and will compile fine
In the offending implementations where the undefined reference error
occurred there is no 'iiseterr' entry (as in the manual) for any
library contained in libingres.a; however there is an IIseterr entry
and that is why when capitalizing both i's the symbol can be found and
hence compile.
(it would compile with 'iiseterr_' as well)
libingres.a:iiseterr.o:00000000 T IIseterr
libingres.a:iiuflibq.o:00000a5f T iiseterr_
(a refresher on the issue ):
http://groups.google.com/group/comp.databases.ingres/browse_thread/thread/57c1497f5504d8bd/bcec53592a5fc7fb?hl=en#bcec53592a5fc7fb
)