PATCH: Handle the shared libgcc is a system library

PATCH: Handle the shared libgcc is a system library

[H . J . Lu]

This patch detects if there is a system shared libgcc in /lib or
/usr/lib. If it detects one, the shared libgcc will be installed
$(libsubdir) so that it won't override the system one by accident.

I also added --release/-dumprelease since I found --version couldn't
tell the different releases of the same version. It can be used to
install libgcc_s.so into /lib

# cp `gcc --print-file-name=libgcc_s.so.1` /lib/libgcc_s-`gcc --release`.so
# ln -sf libgcc_s-`gcc --release`.so /lib/libgcc_s.so.1

so that there is always a libgcc_s.so.1 available at any time.


H.J.
---
2001-07-01  H.J. Lu  (hjl@gnu.org)

	* configure.in (slibdir): Set according to if the shared libgcc
	library is a system shared library.
	* configure: Rebuild.

	* gcc.c (compiler_release): New string for the compiler
	release.
	(option_map): Add --release/-dumprelease.
	(display_help): Add -dumprelease.
	(process_command): Initialize compiler_release and handle
	-dumprelease.

--- gcc/configure.in.glibc	Wed Jun 13 13:36:24 2001
+++ gcc/configure.in	Sun Jul  1 10:01:13 2001
@@ -1945,14 +1945,33 @@ AC_ARG_ENABLE(version-specific-runtime-l
 
 AC_ARG_WITH(slibdir,
 [  --with-slibdir=DIR      shared libraries in DIR [LIBDIR]],
-slibdir="$with_slibdir",
+slibdir="$with_slibdir",[
 if test "${enable_version_specific_runtime_libs+set}" = set; then
   slibdir='$(libsubdir)'
 elif test "$host" != "$target"; then
   slibdir='$(build_tooldir)/lib'
 else
   slibdir='$(libdir)'
-fi)
+  if test "$build" = "$target"; then
+    # For systems where there is the shared libgcc in /lib or /usr/lib,
+    # we assume it is a system library come from the system vendor, we
+    # install our shared libgcc into $(libsubdir). We only check the
+    # system shared libgcc for the native build.
+    # FIXME: Need to check if the system shared libgcc library is
+    #	     really ok.
+    if test -e /lib/libgcc_s.so || test -e /usr/lib/libgcc_s.so; then
+      slibdir='$(libsubdir)'
+    fi
+  else
+    # For the native compiler built by canadian cross build, we install
+    # our shared libgcc into /lib if it is used as the system compiler.
+    case $target in
+    *-linux*)
+      slibdir="/lib"
+    ;;
+    esac
+  fi
+fi])
 AC_SUBST(slibdir)
 
 # Nothing to do for FLOAT_H, float_format already handled.
--- gcc/gcc.c.glibc	Tue Jun 12 14:38:51 2001
+++ gcc/gcc.c	Sun Jul  1 09:34:02 2001
@@ -157,6 +157,10 @@ static int save_temps_flag;
 
 static const char *compiler_version;
 
+/* The compiler release. */
+
+static const char *compiler_release;
+
 /* The target version specified with -V */
 
 static const char *spec_version = DEFAULT_TARGET_VERSION;
@@ -898,6 +902,7 @@ struct option_map option_map[] =
    {"--user-dependencies", "-MM", 0},
    {"--verbose", "-v", 0},
    {"--version", "-dumpversion", 0},
+   {"--release", "-dumprelease", 0},
    {"--warn-", "-W", "*j"},
    {"--write-dependencies", "-MD", 0},
    {"--write-user-dependencies", "-MMD", 0},
@@ -2897,6 +2902,7 @@ display_help ()
     fputs (_("  (Use '-v --help' to display command line options of sub-processes)\n"), stdout);
   fputs (_("  -dumpspecs               Display all of the built in spec strings\n"), stdout);
   fputs (_("  -dumpversion             Display the version of the compiler\n"), stdout);
+  fputs (_("  -dumprelease             Display the release of the compiler\n"), stdout);
   fputs (_("  -dumpmachine             Display the compiler's target processor\n"), stdout);
   fputs (_("  -print-search-dirs       Display the directories in the compiler's search path\n"), stdout);
   fputs (_("  -print-libgcc-file-name  Display the name of the compiler's companion library\n"), stdout);
@@ -3022,7 +3028,7 @@ process_command (argc, argv)
   n_infiles = 0;
   added_libraries = 0;
 
-  /* Figure compiler version from version string.  */
+  /* Figure out compiler version from version string.  */
 
   compiler_version = temp1 = xstrdup (version_string);
 
@@ -3035,6 +3041,27 @@ process_command (argc, argv)
 	}
     }
 
+  /* Figure compiler release from version string.  */
+  compiler_release = temp1 = xstrdup (version_string);
+
+  for (; *temp1; ++temp1)
+    {
+      if (ISSPACE ((unsigned char) *temp1))
+	*temp1 = '-';
+      else if (*temp1 == '(')
+	{
+	  *temp1 = '\0';
+	  break;
+	}
+    }
+  for (--temp1; *temp1; --temp1)
+    {
+      if (*temp1 == '-')
+	*temp1 = '\0';
+      else
+	break;
+    }
+
   /* Set up the default search paths.  If there is no GCC_EXEC_PREFIX,
      see if we can create it from the pathname specified in argv[0].  */
 
@@ -3200,6 +3227,11 @@ process_command (argc, argv)
       else if (! strcmp (argv[i], "-dumpversion"))
 	{
 	  printf ("%s\n", spec_version);
+	  exit (0);
+	}
+      else if (! strcmp (argv[i], "-dumprelease"))
+	{
+	  printf ("%s\n", compiler_release);
 	  exit (0);
 	}
       else if (! strcmp (argv[i], "-dumpmachine"))

Re: PATCH: Handle the shared libgcc is a system library

[Daniel Jacobowitz]

On Sun, Jul 01, 2001 at 10:50:17AM -0700, H . J . Lu wrote:
> This patch detects if there is a system shared libgcc in /lib or
> /usr/lib. If it detects one, the shared libgcc will be installed
> $(libsubdir) so that it won't override the system one by accident.
> 
> I also added --release/-dumprelease since I found --version couldn't
> tell the different releases of the same version. It can be used to
> install libgcc_s.so into /lib
> 
> # cp `gcc --print-file-name=libgcc_s.so.1` /lib/libgcc_s-`gcc --release`.so
> # ln -sf libgcc_s-`gcc --release`.so /lib/libgcc_s.so.1
> 
> so that there is always a libgcc_s.so.1 available at any time.


Some comments....

> +  if test "$build" = "$target"; then

$build = $target is not the right test.  I've built cross compilers
where $build = $target != $host.  Sure, it's perverse, but that's life,
and that's supported.

> +    # For systems where there is the shared libgcc in /lib or /usr/lib,
> +    # we assume it is a system library come from the system vendor, we
> +    # install our shared libgcc into $(libsubdir). We only check the
> +    # system shared libgcc for the native build.
> +    # FIXME: Need to check if the system shared libgcc library is
> +    #	     really ok.
> +    if test -e /lib/libgcc_s.so || test -e /usr/lib/libgcc_s.so; then
> +      slibdir='$(libsubdir)'
> +    fi

First of all, I think you want to check the version with the SONAME
here.  Installing a libgcc_s.so.2 someday, if for some reason that
should happen, shouldn't be affected.  Also, the .so link is often in a
development package while the .so.1 link is really a system library.

Second of all, this introduces a gratuitous random behavior that I
really don't like.  SOMETIMES gcc will install the library in /lib? 
And sometimes it won't?  Especially with:

> +  else
> +    # For the native compiler built by canadian cross build, we install
> +    # our shared libgcc into /lib if it is used as the system compiler.
> +    case $target in
> +    *-linux*)
> +      slibdir="/lib"
> +    ;;
> +    esac
> +  fi

So if I do a host-x-host cross, it'll automatically go into /lib, but
not otherwise?

And I regularly build compilers that are not meant to be installed on
the system that builds them.  Existance checks in /lib on the build
system are worse than useless here.  There's dozens of different build
systems that build from the same spec file.

And even worse, if you install libgcc_s in $(libsubdir), it will be
linked against but not found by the dynamic linker.  That's never going
to be the right solution.


If you really want to do automagic configuration based on the build
system, at least provide an option to cleanly ignore your magic. 
Something like --with-install-system-libgcc.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH: Handle the shared libgcc is a system library

[H . J . Lu]

On Sun, Jul 01, 2001 at 12:33:57PM -0700, Daniel Jacobowitz wrote:
> Some comments....
> 
> > +  if test "$build" = "$target"; then
> 
> $build = $target is not the right test.  I've built cross compilers
> where $build = $target != $host.  Sure, it's perverse, but that's life,
> and that's supported.

A few lines above, there is

elif test "$host" != "$target"; then
  slibdir='$(build_tooldir)/lib'
else
  slibdir='$(libdir)'
  if test "$build" = "$target"; then

At this point, $host = $target. When $build = $target != $host, you
are building a cross compiler, slibdir is set to $(build_tooldir)/lib.

> 
> > +    # For systems where there is the shared libgcc in /lib or /usr/lib,
> > +    # we assume it is a system library come from the system vendor, we
> > +    # install our shared libgcc into $(libsubdir). We only check the
> > +    # system shared libgcc for the native build.
> > +    # FIXME: Need to check if the system shared libgcc library is
> > +    #	     really ok.
> > +    if test -e /lib/libgcc_s.so || test -e /usr/lib/libgcc_s.so; then
> > +      slibdir='$(libsubdir)'
> > +    fi
> 
> First of all, I think you want to check the version with the SONAME
> here.  Installing a libgcc_s.so.2 someday, if for some reason that
> should happen, shouldn't be affected.  Also, the .so link is often in a

SONAME only exists in ELF. the gcc developers have promised that
libgcc_s.so.1 will be here to stay. If there is a libgcc_s.so.2,
we may have a bigger problem than where libgcc_s.so.2 should be
installed.

> 
> > +  else
> > +    # For the native compiler built by canadian cross build, we install
> > +    # our shared libgcc into /lib if it is used as the system compiler.
> > +    case $target in
> > +    *-linux*)
> > +      slibdir="/lib"
> > +    ;;
> > +    esac
> > +  fi
> 
> So if I do a host-x-host cross, it'll automatically go into /lib, but
> not otherwise?

It won't automatically go anywhere. I don't think many people will do

# make install

for a canadian cross build. The possible usage is

# make install prefix=/var/tmp/gcc
# rm -f /var/tmp/gcc/lib/libgcc_s.so
# ln -s ../../lib/libgcc_s.so.1 /var/tmp/gcc/usr/lib/libgcc_s.so

In any case, you have to do some packaging than

# make install

for a canadian cross build.

> 
> And I regularly build compilers that are not meant to be installed on
> the system that builds them.  Existance checks in /lib on the build
> system are worse than useless here.  There's dozens of different build
> systems that build from the same spec file.

Well, it can be called cross build. It is handled differently.

> 
> And even worse, if you install libgcc_s in $(libsubdir), it will be
> linked against but not found by the dynamic linker.  That's never going
> to be the right solution.
> 

Why? It only gets installed in $(libsubdir) if there is a system
shared libgcc.

> 
> If you really want to do automagic configuration based on the build
> system, at least provide an option to cleanly ignore your magic. 
> Something like --with-install-system-libgcc.

I am not sure if gcc is ever designed for such a thing. When you do

# ./configure 
# make bootstrap
# make install

it assumes $build = $host = $target. If you want to do those 3 steps on
different machines, It may not work right since ./configure may detect
somethings which don't exist or aren't true on other machines. You are
better off with cross compile.


H.J.

Re: PATCH: Handle the shared libgcc is a system library

[Daniel Jacobowitz]

On Sun, Jul 01, 2001 at 01:40:16PM -0700, H . J . Lu wrote:
> On Sun, Jul 01, 2001 at 12:33:57PM -0700, Daniel Jacobowitz wrote:
> > Some comments....
> > 
> > > +  if test "$build" = "$target"; then
> > 
> > $build = $target is not the right test.  I've built cross compilers
> > where $build = $target != $host.  Sure, it's perverse, but that's life,
> > and that's supported.
> 
> A few lines above, there is
> 
> elif test "$host" != "$target"; then
>   slibdir='$(build_tooldir)/lib'
> else
>   slibdir='$(libdir)'
>   if test "$build" = "$target"; then
> 
> At this point, $host = $target. When $build = $target != $host, you
> are building a cross compiler, slibdir is set to $(build_tooldir)/lib.

Sorry.  That's what I get for not looking at the surrounding hundred
lines of context.

> > > +    # For systems where there is the shared libgcc in /lib or /usr/lib,
> > > +    # we assume it is a system library come from the system vendor, we
> > > +    # install our shared libgcc into $(libsubdir). We only check the
> > > +    # system shared libgcc for the native build.
> > > +    # FIXME: Need to check if the system shared libgcc library is
> > > +    #	     really ok.
> > > +    if test -e /lib/libgcc_s.so || test -e /usr/lib/libgcc_s.so; then
> > > +      slibdir='$(libsubdir)'
> > > +    fi
> > 
> > First of all, I think you want to check the version with the SONAME
> > here.  Installing a libgcc_s.so.2 someday, if for some reason that
> > should happen, shouldn't be affected.  Also, the .so link is often in a
> 
> SONAME only exists in ELF. the gcc developers have promised that
> libgcc_s.so.1 will be here to stay. If there is a libgcc_s.so.2,
> we may have a bigger problem than where libgcc_s.so.2 should be
> installed.

Read the rest of the paragraph.  The .so link may not be installed,
even if the system libgcc is.

> > > +  else
> > > +    # For the native compiler built by canadian cross build, we install
> > > +    # our shared libgcc into /lib if it is used as the system compiler.
> > > +    case $target in
> > > +    *-linux*)
> > > +      slibdir="/lib"
> > > +    ;;
> > > +    esac
> > > +  fi
> > 
> > So if I do a host-x-host cross, it'll automatically go into /lib, but
> > not otherwise?
> 
> It won't automatically go anywhere. I don't think many people will do
> 
> # make install
> 
> for a canadian cross build. The possible usage is
> 
> # make install prefix=/var/tmp/gcc
> # rm -f /var/tmp/gcc/lib/libgcc_s.so
> # ln -s ../../lib/libgcc_s.so.1 /var/tmp/gcc/usr/lib/libgcc_s.so
> 
> In any case, you have to do some packaging than
> 
> # make install
> 
> for a canadian cross build.

Certainly.  But it should be the same packaging that you have to do for
a native build on the $host=$target system, whenever possible.

> > And even worse, if you install libgcc_s in $(libsubdir), it will be
> > linked against but not found by the dynamic linker.  That's never going
> > to be the right solution.
> > 
> 
> Why? It only gets installed in $(libsubdir) if there is a system
> shared libgcc.

If you're going to take this stance, why install it at all?  The one in
$(libsubdir) will be found at link time but not at run time, which is
bad news.  If you want the system copy to be found at run time, find it
at link time also.

> > If you really want to do automagic configuration based on the build
> > system, at least provide an option to cleanly ignore your magic. 
> > Something like --with-install-system-libgcc.
> 
> I am not sure if gcc is ever designed for such a thing. When you do
> 
> # ./configure 
> # make bootstrap
> # make install
> 
> it assumes $build = $host = $target. If you want to do those 3 steps on
> different machines, It may not work right since ./configure may detect
> somethings which don't exist or aren't true on other machines. You are
> better off with cross compile.

Huh?  Of course.  I specify host and target quite explicitly. 
Sometimes, I build native ($host=$target) compilers for our embedded
x86 platforms on an x68 Debian host.  I don't want it picking up
anything about the build machine, and while it's a losing fight I'm
keeping up the effort.  It's especially challenging because programs
built by the "cross compiler" will run on the build system, and keeping
autoconf in the right frame of mind is hard enough.  But $build !=
$host.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH: Handle the shared libgcc is a system library

[H . J . Lu]

On Sun, Jul 01, 2001 at 02:10:33PM -0700, Daniel Jacobowitz wrote:
> > SONAME only exists in ELF. the gcc developers have promised that
> > libgcc_s.so.1 will be here to stay. If there is a libgcc_s.so.2,
> > we may have a bigger problem than where libgcc_s.so.2 should be
> > installed.
> 
> Read the rest of the paragraph.  The .so link may not be installed,
> even if the system libgcc is.

That is a good point. I think it should check libgcc_s.so.1, not
libgcc_s.so.

> > 
> > In any case, you have to do some packaging than
> > 
> > # make install
> > 
> > for a canadian cross build.
> 
> Certainly.  But it should be the same packaging that you have to do for
> a native build on the $host=$target system, whenever possible.

It is not always easy to do. I think /lib is an ok one for Linux.

> 
> > > And even worse, if you install libgcc_s in $(libsubdir), it will be
> > > linked against but not found by the dynamic linker.  That's never going
> > > to be the right solution.
> > > 
> > 
> > Why? It only gets installed in $(libsubdir) if there is a system
> > shared libgcc.
> 
> If you're going to take this stance, why install it at all?  The one in
> $(libsubdir) will be found at link time but not at run time, which is
> bad news.  If you want the system copy to be found at run time, find it
> at link time also.

I don't think it is a bad news. It happens all the time with
cross compiling. Also I have no idea what your libc.so.6 in
glibc 2.2 looks like when I send you my binary compiled against
my glibc 2.2. For all I know, you can have a link-time libc.so
with all the functions of the empty bodies. Neither the static
linker nor the dynamic linker will care.

> > I am not sure if gcc is ever designed for such a thing. When you do
> > 
> > # ./configure 
> > # make bootstrap
> > # make install
> > 
> > it assumes $build = $host = $target. If you want to do those 3 steps on
> > different machines, It may not work right since ./configure may detect
> > somethings which don't exist or aren't true on other machines. You are
> > better off with cross compile.
> 
> Huh?  Of course.  I specify host and target quite explicitly. 

It doesn't matter. The many features are detected by running
programss on the build machine.

> Sometimes, I build native ($host=$target) compilers for our embedded
> x86 platforms on an x68 Debian host.  I don't want it picking up
> anything about the build machine, and while it's a losing fight I'm
> keeping up the effort.  It's especially challenging because programs
> built by the "cross compiler" will run on the build system, and keeping
> autoconf in the right frame of mind is hard enough.  But $build !=
> $host.

You must have done something different. I have no problems with cross
compile, including weird ones like you described. On the other hand,
it was me who wrote those cross compile stuff in gcc. I guess I
know what I am doing :-).


H.J.

Re: PATCH: Handle the shared libgcc is a system library

[Neil Booth]

H . J . Lu wrote:-

> On the other hand, it was me who wrote those cross compile stuff in
> gcc. I guess I know what I am doing :-).

In that case, would you be so kind as to fully document it for those
of lesser knowledge like myself?

Neil.

Re: PATCH: Handle the shared libgcc is a system library

[Joseph S. Myers]

On Mon, 2 Jul 2001, Neil Booth wrote:

> H . J . Lu wrote:-
> 
> > On the other hand, it was me who wrote those cross compile stuff in
> > gcc. I guess I know what I am doing :-).
> 
> In that case, would you be so kind as to fully document it for those
> of lesser knowledge like myself?

Yes, I've been asking for a volunteer to handle merging the
cross-compilation documentation from install-old.texi into unified
up-to-date documentation in install.texi (which doesn't rely on external
FAQs or scripts to make sense and be used for building cross-compilers)  
for a month, and no-one has volunteered.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: PATCH: Handle the shared libgcc is a system library

[Alexandre Oliva]

On Jul  1, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> +    if test -e /lib/libgcc_s.so || test -e /usr/lib/libgcc_s.so; then

test -e is not portable (IIRC, it breaks at least with Tru64's
/bin/sh).  Please use test -f instead.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Handle the shared libgcc is a system library

[Alexandre Oliva]

On Jul  1, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> On Sun, Jul 01, 2001 at 12:33:57PM -0700, Daniel Jacobowitz wrote:
>> Some comments....
>> 
>> > +  if test "$build" = "$target"; then
>> 
>> $build = $target is not the right test.  I've built cross compilers
>> where $build = $target != $host.  Sure, it's perverse, but that's life,
>> and that's supported.

> A few lines above, there is

> elif test "$host" != "$target"; then
>   slibdir='$(build_tooldir)/lib'
> else
>   slibdir='$(libdir)'
>   if test "$build" = "$target"; then

> At this point, $host = $target. When $build = $target != $host, you
> are building a cross compiler, slibdir is set to $(build_tooldir)/lib.

Would you please add a comment explaining the dependence on the code
above and the inferences you're making?  This could help the next
person who chooses to modify that chunk of code get the whole
picture.

> SONAME only exists in ELF. the gcc developers have promised that
> libgcc_s.so.1 will be here to stay. If there is a libgcc_s.so.2,
> we may have a bigger problem than where libgcc_s.so.2 should be
> installed.

Indeed.

> I don't think many people will do

> # make install

> for a canadian cross build. The possible usage is

I'll concede that I'm not a typical user, but I often do it.

> # make install prefix=/var/tmp/gcc
> # rm -f /var/tmp/gcc/lib/libgcc_s.so
> # ln -s ../../lib/libgcc_s.so.1 /var/tmp/gcc/usr/lib/libgcc_s.so

How about creating the .so link only inside GCC's internal gcc-lib
sub-directory, but having the SONAME file installed in lib?

> Why? It only gets installed in $(libsubdir) if there is a system
> shared libgcc.

I fail to see the point of making this distinction.

Isn't your argument that having more than one copy of libgcc_s.so.1
can get the whole system unstable?  How does moving it change this
fact?  There will still be one more copy, and users are likely to add
GCC's internal library search path to ld.so.conf as well.  For one,
that's where the libobjc libraries are installed.  For another, that's
what they're going to do to make sure they're using the newer copy of
libgcc_s.so.1, or just because they had to do it on other OSs that
don't have libgcc_s.so.1 in /lib.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Handle the shared libgcc is a system library

[H . J . Lu]

On Mon, Jul 02, 2001 at 07:17:50AM +0100, Neil Booth wrote:
> H . J . Lu wrote:-
> 
> > On the other hand, it was me who wrote those cross compile stuff in
> > gcc. I guess I know what I am doing :-).
> 
> In that case, would you be so kind as to fully document it for those
> of lesser knowledge like myself?

I am afraid if I don't have the time and it has to be treated on a case
by case basis. If you have any specific questions on cross compiling to
Linux, I will be happy to help.

BTW, the key issue is the cross toolchain shouldn't even know anything
about the header files and libraries on the host machine. Many people
miss that.

BTW, I have a complete cross toolchain for Linux/mips hosted on RedHat
7.1. You can get it from

ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/

You can get some ideas from my toolchain source rpm.


H.J.

Re: PATCH: Handle the shared libgcc is a system library

[H . J . Lu]

On Mon, Jul 02, 2001 at 11:14:06AM -0300, Alexandre Oliva wrote:
> 
> > At this point, $host = $target. When $build = $target != $host, you
> > are building a cross compiler, slibdir is set to $(build_tooldir)/lib.
> 
> Would you please add a comment explaining the dependence on the code
> above and the inferences you're making?  This could help the next
> person who chooses to modify that chunk of code get the whole
> picture.

Ok. Added.

> 
> > I don't think many people will do
> 
> > # make install
> 
> > for a canadian cross build. The possible usage is
> 
> I'll concede that I'm not a typical user, but I often do it.

I removed that part.

> 
> Isn't your argument that having more than one copy of libgcc_s.so.1
> can get the whole system unstable?  How does moving it change this

More precisely, only the system libgcc_s.so.1 should be visible to the
system dynamic linker for the binaries come from the ditribution vendor.
I have many copies of libc.so.6 on my machine. It is ok as long as they
are not visible to the system dynamic linker. One word of caution, never
set DT_RPATH to "" in the system binaries :-).

> fact?  There will still be one more copy, and users are likely to add
> GCC's internal library search path to ld.so.conf as well.  For one,
> that's where the libobjc libraries are installed.  For another, that's
> what they're going to do to make sure they're using the newer copy of
> libgcc_s.so.1, or just because they had to do it on other OSs that
> don't have libgcc_s.so.1 in /lib.
> 

I can live with that. At least, the users should be aware that they are
tempering with the system library :-).

Here is an update on my last patch.

Thanks for all the comments.


H.J.
---
2001-07-02  H.J. Lu  (hjl@gnu.org)

	* configure.in (slibdir): Set according to if the shared libgcc
	library is a system shared library.
	* configure: Rebuild.

	* gcc.c (compiler_release): New string for the compiler
	release.
	(option_map): Add --release/-dumprelease.
	(display_help): Add -dumprelease.
	(process_command): Initialize compiler_release and handle
	-dumprelease.

--- gcc/configure.in.libgcc	Wed Jun 13 13:36:24 2001
+++ gcc/configure.in	Mon Jul  2 08:25:31 2001
@@ -1945,14 +1945,26 @@ AC_ARG_ENABLE(version-specific-runtime-l
 
 AC_ARG_WITH(slibdir,
 [  --with-slibdir=DIR      shared libraries in DIR [LIBDIR]],
-slibdir="$with_slibdir",
+slibdir="$with_slibdir",[
 if test "${enable_version_specific_runtime_libs+set}" = set; then
   slibdir='$(libsubdir)'
 elif test "$host" != "$target"; then
   slibdir='$(build_tooldir)/lib'
 else
+  # We are building a nativa compiler here since "$host" = "$target".
   slibdir='$(libdir)'
-fi)
+  if test "$build" = "$target"; then
+    # For systems where there is the shared libgcc in /lib or /usr/lib,
+    # we assume it is a system library come from the system vendor, we
+    # install our shared libgcc into $(libsubdir). We only check the
+    # system shared libgcc for the native build.
+    # FIXME: Need to check if the system shared libgcc library is
+    #	     really ok.
+    if test -e /lib/libgcc_s.so.1 || test -e /usr/lib/libgcc_s.so.1; then
+      slibdir='$(libsubdir)'
+    fi
+  fi
+fi])
 AC_SUBST(slibdir)
 
 # Nothing to do for FLOAT_H, float_format already handled.
--- gcc/gcc.c.libgcc	Tue Jun 12 14:38:51 2001
+++ gcc/gcc.c	Mon Jul  2 08:18:19 2001
@@ -157,6 +157,10 @@ static int save_temps_flag;
 
 static const char *compiler_version;
 
+/* The compiler release. */
+
+static const char *compiler_release;
+
 /* The target version specified with -V */
 
 static const char *spec_version = DEFAULT_TARGET_VERSION;
@@ -898,6 +902,7 @@ struct option_map option_map[] =
    {"--user-dependencies", "-MM", 0},
    {"--verbose", "-v", 0},
    {"--version", "-dumpversion", 0},
+   {"--release", "-dumprelease", 0},
    {"--warn-", "-W", "*j"},
    {"--write-dependencies", "-MD", 0},
    {"--write-user-dependencies", "-MMD", 0},
@@ -2897,6 +2902,7 @@ display_help ()
     fputs (_("  (Use '-v --help' to display command line options of sub-processes)\n"), stdout);
   fputs (_("  -dumpspecs               Display all of the built in spec strings\n"), stdout);
   fputs (_("  -dumpversion             Display the version of the compiler\n"), stdout);
+  fputs (_("  -dumprelease             Display the release of the compiler\n"), stdout);
   fputs (_("  -dumpmachine             Display the compiler's target processor\n"), stdout);
   fputs (_("  -print-search-dirs       Display the directories in the compiler's search path\n"), stdout);
   fputs (_("  -print-libgcc-file-name  Display the name of the compiler's companion library\n"), stdout);
@@ -3035,6 +3041,27 @@ process_command (argc, argv)
 	}
     }
 
+  /* Figure compiler release from version string.  */
+  compiler_release = temp1 = xstrdup (version_string);
+
+  for (; *temp1; ++temp1)
+    {
+      if (ISSPACE ((unsigned char) *temp1))
+	*temp1 = '-';
+      else if (*temp1 == '(')
+	{
+	  *temp1 = '\0';
+	  break;
+	}
+    }
+  for (--temp1; *temp1; --temp1)
+    {
+      if (*temp1 == '-')
+	*temp1 = '\0';
+      else
+	break;
+    }
+
   /* Set up the default search paths.  If there is no GCC_EXEC_PREFIX,
      see if we can create it from the pathname specified in argv[0].  */
 
@@ -3200,6 +3227,11 @@ process_command (argc, argv)
       else if (! strcmp (argv[i], "-dumpversion"))
 	{
 	  printf ("%s\n", spec_version);
+	  exit (0);
+	}
+      else if (! strcmp (argv[i], "-dumprelease"))
+	{
+	  printf ("%s\n", compiler_release);
 	  exit (0);
 	}
       else if (! strcmp (argv[i], "-dumpmachine"))

Re: PATCH: Handle the shared libgcc is a system library

[H . J . Lu]

On Mon, Jul 02, 2001 at 11:06:42AM -0300, Alexandre Oliva wrote:
> On Jul  1, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > +    if test -e /lib/libgcc_s.so || test -e /usr/lib/libgcc_s.so; then
> 
> test -e is not portable (IIRC, it breaks at least with Tru64's
> /bin/sh).  Please use test -f instead.
> 

Ooops. Missed this one. Another update.


H.J.
----
2001-07-02  H.J. Lu  (hjl@gnu.org)

	* configure.in (slibdir): Set according to if the shared libgcc
	library is a system shared library.
	* configure: Rebuild.

	* gcc.c (compiler_release): New string for the compiler
	release.
	(option_map): Add --release/-dumprelease.
	(display_help): Add -dumprelease.
	(process_command): Initialize compiler_release and handle
	-dumprelease.

--- gcc/configure.in.libgcc	Wed Jun 13 13:36:24 2001
+++ gcc/configure.in	Mon Jul  2 08:25:31 2001
@@ -1945,14 +1945,26 @@ AC_ARG_ENABLE(version-specific-runtime-l
 
 AC_ARG_WITH(slibdir,
 [  --with-slibdir=DIR      shared libraries in DIR [LIBDIR]],
-slibdir="$with_slibdir",
+slibdir="$with_slibdir",[
 if test "${enable_version_specific_runtime_libs+set}" = set; then
   slibdir='$(libsubdir)'
 elif test "$host" != "$target"; then
   slibdir='$(build_tooldir)/lib'
 else
+  # We are building a nativa compiler here since "$host" = "$target".
   slibdir='$(libdir)'
-fi)
+  if test "$build" = "$target"; then
+    # For systems where there is the shared libgcc in /lib or /usr/lib,
+    # we assume it is a system library come from the system vendor, we
+    # install our shared libgcc into $(libsubdir). We only check the
+    # system shared libgcc for the native build.
+    # FIXME: Need to check if the system shared libgcc library is
+    #	     really ok.
+    if test -f /lib/libgcc_s.so.1 || test -f /usr/lib/libgcc_s.so.1; then
+      slibdir='$(libsubdir)'
+    fi
+  fi
+fi])
 AC_SUBST(slibdir)
 
 # Nothing to do for FLOAT_H, float_format already handled.
--- gcc/gcc.c.libgcc	Tue Jun 12 14:38:51 2001
+++ gcc/gcc.c	Mon Jul  2 08:18:19 2001
@@ -157,6 +157,10 @@ static int save_temps_flag;
 
 static const char *compiler_version;
 
+/* The compiler release. */
+
+static const char *compiler_release;
+
 /* The target version specified with -V */
 
 static const char *spec_version = DEFAULT_TARGET_VERSION;
@@ -898,6 +902,7 @@ struct option_map option_map[] =
    {"--user-dependencies", "-MM", 0},
    {"--verbose", "-v", 0},
    {"--version", "-dumpversion", 0},
+   {"--release", "-dumprelease", 0},
    {"--warn-", "-W", "*j"},
    {"--write-dependencies", "-MD", 0},
    {"--write-user-dependencies", "-MMD", 0},
@@ -2897,6 +2902,7 @@ display_help ()
     fputs (_("  (Use '-v --help' to display command line options of sub-processes)\n"), stdout);
   fputs (_("  -dumpspecs               Display all of the built in spec strings\n"), stdout);
   fputs (_("  -dumpversion             Display the version of the compiler\n"), stdout);
+  fputs (_("  -dumprelease             Display the release of the compiler\n"), stdout);
   fputs (_("  -dumpmachine             Display the compiler's target processor\n"), stdout);
   fputs (_("  -print-search-dirs       Display the directories in the compiler's search path\n"), stdout);
   fputs (_("  -print-libgcc-file-name  Display the name of the compiler's companion library\n"), stdout);
@@ -3035,6 +3041,27 @@ process_command (argc, argv)
 	}
     }
 
+  /* Figure compiler release from version string.  */
+  compiler_release = temp1 = xstrdup (version_string);
+
+  for (; *temp1; ++temp1)
+    {
+      if (ISSPACE ((unsigned char) *temp1))
+	*temp1 = '-';
+      else if (*temp1 == '(')
+	{
+	  *temp1 = '\0';
+	  break;
+	}
+    }
+  for (--temp1; *temp1; --temp1)
+    {
+      if (*temp1 == '-')
+	*temp1 = '\0';
+      else
+	break;
+    }
+
   /* Set up the default search paths.  If there is no GCC_EXEC_PREFIX,
      see if we can create it from the pathname specified in argv[0].  */
 
@@ -3200,6 +3227,11 @@ process_command (argc, argv)
       else if (! strcmp (argv[i], "-dumpversion"))
 	{
 	  printf ("%s\n", spec_version);
+	  exit (0);
+	}
+      else if (! strcmp (argv[i], "-dumprelease"))
+	{
+	  printf ("%s\n", compiler_release);
 	  exit (0);
 	}
       else if (! strcmp (argv[i], "-dumpmachine"))

Re: PATCH: Handle the shared libgcc is a system library

[Neil Booth]

H . J . Lu wrote:-

> I am afraid if I don't have the time and it has to be treated on a case
> by case basis. If you have any specific questions on cross compiling to
> Linux, I will be happy to help.

It's only partly for my benefit, H.J.  We need it to be properly
documented for everyone's benefit, and you claimed you implemented it
and understand it well.

So, I think it would be good if you could at least make a start on
some good documentation of this stuff.  It doesn't have to be complete
or cover everything; once something reasonable has started it will be
easier to get others to update it and improve it.

Neil.

Re: PATCH: Handle the shared libgcc is a system library

[H . J . Lu]

On Mon, Jul 02, 2001 at 06:48:46PM +0100, Neil Booth wrote:
> H . J . Lu wrote:-
> 
> > I am afraid if I don't have the time and it has to be treated on a case
> > by case basis. If you have any specific questions on cross compiling to
> > Linux, I will be happy to help.
> 
> It's only partly for my benefit, H.J.  We need it to be properly
> documented for everyone's benefit, and you claimed you implemented it
> and understand it well.
> 
> So, I think it would be good if you could at least make a start on
> some good documentation of this stuff.  It doesn't have to be complete
> or cover everything; once something reasonable has started it will be
> easier to get others to update it and improve it.

Tell me where I should put it. I will see what I can do.


H.J.

Re: PATCH: Handle the shared libgcc is a system library

[Neil Booth]

H . J . Lu wrote:-

> Tell me where I should put it. I will see what I can do.

Well, you'd need to send it to gcc-patches of course.  I would put it
in doc/cross-compile.texi, or something similar.

Thanks,

Neil.

Re: PATCH: Handle the shared libgcc is a system library

[Joseph S. Myers]

On Mon, 2 Jul 2001, Neil Booth wrote:

> H . J . Lu wrote:-
> 
> > Tell me where I should put it. I will see what I can do.
> 
> Well, you'd need to send it to gcc-patches of course.  I would put it
> in doc/cross-compile.texi, or something similar.

It should go in doc/install.texi, along with the existing installation
documentation.  Ideally, it should cover everything the documentation in
doc/install-old.texi does, so the cross compilation documentation there
can go away; and it should cover enough of what the crossgcc FAQ covers
that there is no need for users to refer to that either.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: documentation for cross compiling.

[H . J . Lu]

On Mon, Jul 02, 2001 at 07:09:15PM +0100, Joseph S. Myers wrote:
> 
> It should go in doc/install.texi, along with the existing installation
> documentation.  Ideally, it should cover everything the documentation in
> doc/install-old.texi does, so the cross compilation documentation there
> can go away; and it should cover enough of what the crossgcc FAQ covers
> that there is no need for users to refer to that either.

While looking at the documentation, I realized that the gcc cross
compiling has been broken for years. See

http://gcc.gnu.org/ml/gcc/2001-06/msg00486.html
http://gcc.gnu.org/ml/gcc/2001-06/msg00499.html

I don't want to write a docummentation for a configuration which
is known not working. I also have different ways to deal with cross
compiling to Linux. I am enclosing my patch here for reference. Let me
warn you first, not everyone agrees my patcch is the right way to go.
But it is the right way for me to build cross compilers for Linux.

Before I update the cross compile docummentation, let's fix gcc first.


H.J.
----
2001-05-10  H.J. Lu  (hjl@gnu.org)

	* gcc/Makefile.in (LIMITS_H_TEST): Also check
	$(tooldir)/include and $(gcc_tooldir)/include for limits.h.
	(tooldir): Set to @tooldir@.

2001-04-20  H.J. Lu  (hjl@gnu.org)

	* gcc/configure.in (inhibit_libc): Don't define for Linux.

	* gcc/java/Make-lang.in (jcf-dump$(exeext)): Depend on errors.o
	(gcjh$(exeext)): Likewise.

	* Makefile.in (BASE_FLAGS_TO_PASS): Remove

	"includedir=$(includedir)" \

	for canadian cross compile.

--- gcc-2.96-20000731/gcc/configure.in.cross	Fri Apr 20 10:06:36 2001
+++ gcc-2.96-20000731/gcc/configure.in	Fri Apr 20 10:06:47 2001
@@ -4299,7 +4299,14 @@ fi
 # assert.h.
 inhibit_libc=
 if [test x$host != x$target] && [test x$with_headers = x]; then
-       inhibit_libc=-Dinhibit_libc
+       case "${target}" in
+       *linux*)
+	       # Linux targets have the C library header files.
+	       ;;
+       *)
+               inhibit_libc=-Dinhibit_libc
+	       ;;
+       esac
 else
        if [test x$with_newlib = xyes]; then
                inhibit_libc=-Dinhibit_libc
--- gcc-2.96-20000731/gcc/java/Make-lang.in.cross	Fri Jul  7 12:40:14 2000
+++ gcc-2.96-20000731/gcc/java/Make-lang.in	Fri Apr 20 10:06:47 2001
@@ -59,7 +59,12 @@ GCJ = gcj
 # Define the names for selecting java in LANGUAGES.
 java: jc1$(exeext) $(GCJ)$(exeext) jvgenmain$(exeext) gcjh$(exeext) jv-scan$(exeext) jcf-dump$(exeext)
 
-# Define the name of target independant tools to be installed in $(bindir)
+# errors.o may not be always built for canadian cross compile. Make
+# sure it is built for java.
+jcf-dump$(exeext): errors.o
+gcjh$(exeext): errors.o
+
+# Defin the name of target independant tools to be installed in $(bindir)
 # Names are subject to changes
 JAVA_TARGET_INDEPENDENT_BIN_TOOLS = gcjh jv-scan jcf-dump
 
--- gcc-2.96-20000731/gcc/Makefile.in.cross	Thu May 10 23:19:54 2001
+++ gcc-2.96-20000731/gcc/Makefile.in	Thu May 10 23:23:05 2001
@@ -235,7 +235,10 @@ STMP_FIXPROTO = stmp-fixproto
 STMP_FIXINC = stmp-fixinc
 
 # Test to see whether <limits.h> exists in the system header files.
-LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
+LIMITS_H_TEST = \
+  [ -f $(SYSTEM_HEADER_DIR)/limits.h ] \
+  || [ -f $(tooldir)/include/limits.h ] \
+  || [ -f $(gcc_tooldir)/include/limits.h ] 
 
 target=@target@
 target_alias=@target_alias@
@@ -279,6 +282,8 @@ libsubdir = $(libdir)/gcc-lib/$(target_a
 unlibsubdir = ../../..
 # Directory in which to find other cross-compilation tools and headers.
 dollar = @dollar@
+# Used to check limits.h for cross-compiler.
+tooldir = @tooldir@
 # Used in install-cross.
 gcc_tooldir = @gcc_tooldir@
 # Since tooldir does not exist at build-time, use -B$(build_tooldir)/bin/
--- gcc-2.96-20000731/Makefile.in.cross	Fri Apr 20 10:06:58 2001
+++ gcc-2.96-20000731/Makefile.in	Fri Apr 20 10:07:03 2001
@@ -360,7 +360,6 @@ BASE_FLAGS_TO_PASS = \
 	"bindir=$(bindir)" \
 	"datadir=$(datadir)" \
 	"exec_prefix=$(exec_prefix)" \
-	"includedir=$(includedir)" \
 	"infodir=$(infodir)" \
 	"libdir=$(libdir)" \
 	"libexecdir=$(libexecdir)" \

Re: documentation for cross compiling.

[NIIBE Yutaka]

Hi HJ, 

H . J . Lu wrote:
 > 2001-04-20  H.J. Lu  (hjl@gnu.org)
 > 
 > 	* gcc/configure.in (inhibit_libc): Don't define for Linux.
[...]
 > --- gcc-2.96-20000731/gcc/configure.in.cross	Fri Apr 20 10:06:36 2001
 > +++ gcc-2.96-20000731/gcc/configure.in	Fri Apr 20 10:06:47 2001
 > @@ -4299,7 +4299,14 @@ fi
 >  # assert.h.
 >  inhibit_libc=
 >  if [test x$host != x$target] && [test x$with_headers = x]; then
 > -       inhibit_libc=-Dinhibit_libc
 > +       case "${target}" in
 > +       *linux*)
 > +	       # Linux targets have the C library header files.
 > +	       ;;
 > +       *)
 > +               inhibit_libc=-Dinhibit_libc
 > +	       ;;
 > +       esac
 >  else
 >         if [test x$with_newlib = xyes]; then
 >                 inhibit_libc=-Dinhibit_libc

This change is questionable.  There's a situation where we don't have
C library (yet).  I mean, when we start development of porting, we
don't have C library.

Actually, I have such a kind of experience for our GNU/Linux support
of SuperH.  The bootstrap goes like this.

	(1) (Partial) build of GCC (with no C library), install.
            Language is C only.
	(2) Build GNU C library, install.
	(3) (Full) build of GCC.  We can support C++ language
	    (runtime) or others this time.
-- 

Re: documentation for cross compiling.

[H . J . Lu]

On Tue, Jul 03, 2001 at 07:26:57PM +0900, NIIBE Yutaka wrote:
> Hi HJ, 
>  > +       case "${target}" in
>  > +       *linux*)
>  > +	       # Linux targets have the C library header files.
>  > +	       ;;
>  > +       *)
>  > +               inhibit_libc=-Dinhibit_libc
>  > +	       ;;
>  > +       esac
>  >  else
>  >         if [test x$with_newlib = xyes]; then
>  >                 inhibit_libc=-Dinhibit_libc
> 
> This change is questionable.  There's a situation where we don't have
> C library (yet).  I mean, when we start development of porting, we
> don't have C library.

I have done that many times. It only happens once per port.

> 
> Actually, I have such a kind of experience for our GNU/Linux support
> of SuperH.  The bootstrap goes like this.
> 
	(0) Install the header files from the x86 port.

> 	(1) (Partial) build of GCC (with no C library), install.
>             Language is C only.

It doesn't matter if the header files exist or not. You will get
just enough gcc to build glibc.

> 	(2) Build GNU C library, install.
> 	(3) (Full) build of GCC.  We can support C++ language

That change to

	(3) (Full) Reconfigure/rebuild of GCC.  We can support C++ language

> 	    (runtime) or others this time.

I usually have

	(4) Install gcc
	(5) Rebuild GNU C library, install.
	(6) (Full) Reconfigure/rebuild of GCC.  We can support C++ language
	(runtime) or others this time.

H.J.

Re: documentation for cross compiling.

[Toshi Morita]

Niibe Yutaka wrote:
> Hi HJ, 
> 
> H . J . Lu wrote:
>  > 2001-04-20  H.J. Lu  (hjl@gnu.org)
>  > 
>  > 	* gcc/configure.in (inhibit_libc): Don't define for Linux.
> [...]
>  > --- gcc-2.96-20000731/gcc/configure.in.cross	Fri Apr 20 10:06:36 2001
>  > +++ gcc-2.96-20000731/gcc/configure.in	Fri Apr 20 10:06:47 2001
>  > @@ -4299,7 +4299,14 @@ fi
>  >  # assert.h.
>  >  inhibit_libc=
>  >  if [test x$host != x$target] && [test x$with_headers = x]; then
>  > -       inhibit_libc=-Dinhibit_libc
>  > +       case "${target}" in
>  > +       *linux*)
>  > +	       # Linux targets have the C library header files.
>  > +	       ;;
>  > +       *)
>  > +               inhibit_libc=-Dinhibit_libc
>  > +	       ;;
>  > +       esac
>  >  else
>  >         if [test x$with_newlib = xyes]; then
>  >                 inhibit_libc=-Dinhibit_libc
> 
> This change is questionable.  There's a situation where we don't have
> C library (yet).  I mean, when we start development of porting, we
> don't have C library.
> 
> Actually, I have such a kind of experience for our GNU/Linux support
> of SuperH.  The bootstrap goes like this.
> 
> 	(1) (Partial) build of GCC (with no C library), install.
>             Language is C only.
> 	(2) Build GNU C library, install.
> 	(3) (Full) build of GCC.  We can support C++ language
> 	    (runtime) or others this time.

This reminds me...

Can we make crt1.asm call __setup_argv_and_call_main or _main depending on
whether or not inhibit_libc is defined?

It's annoying to have the compiler build fail when there is no libc, as
is presently the case.

Toshi

Cross-compiler Documentation (was: PATCH: Handle the shared libgccis a system library)

[Gerald Pfeifer]

On Mon, 2 Jul 2001, Joseph S. Myers wrote:
>>> Tell me where I should put it. I will see what I can do.
>> Well, you'd need to send it to gcc-patches of course.  I would put it
>> in doc/cross-compile.texi, or something similar.
> It should go in doc/install.texi, along with the existing installation
> documentation.  Ideally, it should cover everything the documentation in
> doc/install-old.texi does, so the cross compilation documentation there
> can go away; and it should cover enough of what the crossgcc FAQ covers
> that there is no need for users to refer to that either.

We desparately need such documentation, and any (nearly) anything will
be better than what we currently have (which is nothing, in the official
install documentation). :-(

So, if anyone has a bit of time to work on this, I think we should
instantly install whatever s/he can offer and then iterate on that.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Cross-compiler Documentation (was: PATCH: Handle the sharedlibgcc is a system library)

[Joseph S. Myers]

On Tue, 3 Jul 2001, Gerald Pfeifer wrote:

> We desparately need such documentation, and any (nearly) anything will
> be better than what we currently have (which is nothing, in the official
> install documentation). :-(
> 
> So, if anyone has a bit of time to work on this, I think we should
> instantly install whatever s/he can offer and then iterate on that.

Bo Thorsen <bo@sonofthor.dk> is now working on something.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: documentation for cross compiling.

[Daniel Jacobowitz]

On Tue, Jul 03, 2001 at 07:38:40AM -0700, H . J . Lu wrote:
> On Tue, Jul 03, 2001 at 07:26:57PM +0900, NIIBE Yutaka wrote:
> > Hi HJ, 
> >  > +       case "${target}" in
> >  > +       *linux*)
> >  > +	       # Linux targets have the C library header files.
> >  > +	       ;;
> >  > +       *)
> >  > +               inhibit_libc=-Dinhibit_libc
> >  > +	       ;;
> >  > +       esac
> >  >  else
> >  >         if [test x$with_newlib = xyes]; then
> >  >                 inhibit_libc=-Dinhibit_libc
> > 
> > This change is questionable.  There's a situation where we don't have
> > C library (yet).  I mean, when we start development of porting, we
> > don't have C library.
> 
> I have done that many times. It only happens once per port.

That depends if you insist on full proper bootstraps or not.  Every
time I to a daily build for one of our architectures, we start without
a target libc installed.  This prevents all sorts of unpleasant
lingering problems.

When I build gcc first for a given target, I have no libc.

> > Actually, I have such a kind of experience for our GNU/Linux support
> > of SuperH.  The bootstrap goes like this.
> > 
> 	(0) Install the header files from the x86 port.

That's gross.  I'm not amazed that it works, but if anything ever goes
wrong it'll be almost impossible to track down.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: documentation for cross compiling.

[H . J . Lu]

On Tue, Jul 03, 2001 at 05:37:26AM -0700, Daniel Jacobowitz wrote:
> > 
> > I have done that many times. It only happens once per port.
> 
> That depends if you insist on full proper bootstraps or not.  Every
> time I to a daily build for one of our architectures, we start without
> a target libc installed.  This prevents all sorts of unpleasant
> lingering problems.

Check out my mips toolchain source rpm to see how I do it. I have a
setup to rebuild my Linux/mips from scratch. It is kind of tricky.

> 
> When I build gcc first for a given target, I have no libc.
> 
> > > Actually, I have such a kind of experience for our GNU/Linux support
> > > of SuperH.  The bootstrap goes like this.
> > > 
> > 	(0) Install the header files from the x86 port.
> 
> That's gross.  I'm not amazed that it works, but if anything ever goes

That is how to start a new glibc port. At this point, you only want
ta gcc compiler for your new target. Those header files will be just
enough to finish the minimal gcc build. It is a very tricky thing to
do. Fortunately, I only need to do it once per target.

> wrong it'll be almost impossible to track down.

Can you guess I created the very first Linux cross toolchain more
than 10 years ago?


H.J.

Re: documentation for cross compiling.

[Daniel Jacobowitz]

On Tue, Jul 03, 2001 at 12:53:11PM -0700, H . J . Lu wrote:
> On Tue, Jul 03, 2001 at 05:37:26AM -0700, Daniel Jacobowitz wrote:
> > > 
> > > I have done that many times. It only happens once per port.
> > 
> > That depends if you insist on full proper bootstraps or not.  Every
> > time I to a daily build for one of our architectures, we start without
> > a target libc installed.  This prevents all sorts of unpleasant
> > lingering problems.
> 
> Check out my mips toolchain source rpm to see how I do it. I have a
> setup to rebuild my Linux/mips from scratch. It is kind of tricky.

I have a perfectly working setup to do this.  It relies on the ability
to build a minimal gcc for only C support without the presence of a
target libc.  I consider that a perfectly reasonable requirement; don't
you?

I've actually got a couple other patches floating around necessary for
this, mostly to fix problems introduced in the DWARF2 unwinder.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: documentation for cross compiling.

[Neil Booth]

H . J . Lu wrote:-

> Can you guess I created the very first Linux cross toolchain more
> than 10 years ago?

That's quite an achievement considering Linux isn't 10 until
September.

Neil.

Re: documentation for cross compiling.

[H . J . Lu]

On Tue, Jul 03, 2001 at 09:59:03PM +0100, Neil Booth wrote:
> H . J . Lu wrote:-
> 
> > Can you guess I created the very first Linux cross toolchain more
> > than 10 years ago?
> 
> That's quite an achievement considering Linux isn't 10 until
> September.

That was kernel 0.09(?), gcc 1.3x and binutils 1.? I was so fed up
with it that I did my best to put my cross compile stuff into gcc 2.x.


H.J.

Re: documentation for cross compiling.

[H . J . Lu]

On Tue, Jul 03, 2001 at 01:23:20PM -0700, Daniel Jacobowitz wrote:
> > > That depends if you insist on full proper bootstraps or not.  Every
> > > time I to a daily build for one of our architectures, we start without
> > > a target libc installed.  This prevents all sorts of unpleasant
> > > lingering problems.
> > 
> > Check out my mips toolchain source rpm to see how I do it. I have a
> > setup to rebuild my Linux/mips from scratch. It is kind of tricky.
> 
> I have a perfectly working setup to do this.  It relies on the ability
> to build a minimal gcc for only C support without the presence of a
> target libc.  I consider that a perfectly reasonable requirement; don't
> you?

I don't think it is necessary. Bootstrap glibc/gcc for the very first
time is always a special case. I don't think you can automate it.
After that, you just need the appropriate glibc header files and
binary files to get a correct cross compiler, including C and C++.
You don't have to use any initial target binaries in the cross
toolchain to cross compile binaries for your target machine. At least,
that is how I do it. It is kind of tricky to do.

> 
> I've actually got a couple other patches floating around necessary for
> this, mostly to fix problems introduced in the DWARF2 unwinder.

I am very interested in them. I saw some gcc 3.0 C++ EH bug reports on
Linux/mipsel which I cannot duplicate with my 2.96 based toolchain.


H.J.

Re: documentation for cross compiling.

[Daniel Jacobowitz]

On Tue, Jul 03, 2001 at 02:31:48PM -0700, H . J . Lu wrote:
> On Tue, Jul 03, 2001 at 01:23:20PM -0700, Daniel Jacobowitz wrote:
> > > > That depends if you insist on full proper bootstraps or not.  Every
> > > > time I to a daily build for one of our architectures, we start without
> > > > a target libc installed.  This prevents all sorts of unpleasant
> > > > lingering problems.
> > > 
> > > Check out my mips toolchain source rpm to see how I do it. I have a
> > > setup to rebuild my Linux/mips from scratch. It is kind of tricky.
> > 
> > I have a perfectly working setup to do this.  It relies on the ability
> > to build a minimal gcc for only C support without the presence of a
> > target libc.  I consider that a perfectly reasonable requirement; don't
> > you?
> 
> I don't think it is necessary. Bootstrap glibc/gcc for the very first
> time is always a special case. I don't think you can automate it.

But I disagree.  Not only that, I disagree in code - I have automated
it, for MIPS, PowerPC, i386, ARM, and SH.  It prevents vicious cycles
from a bad compiler being any concern.  It means we don't have to have
part of yesterdays broken build lying around to contaminate today's
fixed one.  I consider it vital.

> > I've actually got a couple other patches floating around necessary for
> > this, mostly to fix problems introduced in the DWARF2 unwinder.
> 
> I am very interested in them. I saw some gcc 3.0 C++ EH bug reports on
> Linux/mipsel which I cannot duplicate with my 2.96 based toolchain.

They won't affect those.  The only thing they're for is removing the
need to include, e.g., <signal.h> when building libgcc.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: documentation for cross compiling.

[H . J . Lu]

On Tue, Jul 03, 2001 at 03:57:55PM -0700, Daniel Jacobowitz wrote:
> > 
> > I don't think it is necessary. Bootstrap glibc/gcc for the very first
> > time is always a special case. I don't think you can automate it.
> 
> But I disagree.  Not only that, I disagree in code - I have automated
> it, for MIPS, PowerPC, i386, ARM, and SH.  It prevents vicious cycles

When I said "the very first time", I meant "the very first time". That
is you are doing the first port to a new target. There is nothing
specific for the new target ever existed. You have to fill all the
blanks. How can you automate that?


H.J.

Re: documentation for cross compiling.

[M. R. Brown]

* H . J . Lu <hjl@lucon.org> on Tue, Jul 03, 2001:

> 
> I don't think it is necessary. Bootstrap glibc/gcc for the very first
> time is always a special case. I don't think you can automate it.

Hmm, we're still talking about cross-compilers right?  If so, then a
minimal C compiler can be "bootstrapped" by:

# ../configure ... --with-newlib --without-headers
# make all-gcc
# make install-gcc

That can be automated.

> After that, you just need the appropriate glibc header files and
> binary files to get a correct cross compiler, including C and C++.

You're right, after you create the C compiler, you can build glibc; the
only problem I have is with gcc-3.0 where some part of glibc links with
(the nonexistent) libgcc_s, but it could be because the specs I'm using
(Kaz Kojima's patches) for SuperH (I don't know if this is a problem on 
other archs).  I solve that with a symlink to the static libgcc.

I can only build libgcc_s after I have the glibc headers, e.g. the second
(full) build of gcc.

M. R.

Re: documentation for cross compiling.

[Daniel Jacobowitz]

On Tue, Jul 03, 2001 at 04:03:10PM -0700, H . J . Lu wrote:
> On Tue, Jul 03, 2001 at 03:57:55PM -0700, Daniel Jacobowitz wrote:
> > > 
> > > I don't think it is necessary. Bootstrap glibc/gcc for the very first
> > > time is always a special case. I don't think you can automate it.
> > 
> > But I disagree.  Not only that, I disagree in code - I have automated
> > it, for MIPS, PowerPC, i386, ARM, and SH.  It prevents vicious cycles
> 
> When I said "the very first time", I meant "the very first time". That
> is you are doing the first port to a new target. There is nothing
> specific for the new target ever existed. You have to fill all the
> blanks. How can you automate that?

Sure.  I misread that.

But I'd like to keep it possible to build gcc without any target glibc
headers at all, without having to fiddle the gcc configuration, so that
this sort of clean build continues to be possible.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: documentation for cross compiling.

[H . J . Lu]

On Tue, Jul 03, 2001 at 05:00:41PM -0700, Daniel Jacobowitz wrote:
> 
> But I'd like to keep it possible to build gcc without any target glibc
> headers at all, without having to fiddle the gcc configuration, so that
> this sort of clean build continues to be possible.
> 

That is a nice thing to have, at least as a configure time option. It
may not give you a complete C compiler, but may be good enough to
compile glibc with it.


H.J.

Re: documentation for cross compiling.

[Alexandre Oliva]

On Jul  3, 2001, Toshi Morita <tm2@best.com> wrote:

> Can we make crt1.asm call __setup_argv_and_call_main or _main depending on
> whether or not inhibit_libc is defined?

Hmm...  Perhaps we should just inline __setup_argv_and_call_main into
the assembly start-up code, and remove it from newlib?  I wouldn't
object to a patch that did this.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: documentation for cross compiling.

[tm]

Alexandre Oliva wrote:
> 
> On Jul  3, 2001, Toshi Morita <tm2@best.com> wrote:
> 
> > Can we make crt1.asm call __setup_argv_and_call_main or _main depending on
> > whether or not inhibit_libc is defined?
> 
> Hmm...  Perhaps we should just inline __setup_argv_and_call_main into
> the assembly start-up code, and remove it from newlib?  I wouldn't
> object to a patch that did this.

I think that code has external dependencies on the host OS?

Niibe would know, though.

Toshi

Re: documentation for cross compiling.

[Alexandre Oliva]

On Jul 27, 2001, tm <tm@kloo.net> wrote:

> Alexandre Oliva wrote:
>> 
>> On Jul  3, 2001, Toshi Morita <tm2@best.com> wrote:
>> 
>> > Can we make crt1.asm call __setup_argv_and_call_main or _main depending on
>> > whether or not inhibit_libc is defined?
>> 
>> Hmm...  Perhaps we should just inline __setup_argv_and_call_main into
>> the assembly start-up code, and remove it from newlib?  I wouldn't
>> object to a patch that did this.

> I think that code has external dependencies on the host OS?

On the target non-OS, actually.  __setup_argv_and_call_main is
currently only used in the newlib crt0.o, called from
sh-{elf,coff,hms}'s crt1.o.  gcc/config/sh/crt1.asm is not used for
sh-linux, so it's safe to move the code from newlib into crt1.asm.  I
didn't just because I didn't feel like coding that in assembly; it
should be easy enough to just take the optimized assembly output from
those functions and integrate it into crt1.asm, possibly with
additional hand-optimization.  I'd still keep the original source code
as comments in the assembly sources, though, for documentation
purposes.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: documentation for cross compiling.

[tm]

Alexandre Oliva wrote:
> 
> On Jul 27, 2001, tm <tm@kloo.net> wrote:
> 
> > Alexandre Oliva wrote:
> >>
> >> On Jul  3, 2001, Toshi Morita <tm2@best.com> wrote:
> >>
> >> > Can we make crt1.asm call __setup_argv_and_call_main or _main depending on
> >> > whether or not inhibit_libc is defined?
> >>
> >> Hmm...  Perhaps we should just inline __setup_argv_and_call_main into
> >> the assembly start-up code, and remove it from newlib?  I wouldn't
> >> object to a patch that did this.
> 
> > I think that code has external dependencies on the host OS?
> 
> On the target non-OS, actually.  __setup_argv_and_call_main is
> currently only used in the newlib crt0.o, called from
> sh-{elf,coff,hms}'s crt1.o.  gcc/config/sh/crt1.asm is not used for
> sh-linux, so it's safe to move the code from newlib into crt1.asm.  I
> didn't just because I didn't feel like coding that in assembly; it
> should be easy enough to just take the optimized assembly output from
> those functions and integrate it into crt1.asm, possibly with
> additional hand-optimization.  I'd still keep the original source code
> as comments in the assembly sources, though, for documentation
> purposes.

I don't understand the full implications of this change, since I haven't
looked through newlib yet, but as long as it breaks the sh-coff/sh-elf
dependency on newlib and enables a full working compiler to be built
without
newlib installed, I'm all for it.

Toshi

Re: documentation for cross compiling.

[Alexandre Oliva]

On Jan  2, 1997, tm <tm@kloo.net> wrote:

> I don't understand the full implications of this change, since I
> haven't looked through newlib yet, but as long as it breaks the
> sh-coff/sh-elf dependency on newlib and enables a full working
> compiler to be built without newlib installed, I'm all for it.

This dependency can't really be broken: GCC is the compiler, and the C
library, expected to supply crt0.o, libc.a and libm.a are supposed to
be newlib, in the case of sh-elf and sh-coff.  Of course, if you use
an alternate C library that supplies crt0.o, libc.a and libm.a such
that they are compatible with those offered by newlib, you can claim
there's no dependence on newlib.  The real point is the issue of
compatibility.  Currently, in order to be compatible, crt0.o must
implement __setup_argv_and_call_main().  If we move this from crt0.o
to crt1.asm, it will no longer be the case.  But all other
dependencies on newlib will remain.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: documentation for cross compiling.

[tm]

Alexandre Oliva wrote:
> 
> On Jan  2, 1997, tm <tm@kloo.net> wrote:
> 
> > I don't understand the full implications of this change, since I
> > haven't looked through newlib yet, but as long as it breaks the
> > sh-coff/sh-elf dependency on newlib and enables a full working
> > compiler to be built without newlib installed, I'm all for it.
> 
> This dependency can't really be broken: GCC is the compiler, and the C
> library, expected to supply crt0.o, libc.a and libm.a are supposed to
> be newlib, in the case of sh-elf and sh-coff.  Of course, if you use
> an alternate C library that supplies crt0.o, libc.a and libm.a such
> that they are compatible with those offered by newlib, you can claim
> there's no dependence on newlib.  The real point is the issue of
> compatibility.  Currently, in order to be compatible, crt0.o must
> implement __setup_argv_and_call_main().  If we move this from crt0.o
> to crt1.asm, it will no longer be the case.  But all other
> dependencies on newlib will remain.

Well, it's a step in the right direction, anyway.

It would be nice if we could print a message when the toolchain is
configured, 
e.g.:

./configure --target=sh-elf
Configuring for sh-elf...
This configuration requires newlib. Please ensure it is installed.

...or something to that effect.

Toshi