Re: Fwd: Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-09-05 Thread Christian Bruel

On 08/30/2013 05:50 PM, Joseph S. Myers wrote:
 On Fri, 30 Aug 2013, Christian Bruel wrote:

 So to cross build a target library |
 --with-build-sysroot=|dir looks appropriate to specify the alternative
 host root path.
 but
 --with-sysroot looks not appropriate because it changes the search paths
 (that should still be /usr/include on the target tree).
 ...
 Your patch suggests you are actually using a cross compiler to build a 
 native compiler - $build != $host == $target.  In that case, it's best not 
 to build target libraries at all, as they will already have been built 
 with the $build-x-$target cross compiler that must have previously been 
 built from the same GCC sources, with the same configuration.  That is, 
 make all-host and make install-host, and copy the libraries from the 
 previous build.  And since you already have such a $build-x-$target 
 compiler, it would seem best to determine what directory that compiler 
 actually searches for headers and compute target_header_dir that way, to 
 the extent that the target headers need examining to determine 
 configuration of the compiler proper.

Thanks for the hint. Indeed in the normal case it doesn't make sense to
rebuild twice the target libraries, the target build is simplified with
the all-host rules and reusing those built with the cross-gcc is best.
But there are cases were it is still interesting to rebuild them (e.g 
the target gcc is not  from the same version or have different
CFLAGS_FOR_TARGET, or for cross-checking reasons).  Let me ping the
patch (from http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01748.html)

Many thanks

Christian



Fwd: Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-08-30 Thread Christian Bruel
(resent plain text, sorry)

A documentation comment on the proposed patch.

The issue occurred while building the target libgcc using the cross-gcc,
while cross-building a target-gcc

../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
file or directory

indeed, auto-host.h had

/* Define if your target C library provides sys/sdt.h */
#define HAVE_SYS_SDT_H 1

because:

configure:26872: checking sys/sdt.h in the target C library
configure:26881: result: yes
(which is false)

So to cross build a target library |
--with-build-sysroot=|dir looks appropriate to specify the alternative
host root path.
but
--with-sysroot looks not appropriate because it changes the search paths
(that should still be /usr/include on the target tree).

So, consequently, the --with-build-sysroot documentation sentence
This option is only useful when you are already using --with-sysroot.
looks incorrect to me as we seem to have here a use of
--with-build-sysroot without --with-sysroot.

Not sure if it's clear, but I'm wondering why this restriction in the
documentation ? Could we amend it  ?

Cheers

Christian

On 08/29/2013 10:36 AM, Christian Bruel wrote:
 Hello Bill and Jakub

 On 08/22/2013 07:47 PM, Jakub Jelinek wrote:
 On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
 Hi Christian and Jakub,

 I'm curious whether there was ever any resolution for:
 http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.
 Sorry for not having sent a follow up for this.

 The problem is that configure was checking for cross features in the
 host root dir instead of the cross root dir.

 This SDT failure was only the visible part of the problem while building
 a Canadian Cross linux hosted GCC, as  we could as well silently test
 for different cross/target runtime features :-).

 I fixed this problem  by fixing the usage of with_build_sysroot while
 checking system features with target_header_dir when host != build.
 Checked for legacy issue with various bare or hosted SH4 compilers in
 various environments (linux, mingwn, cygwin)

 Comments ? does this is seems reasonable to push to trunk ?

 Cheers

 Christian








Re: Fwd: Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-08-30 Thread Joseph S. Myers
On Fri, 30 Aug 2013, Christian Bruel wrote:

 So to cross build a target library |
 --with-build-sysroot=|dir looks appropriate to specify the alternative
 host root path.
 but
 --with-sysroot looks not appropriate because it changes the search paths
 (that should still be /usr/include on the target tree).

If you are building a cross compiler to a target such as GNU/Linux for 
which the concept of native directory arrangements makes sense, then you 
need --with-sysroot.  That specifies the directory that the final 
installed compiler will use to find headers and libraries (as modified by 
sysroot suffixes and the usual relocation if the compiler is installed 
somewhere other than its configured prefix).

If, when you are building such a compiler, the sysroot is located 
somewhere other than the location specified with --with-sysroot, then you 
need --with-build-sysroot as well.  That's the entire purpose of 
--with-build-sysroot: the case where the build-time location of the 
sysroot for a sysrooted compiler you are building differs from the 
configured location given with --with-sysroot.

I don't see what your use is for a cross compiler without --with-sysroot.  
It's simply not correct for the installed cross compiler to search 
/usr/include, and if you don't specify a sysroot at all then it will just 
search directories such as target/include and target/lib under the 
installation (which cannot represent the complexity of standard GNU/Linux 
directory arrangements; note the absolute paths, intended to be 
interpreted relative to a sysroot, in the libc.so linker script from 
glibc, for example), so that compiler needs a sysroot.

All the above is about cross compilers - compilers with $host != $target.  
Your patch suggests you are actually using a cross compiler to build a 
native compiler - $build != $host == $target.  In that case, it's best not 
to build target libraries at all, as they will already have been built 
with the $build-x-$target cross compiler that must have previously been 
built from the same GCC sources, with the same configuration.  That is, 
make all-host and make install-host, and copy the libraries from the 
previous build.  And since you already have such a $build-x-$target 
compiler, it would seem best to determine what directory that compiler 
actually searches for headers and compute target_header_dir that way, to 
the extent that the target headers need examining to determine 
configuration of the compiler proper.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-08-29 Thread Christian Bruel
Hello Bill and Jakub

On 08/22/2013 07:47 PM, Jakub Jelinek wrote:
 On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
 Hi Christian and Jakub,

 I'm curious whether there was ever any resolution for:
 http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.


Sorry for not having sent a follow up for this.

The problem is that configure was checking for cross features in the
host root dir instead of the cross root dir.

This SDT failure was only the visible part of the problem while building
a Canadian Cross linux hosted GCC, as  we could as well silently test
for different cross/target runtime features :-).

I fixed this problem  by fixing the usage of with_build_sysroot while
checking system features with target_header_dir when host != build.
Checked for legacy issue with various bare or hosted SH4 compilers in
various environments (linux, mingwn, cygwin)

Comments ? does this is seems reasonable to push to trunk ?

Cheers

Christian


2012-12-21  Christian Bruel  christian.br...@st.com

   * configure.ac: Set target_header_dir for with-build-sysroot.
   * configure: Regenerate.

Index: gcc/configure
===
--- gcc/configure	(revision 202068)
+++ gcc/configure	(working copy)
@@ -27011,6 +27011,8 @@ if test x$host != x$target || test x$TARGET_SYSTE
   else
 target_header_dir=${with_sysroot}${native_system_header_dir}
   fi
+elif test x$host != x$build  test x$with_build_sysroot != x; then
+  target_header_dir=${with_build_sysroot}${native_system_header_dir}
 else
   target_header_dir=${native_system_header_dir}
 fi
Index: gcc/configure.ac
===
--- gcc/configure.ac	(revision 202068)
+++ gcc/configure.ac	(working copy)
@@ -4822,6 +4822,8 @@ if test x$host != x$target || test x$TARGET_SYSTE
   else
 target_header_dir=${with_sysroot}${native_system_header_dir}
   fi
+elif test x$host != x$build  test x$with_build_sysroot != x; then
+  target_header_dir=${with_build_sysroot}${native_system_header_dir}
 else
   target_header_dir=${native_system_header_dir}
 fi


Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-08-22 Thread Bill Schmidt
Hi Christian and Jakub,

I'm curious whether there was ever any resolution for:
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.

We've encountered what appears to be the same issue internally when
building a cross for powerpc64le-linux-gnu:

/scratch/tmp/anton/toolchain/build/src/gcc/libgcc/unwind-dw2.c:41:21:
fatal error: sys/sdt.h: No such file or directory
 #include sys/sdt.h

The gcc configure is looking at the build machine header files, instead
of the installed headers for the host we're building.  We can work
around this with a build-sysroot, but it seems that shouldn't be
necessary.  Thoughts?



Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-08-22 Thread Jakub Jelinek
On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
 Hi Christian and Jakub,
 
 I'm curious whether there was ever any resolution for:
 http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.

The last mail I remember didn't make any sense:
#include tconfig.h

that includes it:

#ifndef GCC_TCONFIG_H
#define GCC_TCONFIG_H
#ifndef USED_FOR_TARGET
# define USED_FOR_TARGET
#endif
#include auto-host.h

in which there is :

#ifndef USED_FOR_TARGET
#define HAVE_SYS_SDT_H 1
#endif

That means USED_FOR_TARGET is defined and thus HAVE_SYS_SDT_H is never
defined, which is not desirable.

Jakub


Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2013-08-22 Thread Bill Schmidt
On Thu, 2013-08-22 at 19:47 +0200, Jakub Jelinek wrote:
 On Thu, Aug 22, 2013 at 09:39:48AM -0500, Bill Schmidt wrote:
  Hi Christian and Jakub,
  
  I'm curious whether there was ever any resolution for:
  http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01124.html.
 
 The last mail I remember didn't make any sense:
 #include tconfig.h
 
 that includes it:
 
 #ifndef GCC_TCONFIG_H
 #define GCC_TCONFIG_H
 #ifndef USED_FOR_TARGET
 # define USED_FOR_TARGET
 #endif
 #include auto-host.h
 
 in which there is :
 
 #ifndef USED_FOR_TARGET
 #define HAVE_SYS_SDT_H 1
 #endif
 
 That means USED_FOR_TARGET is defined and thus HAVE_SYS_SDT_H is never
 defined, which is not desirable.
 
   Jakub
 

Yes, that doesn't seem right at all.  OK, thanks.  I'll stick this on a
list as a low-priority item to fix one of these days.

Thanks,
Bill



Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2012-12-18 Thread Jakub Jelinek
On Tue, Dec 18, 2012 at 03:41:58PM +0100, Christian Bruel wrote:
 Canadian Cross Builds fail to build libgcc/unwind-dw2.c
 
 ...
 ../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
 file or directory
 ...
 
 when the build machine has sys/sdt.h installed (systemtap-sdt-devel),
 but not the target's, because of this:
 
 #ifdef HAVE_SYS_SDT_H
 #include sys/sdt.h
 #endif
 
 This appears to be because auto-host.h unconditionally defines
 HAVE_SYS_SDT_H from config.in, that should be guarded with #ifndef
 USED_FOR_TARGET
 
 This patch changes the sys/sdt.h detection to the standard macro to
 correctly generate it. And need to regenerate configure and config.in.
 
 Checked for x86 native boostrap OK and SH4-linux Cross and Native builds
 on host (with and without systemtap host header installed)
 
 OK for trunk ?

That doesn't look like a correct fix.  If HAVE_SYS_SDT_H define is always
guarded with #ifndef USED_FOR_TARGET, then it will never be used in the
target unwind-dw2.c where it is supposed to be used if available.
The configury snippet was clearly looking for target sys/sdt.h header:
if test -f $target_header_dir/sys/sdt.h; then
  have_sys_sdt_h=yes

so the question is why it found a host header instead in your case.

Jakub


Re: [PATCH]. Fix HAVE_SYS_SDT_H for cross-compilation

2012-12-18 Thread Christian Bruel


On 12/18/2012 03:47 PM, Jakub Jelinek wrote:
 On Tue, Dec 18, 2012 at 03:41:58PM +0100, Christian Bruel wrote:
 Canadian Cross Builds fail to build libgcc/unwind-dw2.c

 ...
 ../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
 file or directory
 ...

 when the build machine has sys/sdt.h installed (systemtap-sdt-devel),
 but not the target's, because of this:

 #ifdef HAVE_SYS_SDT_H
 #include sys/sdt.h
 #endif

 This appears to be because auto-host.h unconditionally defines
 HAVE_SYS_SDT_H from config.in, that should be guarded with #ifndef
 USED_FOR_TARGET

 This patch changes the sys/sdt.h detection to the standard macro to
 correctly generate it. And need to regenerate configure and config.in.

 Checked for x86 native boostrap OK and SH4-linux Cross and Native builds
 on host (with and without systemtap host header installed)

 OK for trunk ?
 
 That doesn't look like a correct fix.  If HAVE_SYS_SDT_H define is always
 guarded with #ifndef USED_FOR_TARGET, then it will never be used in the
 target unwind-dw2.c where it is supposed to be used if available.
 The configury snippet was clearly looking for target sys/sdt.h header:
 if test -f $target_header_dir/sys/sdt.h; then
   have_sys_sdt_h=yes
 

Well, it should be used by unwind-dw2.c, because we have

#include tconfig.h

that includes it:

#ifndef GCC_TCONFIG_H
#define GCC_TCONFIG_H
#ifndef USED_FOR_TARGET
# define USED_FOR_TARGET
#endif
#include auto-host.h

in which there is :

#ifndef USED_FOR_TARGET
#define HAVE_SYS_SDT_H 1
#endif

So HAVE_SYS_SDT will be defined in unwind-dw2.c on system that need it.

 so the question is why it found a host header instead in your case.

This is for everyone. The auto-host.h is used commonly for the target,
unded the definition of 'USED_FOR_TARGET'

Cheers

Christian

 
   Jakub