gfc_offset question (32 vs. 64 bits)
Paul Brook
paul@codesourcery.com
Mon Dec 20 01:31:00 GMT 2004
On Wednesday 15 December 2004 18:36, Jonathan Lennox wrote:
> Steve Ellcey writes:
> > Does libgfortran (or any other GCC library) offer a way to pass compiler
> > option information into a library so it could be used to change the
> > libraries behaviour? I guess one could invent a new interface to do
> > this, I was wondering if there was any existing precedence.
>
> I think the most straightforward solution would just be to link in an
> additional library before libgfortran.
>
> My suggestion: define functions
>
> gfc_offset _gfortran_read_us_head(gfc_unit*);
> gfc_offset _gfortran_read_us_tail(gfc_unit*);
> void _gfortran_write_us_head(gfc_unit*, gfc_offset);
> void _gfortran_write_us_tail(gfc_unit*, gfc_offset);
>
> defined as extern functions in libgfortran, and call them from
> io/transfer.c as needed. (Tweak as necessary to get error handling right.)
>
> The standard versions can just read and write raw gfc_offset values, as
> now, assuming that's the desired standard behavior, but a user can
> optionally link in a library which defines alternate versions of these
> functions. E.g. "gfortran -o myprog myprog.o -lhp-style-unformatted-files".
>
> As long as these libraries are linked before libgfortran, the linker ought
> to pick up the user's versions of these functions, not libgfortran's.
> (This may require a bit of shared library hacking in order to get this to
> work on all shared library implementations.)
This seems a good idea. I'm a bit worried about the shared library issues
though.
I have different suggestion:
define a library call that specifies the library behaviour. The user can then
either call it explicitly from their code, or link in an object with an
__attribute__((constructor)) function that does it for them. The big
advantage is that it avoids all shared library and linking issues. The
downsite is that is doesn't allow a third party custom formats. However new
formats can easily be added to libgfortran with minimal maintenance cost, so
this probably isn't an issue.
Paul
More information about the Fortran
mailing list