public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland AT frob.com>
To: Ian Lance Taylor <ian AT zembu.com>
Cc: John.Barry AT eso.org, binutils AT sourceware.cygnus.com
Subject: Re: strange compile problem
Date: Mon, 13 Sep 1999 12:39:00 -0000	[thread overview]
Message-ID: <199909131939.PAA31675@frob.com> (raw)
In-Reply-To: <19990913185821.30628.qmail@daffy.airs.com>

>    From: John Barry <jbarry@eso.org>
>    Date: Mon, 13 Sep 1999 20:49:34 +0200 (MET DST)
> 
>    >    ../../binutils-2.9.5.0.12/bfd/libbfd.c: In function `bfd_stat':
>    >    ../../binutils-2.9.5.0.12/bfd/libbfd.c:638: argument `statbuf' doesn't match prototype
>    >    ../../binutils-2.9.5.0.12/bfd/bfd.h:482: prototype declaration
>    > 
>    >    extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));
>    > 
>    > I don't see that with the current development sources.  Do you see it
>    > with the snapshot from the Cygnus site, or just with 2.9.5.0.12 (which
>    > is a GNU/Linux specific release)?
> 
>    I've been getting this with every version of binutils I've built up since I
>    started using -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64, this includes
>    2.9.1 and every snapshop I've downloaded from cygnus. It's a Solaris only
>    issue, didn't happen when I built it on a hppa2.0 Visualise C 3000
> 
> You can probably fix it by adding
> 
> #include <sys/types.h>
> #include <sys/stat.h>
> 
> near the top of bfd/bfd-in2.h.
> 
> I'm somewhat uncomfortable with requiring every program which includes
> bfd.h to also include those files.  Unfortunately, the only other
> choice is probably to change the two uses of struct stat * to void *,
> instead, and thus lose type checking.

I would be inclined to warn away from this.  In fact, I think something
more comprehensive needs to be done in people are using -D_FILE_OFFSET_BITS=64.
(Note that newer glibc versions also support this, not just Solaris.)

Since bfd_stat is a user-visible function in -lbfd, the type used in its
interface needs to be well-specified for all users for the library, not
just code in the binutils tree.

The -D_FILE_OFFSET_BITS=64 setting changes the meaning of `struct stat' in
the source code (along with off_t et al, and which libc functions you get
for fstat et al).  So, the same setting must be used when building libbfd
and when building anything to be linked against libbfd.

Note that -D_LARGEFILE64_SOURCE=1 gives you a parallel set of `struct stat64',
off64_t, fstat64, et al.  So this makes it always possible to use the 64-bit
types, even in 32-bit mode (i.e. _FILE_OFFSET_BITS=32, which is usually the
default).  As far as I am aware, there is no *32 set of names--so there is no
way you can use the 32-bit types when in _FILE_OFFSET_BITS=64 mode.

Since this two-way 32/64-bit interface is quickly taking over the world, I
think the bfd interface should address it directly in some way.  Otherwise
there will just be mayhem as people try to choose what flavor to compile their
world and figure out how each libbfd they install was compiled.

The simplest alternative, naturally, is the official "Don't do that"; that is,
let it be said that if thy compiler configuration and precise set of tweaky
compatibility options of which they define a new one every three and half
minutes, used to compile a bfd-using program, strays in the slightest from
that used to compiled bfd, ye shall be smote.  And if bfd was compiled by thy
vendor and thou knowest not what the bleeding hell they did, just consider
thyself preemptively smote on principle.

The only reasonable alternative I see is to make bfd fully "LFS-aware", as the
youngin's call it.  It doesn't have to be too painful.  You can refer to both
`struct stat' and `struct stat64' as declared incomplete types, even if in the
end one of them is never defined at all.  bfd.h can do:

	struct stat;
	struct stat64;
	#if _FILE_OFFSET_BITS - 0 == 64
	#define bfd_stat bfd_stat64
	#else
	extern int bfd_stat64 PARAMS ((bfd *abfd, struct stat64 *));
	#endif
	extern int bfd_stat PARAMS ((bfd *abfd, struct stat *));

Then internally, BFD should be compiled with _LARGEFILE64_SOURCE but
_FILE_OFFSET_BITS=32.  bfd_stat takes a (32-bit mode) struct stat,
while bfd_stat64 takes a struct stat64 (which is the same as 64-bit mode's
struct stat).

This should let 32-bit mode callers' source use bfd_stat or bfd_stat64 and get
both flavors, and let 64-bit mode callers' source use bfd_stat for 64-bit
flavor.

  reply	other threads:[~1999-09-13 12:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-13 11:50 John Barry
1999-09-13 11:58 ` Ian Lance Taylor
1999-09-13 12:39   ` Roland McGrath [this message]
1999-09-13 12:53     ` Roland McGrath
1999-09-13 13:13     ` John Barry
  -- strict thread matches above, loose matches on Subject: below --
1999-09-13 10:14 John Barry
1999-09-13 11:23 ` Ian Lance Taylor
1999-09-13  6:54 John Barry
1999-09-13  9:12 ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199909131939.PAA31675@frob.com \
    --to=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).