Build failure on Debian testing (cross to arm-none-eabi)

Build failure on Debian testing (cross to arm-none-eabi)

[Julian Brown]

Hi,

I'm getting a build failure during "make install" on Debian testing with 
binutils head, making a cross binutils to arm-none-eabi. This is the 
failure:

.../binutils-build$ make install
/bin/sh /home/jules/binutils/src/mkinstalldirs 
/home/jules/be-small-struct/prefix /home/jules/be-small-struct/prefix
make[1]: Entering directory `/home/jules/be-small-struct/binutils-build/bfd'
Making install in doc
make[2]: Entering directory 
`/home/jules/be-small-struct/binutils-build/bfd/doc'
gcc -c -I.. -I/home/jules/binutils/src/bfd/doc/.. 
-I/home/jules/binutils/src/bfd/doc/../../include 
-I/home/jules/binutils/src/bfd/doc/../../intl -I../../intl 
/home/jules/binutils/src/bfd/doc/chew.c
In file included from /home/jules/binutils/src/bfd/doc/chew.c:86:
/home/jules/binutils/src/bfd/sysdep.h:140: error: parse error before 
"ftello64"
/home/jules/binutils/src/bfd/sysdep.h:140: warning: data definition has 
no type or storage class
/home/jules/binutils/src/bfd/sysdep.h:152: error: parse error before 
"off64_t"
make[2]: *** [chew.o] Error 1
make[2]: Leaving directory 
`/home/jules/be-small-struct/binutils-build/bfd/doc'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/jules/be-small-struct/binutils-build/bfd'
make: *** [install-bfd] Error 2

The culprit is possibly this:

2005-04-20  Jerome Guitton  <guitton@gnat.com>

       * configure.in: Fix the check for basename declaration. Add check
       for declarations of ftello, ftello64, fseeko, fseeko64.
       * configure: Regenerate.
       * config.in: Ditto.
       * sysdep.h: If needed, declare ftello, ftello64, fseeko, fseeko64.

Cheers,

Julian

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Jerome Guitton]

Julian Brown (julian@codesourcery.com):

> In file included from /home/jules/binutils/src/bfd/doc/chew.c:86:
> /home/jules/binutils/src/bfd/sysdep.h:140: error: parse error before 
> "ftello64"
> /home/jules/binutils/src/bfd/sysdep.h:140: warning: data definition has 
> no type or storage class
> /home/jules/binutils/src/bfd/sysdep.h:152: error: parse error before 
> "off64_t"

Mmmm... Sorry for this one. I am able to reproduce it on a linux
host. I am investigating.

(It makes me think that I shall always try to do a 'make install'
before submitting a patch. That should avoid this kind of problems.)

-- 
Jerome

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Zack Weinberg]

Jerome Guitton <guitton@gnat.com> writes:
> Julian Brown (julian@codesourcery.com):
>> In file included from /home/jules/binutils/src/bfd/doc/chew.c:86:
>> /home/jules/binutils/src/bfd/sysdep.h:140: error: parse error before 
>> "ftello64"
>> /home/jules/binutils/src/bfd/sysdep.h:140: warning: data definition has 
>> no type or storage class
>> /home/jules/binutils/src/bfd/sysdep.h:152: error: parse error before 
>> "off64_t"
>
> Mmmm... Sorry for this one. I am able to reproduce it on a linux
> host. I am investigating.

This reminds me ... in the past, I've had problems with binutils'
habit of generating the documentation at install time.  For instance,
in a rather complicated environment where I built the software, then
handed it over to a sysadmin for installation, and he didn't have the
same $PATH as I did, and it blew up not being able to find either
makeinfo or cc.

GCC builds the documentation as part of "make all" - this works much
better in that sort of environment, and would have caught this bug as
well.  What do people think of changing it?

zw

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Hans-Peter Nilsson]

On Fri, 22 Apr 2005, Zack Weinberg wrote:
> This reminds me ... in the past, I've had problems with binutils'
> habit of generating the documentation at install time.  For instance,
> in a rather complicated environment where I built the software, then
> handed it over to a sysadmin for installation, and he didn't have the
> same $PATH as I did, and it blew up not being able to find either
> makeinfo or cc.
>
> GCC builds the documentation as part of "make all" - this works much
> better in that sort of environment, and would have caught this bug as
> well.  What do people think of changing it?

I think it has actually been fixed a while ago.

That's what *should* happen.  If it doesn't that's a bug.
(It's even a GNU coding standard item...)

brgds, H-P

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Zack Weinberg]

Hans-Peter Nilsson <hp@bitrange.com> writes:

> On Fri, 22 Apr 2005, Zack Weinberg wrote:
>> This reminds me ... in the past, I've had problems with binutils'
>> habit of generating the documentation at install time.  For instance,
>> in a rather complicated environment where I built the software, then
>> handed it over to a sysadmin for installation, and he didn't have the
>> same $PATH as I did, and it blew up not being able to find either
>> makeinfo or cc.
>>
>> GCC builds the documentation as part of "make all" - this works much
>> better in that sort of environment, and would have caught this bug as
>> well.  What do people think of changing it?
>
> I think it has actually been fixed a while ago.

Doesn't look like it -- after "make all" in a mainline binutils tree,
"make info" still does stuff.  (I'm about a week out of date, though.)

zw

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Thorsten Glaser]

Hans-Peter Nilsson dixit:

>(It's even a GNU coding standard item...)

Is depending install on all a GNU standard as well?

I think everybody should be able to do a 'gmake all'
before a 'gmake install', and it tends to break
systrace'd builds where write access to the object
directory is forbidden during installation.

//mirabile

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Hans-Peter Nilsson]

On Mon, 25 Apr 2005, Thorsten Glaser wrote:
> Hans-Peter Nilsson dixit:
>
> >(It's even a GNU coding standard item...)
>
> Is depending install on all a GNU standard as well?

I meant that "make all" must imply "make doc" (equivalent)
nothing else.  I'd suggest reading it yourself of course.

brgds, H-P

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Nick Clifton]

Hi Zack,

> This reminds me ... in the past, I've had problems with binutils'
> habit of generating the documentation at install time.  For instance,
> in a rather complicated environment where I built the software, then
> handed it over to a sysadmin for installation, and he didn't have the
> same $PATH as I did, and it blew up not being able to find either
> makeinfo or cc.
> 
> GCC builds the documentation as part of "make all" - this works much
> better in that sort of environment, and would have caught this bug as
> well.  What do people think of changing it?


I think that this would be a good idea, and I hope quite simple to do.

Would you like to submit a patch ?

Cheers
   Nick

Build documentation in 'make all' (was Re: Build failure on Debian testing (cross to arm-none-eabi))

[Zack Weinberg]

Nick Clifton <nickc@redhat.com> writes:
> Hi Zack,
>
>> GCC builds the documentation as part of "make all" - this works much
>> better in that sort of environment, and would have caught this bug as
>> well.  What do people think of changing it?
>
> I think that this would be a good idea, and I hope quite simple to do.
>
> Would you like to submit a patch ?

Here you go.  This turns out to be easy; a matter of a small handful of
lines here and there.

It's tempting to take 'cygnus' off the AUTOMAKE_OPTIONS lines, but
that would have much more far-reaching effects, which I am not
wanting to experiment with now.

zw

        * bfd/Makefile.am, binutils/Makefile.am, etc/Makefile.in
        * gas/Makefile.am: Have 'all' depend on 'info'.
        * ld/Makefile.am: Have 'all' depend on 'info' and 'ld.1'.
        * bfd/Makefile.in, binutils/Makefile.in, gas/Makefile.in
        * ld/Makefile.in: Regenerate.

===================================================================
Index: bfd/Makefile.am
--- bfd/Makefile.am	5 May 2005 14:37:01 -0000	1.155
+++ bfd/Makefile.am	18 May 2005 17:29:16 -0000
@@ -647,7 +647,7 @@ po/BLD-POTFILES.in: @MAINT@ Makefile $(B
 	  | LC_COLLATE= sort > tmp.bld \
 	  && mv tmp.bld $(srcdir)/po/BLD-POTFILES.in
 
-diststuff: info
+all diststuff: info
 
 # Various kinds of .o files to put in libbfd.a:
 # BFD_BACKENDS	Routines the configured targets need.
===================================================================
Index: binutils/Makefile.am
--- binutils/Makefile.am	14 Apr 2005 05:26:27 -0000	1.57
+++ binutils/Makefile.am	18 May 2005 17:29:17 -0000
@@ -297,6 +297,7 @@ EXTRA_DIST = arparse.c arparse.h arlex.c
 	syslex.c deflex.c defparse.h defparse.c rclex.c rcparse.h rcparse.c
 
 diststuff: $(EXTRA_DIST) info
+all: info
 
 DISTCLEANFILES = sysinfo sysroff.c sysroff.h \
 	site.exp site.bak
===================================================================
Index: etc/Makefile.in
--- etc/Makefile.in	2 Jan 2003 20:51:02 -0000	1.3
+++ etc/Makefile.in	18 May 2005 17:29:17 -0000
@@ -51,9 +51,7 @@ TEXIDIR = $(srcdir)/../texinfo
 INFOFILES = standards.info configure.info
 DVIFILES = standards.dvi configure.dvi
 
-all:
-
-# We want install to imply install-info as per GNU standards.
+all: info
 install: install-info
 
 uninstall:
===================================================================
Index: gas/Makefile.am
--- gas/Makefile.am	15 May 2005 18:19:39 -0000	1.110
+++ gas/Makefile.am	18 May 2005 17:29:17 -0000
@@ -475,6 +475,7 @@ stamp-mk.com: vmsconf.sh Makefile
 
 EXTRA_DIST = make-gas.com m68k-parse.c itbl-parse.c itbl-parse.h itbl-lex.c
 diststuff: $(EXTRA_DIST) info
+all: info
 
 DISTCLEANFILES = targ-cpu.h obj-format.h targ-env.h itbl-cpu.h cgen-desc.h
 
===================================================================
Index: ld/Makefile.am
--- ld/Makefile.am	17 May 2005 19:43:52 -0000	1.176
+++ ld/Makefile.am	18 May 2005 17:29:18 -0000
@@ -1697,6 +1697,7 @@ install-data-local: install-info
 # target is run by the taz target in ../Makefile.in.
 EXTRA_DIST = ldgram.c ldgram.h ldlex.c $(man_MANS)
 diststuff: info $(EXTRA_DIST)
+all: info ld.1
 
 DISTCLEANFILES = tdirs site.exp site.bak stringify.sed
 distclean-local:

Re: Build documentation in 'make all' (was Re: Build failure on Debian testing (cross to arm-none-eabi))

[Nick Clifton]

Hi Zack,

>         * bfd/Makefile.am, binutils/Makefile.am, etc/Makefile.in
>         * gas/Makefile.am: Have 'all' depend on 'info'.
>         * ld/Makefile.am: Have 'all' depend on 'info' and 'ld.1'.
>         * bfd/Makefile.in, binutils/Makefile.in, gas/Makefile.in
>         * ld/Makefile.in: Regenerate.

Approved - please apply.

Cheers
   Nick

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Jerome Guitton]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

Julian Brown (julian@codesourcery.com):

> I'm getting a build failure during "make install" on Debian testing with 
> binutils head, making a cross binutils to arm-none-eabi. This is the 
> failure:

OK. So, apparently off64_t is not defined at that point.

The only use of the fseeko family in bfd is in bfdio.c. It does not use
the type off64_t, but the bfd-specific type file_ptr. Unfortunately, this
type is defined in bfd.h, and I guess that sysdep.h should not depend on
bfd.h, right?

Moving the declarations to bfdio.c should help. Patch attached.
Can you confirm that it fixes the problem?

If so, is it OK to apply?

-- 
Jerome

[-- Attachment #2: bfdio.dif --]
[-- Type: text/plain, Size: 2082 bytes --]

2005-04-22  Jerome Guitton  <guitton@gnat.com>

	* sysdep.h: move declarations of ftello, fseeko, ftello64, fseek64...
	* bfdio.c: ... at the point where they are used.

Index: bfdio.c
===================================================================
RCS file: /cvs/src/src/bfd/bfdio.c,v
retrieving revision 1.9
diff -u -r1.9 bfdio.c
--- bfdio.c	3 Mar 2005 11:40:56 -0000	1.9
+++ bfdio.c	22 Apr 2005 13:46:16 -0000
@@ -43,9 +43,17 @@
 real_ftell (FILE *file)
 {
 #if defined (HAVE_FTELLO64)
+#if !HAVE_DECL_FTELLO64
+  extern file_ptr ftello64 (FILE *stream);
+#endif
   return ftello64 (file);
+
 #elif defined (HAVE_FTELLO)
+#if !HAVE_DECL_FTELLO
+  extern file_ptr ftello (FILE *stream);
+#endif
   return ftello (file);
+
 #else
   return ftell (file);
 #endif
@@ -55,9 +63,17 @@
 real_fseek (FILE *file, file_ptr offset, int whence)
 {
 #if defined (HAVE_FSEEKO64)
+#if !HAVE_DECL_FSEEKO64
+  extern int fseeko64 (FILE *stream, file_ptr offset, int whence);
+#endif
   return fseeko64 (file, offset, whence);
+
 #elif defined (HAVE_FSEEKO)
+#if !HAVE_DECL_FSEEKO
+  extern int fseeko (FILE *stream, file_ptr offset, int whence);
+#endif
   return fseeko (file, offset, whence);
+
 #else
   return fseek (file, offset, whence);
 #endif
Index: sysdep.h
===================================================================
RCS file: /cvs/src/src/bfd/sysdep.h,v
retrieving revision 1.9
diff -u -r1.9 sysdep.h
--- sysdep.h	20 Apr 2005 15:00:15 -0000	1.9
+++ sysdep.h	22 Apr 2005 13:46:16 -0000
@@ -129,30 +129,6 @@
 extern char *strstr ();
 #endif
 
-#ifdef HAVE_FTELLO
-#if !HAVE_DECL_FTELLO
-extern off_t ftello (FILE *stream);
-#endif
-#endif
-
-#ifdef HAVE_FTELLO64
-#if !HAVE_DECL_FTELLO64
-extern off64_t ftello64 (FILE *stream);
-#endif
-#endif
-
-#ifdef HAVE_FSEEKO
-#if !HAVE_DECL_FSEEKO
-extern int fseeko (FILE *stream, off_t offset, int whence);
-#endif
-#endif
-
-#ifdef HAVE_FSEEKO64
-#if !HAVE_DECL_FSEEKO64
-extern int fseeko64 (FILE *stream, off64_t offset, int whence);
-#endif
-#endif
-
 /* Define offsetof for those systems which lack it */
 
 #ifndef offsetof

Re: Build failure on Debian testing (cross to arm-none-eabi)

[H. J. Lu]

On Fri, Apr 22, 2005 at 03:49:45PM +0200, Jerome Guitton wrote:
> Julian Brown (julian@codesourcery.com):
> 
> > I'm getting a build failure during "make install" on Debian testing with 
> > binutils head, making a cross binutils to arm-none-eabi. This is the 
> > failure:
> 
> OK. So, apparently off64_t is not defined at that point.
> 

It has been fixed by

http://sourceware.org/ml/binutils/2005-04/msg00622.html


H.J.

Re: Build failure on Debian testing (cross to arm-none-eabi)

[Jerome Guitton]

H. J. Lu (hjl@lucon.org):

> It has been fixed by
> 
> http://sourceware.org/ml/binutils/2005-04/msg00622.html

OK, then I withdraw my patch. Thanks!

-- 
Jerome