[RFA] Fix bin2c executable generation for cross-generation

[RFA] Fix bin2c executable generation for cross-generation

[Pierre Muller]

  I was trying to compile binutils (under others) for mingw64
on cygwin.

 I used
../src/configure --host=x86_64-w64-mingw32 CFLAGS="-gstabs+ -O0"
--disable-libgui --disable-gdbtk --enable-targets=all

make all-gdb all-binutils all-gas all-ld


  It failed on bin2c because this is a executable that is built
using gcc compiler instead of x86_64-w64-mingw32-gcc
but the compilation still used $(LIBINTL).
 $(LIBINTL) is set to the just compiled library ../intl/libintl.a
which is compiled for w64 target, not cygwin
hence the build failure.

 The patch below uses -lintl instead of $(LIBINTL)
for bin2c$(EXEEXT_FOR_BUILD) rule.
 This allowed me to complete this build.


  Is this patch OK?

Pierre Muller

PS: I have no automake 2.63,
but I suppose that running it wouldn't change anything else
for that change, no?

ChangeLog entry:

2010-11-04  Pierre Muller  <muller@ics.u-strasbg.fr>

	* Makefile.am (bin2c rule): Replace $(LIBINTL) by -lintl
	* Makefile.in: Update accordingly.



Index: Makefile.am
===================================================================
RCS file: /cvs/src/src/binutils/Makefile.am,v
retrieving revision 1.125
diff -u -p -r1.125 Makefile.am
--- Makefile.am	25 May 2010 14:02:38 -0000	1.125
+++ Makefile.am	4 Nov 2010 12:41:40 -0000
@@ -274,7 +274,7 @@ sysinfo.@OBJEXT@: sysinfo.c
 	fi
 
 bin2c$(EXEEXT_FOR_BUILD): $(LIBINTL_DEP)
-	$(CC_FOR_BUILD) -o $@ $(AM_CPPFLAGS) $(AM_CFLAGS)
$(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) $(srcdir)/bin2c.c
$(srcdir)/version.c $(LIBINTL)
+	$(CC_FOR_BUILD) -o $@ $(AM_CPPFLAGS) $(AM_CFLAGS)
$(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) $(srcdir)/bin2c.c
$(srcdir)/version.c -lintl
 
 embedspu: embedspu.sh
 	sed
"s@^program_transform_name=@program_transform_name=$(program_transform_name)
@" < $< > $@
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/binutils/Makefile.in,v
retrieving revision 1.149
diff -u -p -r1.149 Makefile.in
--- Makefile.in	25 May 2010 14:02:38 -0000	1.149
+++ Makefile.in	4 Nov 2010 12:41:40 -0000
@@ -1226,7 +1226,7 @@ sysinfo.@OBJEXT@: sysinfo.c
 	fi
 
 bin2c$(EXEEXT_FOR_BUILD): $(LIBINTL_DEP)
-	$(CC_FOR_BUILD) -o $@ $(AM_CPPFLAGS) $(AM_CFLAGS)
$(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) $(srcdir)/bin2c.c
$(srcdir)/version.c $(LIBINTL)
+	$(CC_FOR_BUILD) -o $@ $(AM_CPPFLAGS) $(AM_CFLAGS)
$(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) $(srcdir)/bin2c.c
$(srcdir)/version.c -lintl
 
 embedspu: embedspu.sh
 	sed
"s@^program_transform_name=@program_transform_name=$(program_transform_name)
@" < $< > $@

Re: [RFA] Fix bin2c executable generation for cross-generation

[Tristan Gingold]

On Nov 4, 2010, at 4:29 PM, Pierre Muller wrote:

>  I was trying to compile binutils (under others) for mingw64
> on cygwin.
> 
> I used
> ../src/configure --host=x86_64-w64-mingw32 CFLAGS="-gstabs+ -O0"
> --disable-libgui --disable-gdbtk --enable-targets=all
> 
> make all-gdb all-binutils all-gas all-ld
> 
> 
>  It failed on bin2c because this is a executable that is built
> using gcc compiler instead of x86_64-w64-mingw32-gcc
> but the compilation still used $(LIBINTL).
> $(LIBINTL) is set to the just compiled library ../intl/libintl.a
> which is compiled for w64 target, not cygwin
> hence the build failure.
> 
> The patch below uses -lintl instead of $(LIBINTL)
> for bin2c$(EXEEXT_FOR_BUILD) rule.
> This allowed me to complete this build.
> 
> 
>  Is this patch OK?

I don't think so because libintl is not required (ie you can build with --disable-libintl).
I can't find the issue but why this concerns only bin2c ?

Tristan.

RE: [RFA] Fix bin2c executable generation for cross-generation

[Pierre Muller]

> The patch below uses -lintl instead of $(LIBINTL)
> for bin2c$(EXEEXT_FOR_BUILD) rule.
> This allowed me to complete this build.
> 
> 
>  Is this patch OK?

I don't think so because libintl is not required (ie you can build with
--disable-libintl).
I can't find the issue but why this concerns only bin2c ?


Hi Tristan,

  The fact is that it is the only rule that
uses $(LIBINTL) for a rule that has to be build 
with build gcc, while $(LIBINTL) is a host file,
thus of incompatible type.

  Should "--disable-libintl" apply to host or to build
or to both?

  If you know how to change -lintl into "" if --disable-libintl
is set, this would be fine for me, but I am still not
really at ease when it comes to configure subtleties.

  Anyhow, something needs to be changed...

Pierre
 
PS: Maybe we should add a LIBINTL_FOR_BUILD to configure?

Re: [RFA] Fix bin2c executable generation for cross-generation

[Tristan Gingold]

On Nov 4, 2010, at 4:48 PM, Pierre Muller wrote:

>> The patch below uses -lintl instead of $(LIBINTL)
>> for bin2c$(EXEEXT_FOR_BUILD) rule.
>> This allowed me to complete this build.
>> 
>> 
>> Is this patch OK?
> 
> I don't think so because libintl is not required (ie you can build with
> --disable-libintl).
> I can't find the issue but why this concerns only bin2c ?
> 
> 
> Hi Tristan,
> 
>  The fact is that it is the only rule that
> uses $(LIBINTL) for a rule that has to be build 
> with build gcc, while $(LIBINTL) is a host file,
> thus of incompatible type.

Right.

>  Should "--disable-libintl" apply to host or to build
> or to both?
> 
>  If you know how to change -lintl into "" if --disable-libintl
> is set, this would be fine for me, but I am still not
> really at ease when it comes to configure subtleties.

Neither I am...

>  Anyhow, something needs to be changed...

Alan should know much more than me about this tool, but
if this is a build-tool only, I think we could simply remove its dependency on libintl.
(On the other side I don't see any use of it).
If this is a normal tool, we can simply treat it like the other binutils.

Tristan.

Re: [RFA] Fix bin2c executable generation for cross-generation

[Ralf Wildenhues]

> On Nov 4, 2010, at 4:48 PM, Pierre Muller wrote:
> 
> >> The patch below uses -lintl instead of $(LIBINTL)
> >> for bin2c$(EXEEXT_FOR_BUILD) rule.

The patch is not right, as was already noted.

One proper solution would be to let toplevel create a build-$build/intl
if needed, consider whether --{en,dis}able-libintl should apply both to
build as well as to host tools, or add an --enable-build-libintl switch;
then rename affected variables before/after sourcing the appropriate
config.intl files from ../intl and ../build-$build/intl, to something
like LIBINTL_DEPS_FOR_BUILD etc.  Then we only remain at the problem
that bin2c.c includes sysdeps.h which leads to inclusion of config.h
which contains data for the host not the build ...

Since this is a really trivial build tool that is never installed and
that shouldn't print any localized stuff except in --help output, how
about removing i18n for it, and simplifying it to the point that it
needs not include config.h any more?

Cheers,
Ralf

[RFC] Change bin2c binary to target tool (was [RFA] Fix bin2c executable generation for cross-generation)

[Pierre Muller]

> -----Message d'origine-----
> De : binutils-owner@sourceware.org [mailto:binutils-
> owner@sourceware.org] De la part de Ralf Wildenhues
> Envoyé : jeudi 4 novembre 2010 19:50
> À : Tristan Gingold
> Cc : Pierre Muller; binutils@sourceware.org
> Objet : Re: [RFA] Fix bin2c executable generation for cross-generation
> 
> > On Nov 4, 2010, at 4:48 PM, Pierre Muller wrote:
> >
> > >> The patch below uses -lintl instead of $(LIBINTL)
> > >> for bin2c$(EXEEXT_FOR_BUILD) rule.
> 
> The patch is not right, as was already noted.
> 
> One proper solution would be to let toplevel create a build-$build/intl
> if needed, consider whether --{en,dis}able-libintl should apply both to
> build as well as to host tools, or add an --enable-build-libintl
> switch;
> then rename affected variables before/after sourcing the appropriate
> config.intl files from ../intl and ../build-$build/intl, to something
> like LIBINTL_DEPS_FOR_BUILD etc.  Then we only remain at the problem
> that bin2c.c includes sysdeps.h which leads to inclusion of config.h
> which contains data for the host not the build ...
> 
> Since this is a really trivial build tool that is never installed and
> that shouldn't print any localized stuff except in --help output, how
> about removing i18n for it, and simplifying it to the point that it
> needs not include config.h any more?


  The major point is that I do not even understand why this is
a 'build' tool rather than a 'target' tool.

  Maybe it was used at some point in the past to build 
other target binaries like sysinfo$(EXEEXT_FOR_BUILD)
which is used to create sysroff.c source.

  As it isn't used anymore, it has no use as a build tool,
thus I would rather transform this into a target tool...

  Any opinion on this proposal?

Pierre Muller

Re: [RFC] Change bin2c binary to target tool (was [RFA] Fix bin2c executable generation for cross-generation)

[Alan Modra]

On Fri, Nov 05, 2010 at 08:54:09AM +0100, Pierre Muller wrote:
>   As it isn't used anymore

See ld/Makefile.am.  I think Ralf's suggestion of simplifying bin2c
is the way to go.

	* bin2c.c: Remove internationalization and version report.
	* Makefile.am: Update bin2c rule.
	* Makefile.in: Regenerate.

Index: binutils/bin2c.c
===================================================================
RCS file: /cvs/src/src/binutils/bin2c.c,v
retrieving revision 1.5
diff -u -p -r1.5 bin2c.c
--- binutils/bin2c.c	25 Aug 2008 04:38:13 -0000	1.5
+++ binutils/bin2c.c	5 Nov 2010 10:44:15 -0000
@@ -18,9 +18,9 @@
    Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
    02110-1301, USA.  */
 
-#include "sysdep.h"
-#include "bfd.h"
-#include "bucomm.h"
+#include <stdio.h>
+#include <stdlib.h>
+#include "binary-io.h"
 
 int
 main (int argc, char *argv[])
@@ -28,19 +28,9 @@ main (int argc, char *argv[])
   int c;
   int i;
 
-#if defined (HAVE_SETLOCALE) && defined (HAVE_LC_MESSAGES)
-  setlocale (LC_MESSAGES, "");
-#endif
-#if defined (HAVE_SETLOCALE)
-  setlocale (LC_CTYPE, "");
-#endif
-  bindtextdomain (PACKAGE, LOCALEDIR);
-  textdomain (PACKAGE);
-
   if (argc != 1)
     {
       int ishelp = 0;
-      int isvers = 0;
       FILE *stream;
 
       if (argc == 2 && argv[1][0] == '-')
@@ -49,15 +39,11 @@ main (int argc, char *argv[])
 	  if (*opt == '-')
 	    ++opt;
 	  ishelp = *opt == 'h' || *opt == 'H';
-	  isvers = *opt == 'v' || *opt == 'V';
 	}
 
-      if (isvers)
-	print_version ("bin2c");
-
       stream = ishelp ? stdout : stderr;
-      fprintf (stream, _("Usage: %s < input_file > output_file\n"), argv[0]);
-      fprintf (stream, _("Prints bytes from stdin in hex format.\n"));
+      fprintf (stream, "Usage: %s < input_file > output_file\n", argv[0]);
+      fprintf (stream, "Prints bytes from stdin in hex format.\n");
       exit (!ishelp);
     }
 
Index: binutils/Makefile.am
===================================================================
RCS file: /cvs/src/src/binutils/Makefile.am,v
retrieving revision 1.125
diff -u -p -r1.125 Makefile.am
--- binutils/Makefile.am	25 May 2010 14:02:38 -0000	1.125
+++ binutils/Makefile.am	5 Nov 2010 10:44:15 -0000
@@ -273,8 +273,8 @@ sysinfo.@OBJEXT@: sysinfo.c
 	  $(CC_FOR_BUILD) -c -I. $(AM_CFLAGS) $(CFLAGS_FOR_BUILD) $(NO_WERROR) $(srcdir)/sysinfo.c ; \
 	fi
 
-bin2c$(EXEEXT_FOR_BUILD): $(LIBINTL_DEP)
-	$(CC_FOR_BUILD) -o $@ $(AM_CPPFLAGS) $(AM_CFLAGS) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) $(srcdir)/bin2c.c $(srcdir)/version.c $(LIBINTL)
+bin2c$(EXEEXT_FOR_BUILD): bin2c.c
+	$(CC_FOR_BUILD) -o $@ $(AM_CPPFLAGS) $(AM_CFLAGS) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) $(srcdir)/bin2c.c
 
 embedspu: embedspu.sh
 	sed "s@^program_transform_name=@program_transform_name=$(program_transform_name)@" < $< > $@

-- 
Alan Modra
Australia Development Lab, IBM

Re: [RFC] Change bin2c binary to target tool (was [RFA] Fix bin2c executable generation for cross-generation)

[Tristan Gingold]

On Nov 5, 2010, at 11:49 AM, Alan Modra wrote:

> On Fri, Nov 05, 2010 at 08:54:09AM +0100, Pierre Muller wrote:
>>  As it isn't used anymore
> 
> See ld/Makefile.am.

Ah thanks, I didn't look far enough.

>  I think Ralf's suggestion of simplifying bin2c
> is the way to go.

Do you want me to apply it on the release branch ?

Tristan.