[gcj-eclipse-merge-branch] fix cross-build configury/makery

[gcj-eclipse-merge-branch] fix cross-build configury/makery

[Adam Megacz]

ok to commit?

  - a

2006-12-04  Adam Megacz <megacz@cs.berkeley.edu>

        * Makefile.am: add libgcj-$(gcc_version).jar to -fclasspath=
        * configure.ac: change settings for GCJ and GCJFLAGS to fix
        cross-builds

Index: Makefile.am
===================================================================
--- Makefile.am (revision 119526)
+++ Makefile.am (working copy)
@@ -139,7 +139,7 @@
 
 AM_GCJFLAGS = \
        @LIBGCJ_JAVAFLAGS@ \
-       -fclasspath= -fbootclasspath=$(BOOTCLASSPATH) \
+       -fclasspath=libgcj-$(gcc_version).jar -fbootclasspath=$(BOOTCLASSPATH) \
        --encoding=UTF-8 \
        -Wno-deprecated -fbootstrap-classes
 
Index: configure.ac
===================================================================
--- configure.ac        (revision 119526)
+++ configure.ac        (working copy)
@@ -355,14 +355,16 @@
       if test "x${with_newlib}" = "xyes"; then
          # FIXME (comment): Why is this needed?
          GCC_UNWIND_INCLUDE=
-         GCJ="${target_noncanonical}-gcj"
+         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"
       else
-         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
+         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"
+         GCJFLAGS="-B$built_gcc_dir/ $GCJFLAGS"
       fi
       GCJH='$(target_noncanonical)-gcjh'
    ;;
    path)
-      GCJ="gcj -B`${PWDCMD-pwd}`/"
+      GCJ="$built_gcc_dir/gcj"
+      GCJFLAGS="-B$built_gcc_dir/ $GCJFLAGS"
       GCJH=gcjh
    ;;
 esac

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Andrew Haley]

Adam Megacz writes:
 > 
 > ok to commit?
 > 
 >   - a
 > 
 > 2006-12-04  Adam Megacz <megacz@cs.berkeley.edu>
 > 
 >         * Makefile.am: add libgcj-$(gcc_version).jar to -fclasspath=
 >         * configure.ac: change settings for GCJ and GCJFLAGS to fix
 >         cross-builds
 > 
 > Index: Makefile.am
 > ===================================================================
 > --- Makefile.am (revision 119526)
 > +++ Makefile.am (working copy)
 > @@ -139,7 +139,7 @@
 >  
 >  AM_GCJFLAGS = \
 >         @LIBGCJ_JAVAFLAGS@ \
 > -       -fclasspath= -fbootclasspath=$(BOOTCLASSPATH) \
 > +       -fclasspath=libgcj-$(gcc_version).jar -fbootclasspath=$(BOOTCLASSPATH) \
 >         --encoding=UTF-8 \
 >         -Wno-deprecated -fbootstrap-classes
 >  
 > Index: configure.ac
 > ===================================================================
 > --- configure.ac        (revision 119526)
 > +++ configure.ac        (working copy)
 > @@ -355,14 +355,16 @@
 >        if test "x${with_newlib}" = "xyes"; then
 >           # FIXME (comment): Why is this needed?
 >           GCC_UNWIND_INCLUDE=
 > -         GCJ="${target_noncanonical}-gcj"
 > +         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"

This change shouldn't be necessary.  I think it's related to a bug
that tromey is working on.

Andrew.


 >        else
 > -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
 > +         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"
 > +         GCJFLAGS="-B$built_gcc_dir/ $GCJFLAGS"
 >        fi
 >        GCJH='$(target_noncanonical)-gcjh'
 >     ;;
 >     path)
 > -      GCJ="gcj -B`${PWDCMD-pwd}`/"
 > +      GCJ="$built_gcc_dir/gcj"
 > +      GCJFLAGS="-B$built_gcc_dir/ $GCJFLAGS"
 >        GCJH=gcjh
 >     ;;
 >  esac

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Adam Megacz]

Andrew Haley <aph@redhat.com> writes:
>  > -         GCJ="${target_noncanonical}-gcj"
>  > +         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"

> This change shouldn't be necessary.  I think it's related to a bug
> that tromey is working on.

Currently this problem is still preventing cross-compiles, and this
fix still works.  Please let me know if there is some other way in
which I should be fixing this.

  - a

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Mohan Embar]

Hi Adam,

>Andrew Haley <aph@redhat.com> writes:
>>  > -         GCJ="${target_noncanonical}-gcj"
>>  > +         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"
>
>> This change shouldn't be necessary.  I think it's related to a bug
>> that tromey is working on.
>
>Currently this problem is still preventing cross-compiles, and this
>fix still works.  Please let me know if there is some other way in
>which I should be fixing this.

Can you elaborate more on why you think this is needed? My MinGW ecj
build worked fine without this, and this involved both a cross build
and a crossed-native build.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Adam Megacz]

Mohan Embar <gnustuff@thisiscool.com> writes:
> Hi Adam,
>
>>Andrew Haley <aph@redhat.com> writes:
>>>  > -         GCJ="${target_noncanonical}-gcj"
>>>  > +         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"
>>
>>> This change shouldn't be necessary.  I think it's related to a bug
>>> that tromey is working on.
>>
>>Currently this problem is still preventing cross-compiles, and this
>>fix still works.  Please let me know if there is some other way in
>>which I should be fixing this.
>
> Can you elaborate more on why you think this is needed? My MinGW ecj
> build worked fine without this,

Sorry, when going back through my changes I confused a new change with
this one (which is no longer needed).  See next posting.  Sorry for
the confusion.

  - a

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Adam Megacz]

Adam Megacz <megacz@cs.berkeley.edu> writes:
> this one (which is no longer needed).  See next posting.  Sorry for

Which I managed to post to the wrong list...

  http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01495.html

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

retracting my retraction [patch included]

[Adam Megacz]

See below.

Adam Megacz <megacz@cs.berkeley.edu> writes:
> Mohan Embar <gnustuff@thisiscool.com> writes:
>> Hi Adam,
>>
>>>Andrew Haley <aph@redhat.com> writes:
>>>>  > -         GCJ="${target_noncanonical}-gcj"
>>>>  > +         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"
>>>
>>>> This change shouldn't be necessary.  I think it's related to a bug
>>>> that tromey is working on.
>>>
>>>Currently this problem is still preventing cross-compiles, and this
>>>fix still works.  Please let me know if there is some other way in
>>>which I should be fixing this.
>>
>> Can you elaborate more on why you think this is needed? My MinGW ecj
>> build worked fine without this,
>
> Sorry, when going back through my changes I confused a new change with
> this one (which is no longer needed).  See next posting.  Sorry for
> the confusion.

Nope, I still need this one too -- or at least something very close to
it:

  Index: configure.ac
  ===================================================================
  --- configure.ac        (revision 120101)
  +++ configure.ac        (working copy)
  @@ -323,9 +323,9 @@
            GCC_UNWIND_INCLUDE=
            GCJ="${target_noncanonical}-gcj"
         else
  -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
  +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
         fi
  
Specifically, without this patch the build process attempts to invoke
i386-apple-darwin-gcj (in my case), which does not exist until "make
install" happens (and even then, it winds up in the install directory,
not accessible to the build).

May I commit this patch?

  ...
  i386-apple-darwin-gcj -B/tmp/odc/gcc-build/i386-apple-darwin/libjava/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/tmp/odc/gcc-build/i386-apple-darwin/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c ../../../gcc/libjava/java/lang/Class.java -fno-common -o java/lang/.libs/Class.o
  ./libtool: line 1: i386-apple-darwin-gcj: command not found
  make[4]: *** [java/lang/Class.lo] Error 1
  make[4]: Leaving directory `/tmp/odc/gcc-build/i386-apple-darwin/libjava'
  make[3]: *** [all-recursive] Error 1
  make[3]: Leaving directory `/tmp/odc/gcc-build/i386-apple-darwin/libjava'
  make[2]: *** [all-target-libjava] Error 2
  make[2]: Leaving directory `/tmp/odc/gcc-build'
  make[1]: *** [all] Error 2
  make[1]: Leaving directory `/tmp/odc/gcc-build'
  make: *** [/tmp/odc/prefix/bin/i386-apple-darwin-gcc] Error 2

Mohan, when you did your Canadian crossbuild, did this line work for
you?  If so, where was it getting the i686-pc-minwg32-gcj from?

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Re: retracting my retraction [patch included]

[Andrew Haley]

Adam Megacz writes:
 > 
 > See below.
 > 
 > Adam Megacz <megacz@cs.berkeley.edu> writes:
 > > Mohan Embar <gnustuff@thisiscool.com> writes:
 > >> Hi Adam,
 > >>
 > >>>Andrew Haley <aph@redhat.com> writes:
 > >>>>  > -         GCJ="${target_noncanonical}-gcj"
 > >>>>  > +         GCJ="$built_gcc_dir/${target_noncanonical}-gcj"
 > >>>
 > >>>> This change shouldn't be necessary.  I think it's related to a bug
 > >>>> that tromey is working on.
 > >>>
 > >>>Currently this problem is still preventing cross-compiles, and this
 > >>>fix still works.  Please let me know if there is some other way in
 > >>>which I should be fixing this.
 > >>
 > >> Can you elaborate more on why you think this is needed? My MinGW ecj
 > >> build worked fine without this,
 > >
 > > Sorry, when going back through my changes I confused a new change with
 > > this one (which is no longer needed).  See next posting.  Sorry for
 > > the confusion.
 > 
 > Nope, I still need this one too -- or at least something very close to
 > it:
 > 
 >   Index: configure.ac
 >   ===================================================================
 >   --- configure.ac        (revision 120101)
 >   +++ configure.ac        (working copy)
 >   @@ -323,9 +323,9 @@
 >             GCC_UNWIND_INCLUDE=
 >             GCJ="${target_noncanonical}-gcj"
 >          else
 >   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
 >   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
 >          fi
 >   
 > Specifically, without this patch the build process attempts to invoke
 > i386-apple-darwin-gcj (in my case), which does not exist until "make
 > install" happens (and even then, it winds up in the install directory,
 > not accessible to the build).
 > 
 > May I commit this patch?

Yes.

 > 
 >   ...
 >   i386-apple-darwin-gcj -B/tmp/odc/gcc-build/i386-apple-darwin/libjava/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/tmp/odc/gcc-build/i386-apple-darwin/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c ../../../gcc/libjava/java/lang/Class.java -fno-common -o java/lang/.libs/Class.o
 >   ./libtool: line 1: i386-apple-darwin-gcj: command not found
 >   make[4]: *** [java/lang/Class.lo] Error 1
 >   make[4]: Leaving directory `/tmp/odc/gcc-build/i386-apple-darwin/libjava'
 >   make[3]: *** [all-recursive] Error 1
 >   make[3]: Leaving directory `/tmp/odc/gcc-build/i386-apple-darwin/libjava'
 >   make[2]: *** [all-target-libjava] Error 2
 >   make[2]: Leaving directory `/tmp/odc/gcc-build'
 >   make[1]: *** [all] Error 2
 >   make[1]: Leaving directory `/tmp/odc/gcc-build'
 >   make: *** [/tmp/odc/prefix/bin/i386-apple-darwin-gcc] Error 2
 > 
 > Mohan, when you did your Canadian crossbuild, did this line work for
 > you?  If so, where was it getting the i686-pc-minwg32-gcj from?

I was wondering that too.

Andrew.

Re: retracting my retraction [patch included]

[Mohan Embar]

Hi All,

> > Nope, I still need this one too -- or at least something very close to
> > it:
> > 
> >   Index: configure.ac
> >   ===================================================================
> >   --- configure.ac        (revision 120101)
> >   +++ configure.ac        (working copy)
> >   @@ -323,9 +323,9 @@
> >             GCC_UNWIND_INCLUDE=
> >             GCJ="${target_noncanonical}-gcj"
> >          else
> >   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
> >   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
> >          fi
> >   
> > Specifically, without this patch the build process attempts to invoke
> > i386-apple-darwin-gcj (in my case), which does not exist until "make
> > install" happens (and even then, it winds up in the install directory,
> > not accessible to the build).
> > 
> > May I commit this patch?
>
>Yes.

I don't see how this:

> >   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"

...could possibly be right. Adam, are you building on Linux or Mactel?
What the above line is assuming is that the intermediate compiler is
suitable for building libgcj. This is only true when build=host, which
clearly isn't true for the case when we want to build an i686-pc-mingw32
compiler on i686-pc-linux-gnu using a cross compiler.

If the above is working for you on Mactel, then you're probably
lucking out becuse the intermediate compiler is coincidentally capable of
running on your build machine, even though your build and host strings are
different.

I think the correct assumption is that in order to do crossed-native compiler,
you need to have a cross compiler somewhere in your path, just like
the build-time compiler is assumed to be somewhere in the system path.
That means building the cross compiler, installing it, then adjusting your
system path accordingly before doing the crossed-native build.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: retracting my retraction [patch included]

[Andrew Haley]

Mohan Embar writes:
 > Hi All,
 > 
 > > > Nope, I still need this one too -- or at least something very close to
 > > > it:
 > > > 
 > > >   Index: configure.ac
 > > >   ===================================================================
 > > >   --- configure.ac        (revision 120101)
 > > >   +++ configure.ac        (working copy)
 > > >   @@ -323,9 +323,9 @@
 > > >             GCC_UNWIND_INCLUDE=
 > > >             GCJ="${target_noncanonical}-gcj"
 > > >          else
 > > >   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
 > > >   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
 > > >          fi
 > > >   
 > > > Specifically, without this patch the build process attempts to invoke
 > > > i386-apple-darwin-gcj (in my case), which does not exist until "make
 > > > install" happens (and even then, it winds up in the install directory,
 > > > not accessible to the build).
 > > > 
 > > > May I commit this patch?
 > >
 > >Yes.
 > 
 > I don't see how this:
 > 
 > > >   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
 > 
 > ...could possibly be right. Adam, are you building on Linux or Mactel?
 > What the above line is assuming is that the intermediate compiler is
 > suitable for building libgcj. This is only true when build=host, which
 > clearly isn't true for the case when we want to build an i686-pc-mingw32
 > compiler on i686-pc-linux-gnu using a cross compiler.

Mmm, you're right, and I was wrong.  Seems like Adam has a localized
configuration issue.

Andrew.

canadian vs build==host configury

[Adam Megacz]

Mohan Embar <gnustuff@thisiscool.com> writes:
> I don't see how this:
>
>> >   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
>
> ...could possibly be right. Adam, are you building on Linux or Mactel?

Linux.

> What the above line is assuming is that the intermediate compiler is
> suitable for building libgcj. This is only true when build=host, which

That is the case; at the moment I am doing (build==host)!=target.
The previous configury was broken for that case.

> That means building the cross compiler, installing it, then adjusting your
> system path accordingly before doing the crossed-native build.

Perhaps, but this should not be necessary when build==host.

If I understand your email correctly, you need to do a "make install"
before building libgcj when creating a Canadian cross-compiler and
then let libgcj's build process find the installed compiler.  However,
this had not previously been required for build==host cross-compilers.
Did that change?

I think Canadian cross-builds need their own case arm in that block of
configure.ac (the "we cannot execute the compiler we just built" case,
which is not identical to the "we are making a cross-compiler" case).

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Re: canadian vs build==host configury (and $with_cross_host)

[Adam Megacz]

Adam Megacz <megacz@cs.berkeley.edu> writes:
> I think Canadian cross-builds need their own case arm in that block of
> configure.ac (the "we cannot execute the compiler we just built" case,
> which is not identical to the "we are making a cross-compiler" case).

I see there's some code that attempts to do this with $which_gcj.
Unfortunately it relies on $with_cross_host, which does not work
properly for non-canadian (host==build) cross-compiles:

   gcc/configure.in:

   # Passing a --with-cross-host argument lets the target libraries know
   # whether they are being built with a cross-compiler or being built
   # native.  However, it would be better to use other mechanisms to make the 
   # sorts of decisions they want to make on this basis.  Please consider
   # this option to be deprecated.  FIXME.

   if test x${is_cross_compiler} = xyes ; then
     target_configargs="--with-cross-host=${host_alias} ${target_configargs}"
   fi

If you invoke

  ./configure --target=foo

You get

  libgcj/configure --with-cross-host=""

(that is, the empty string).
   
What is the right thing to do here?

  - a

Re: canadian vs build==host configury (and $with_cross_host)

[Tom Tromey]

>>>>> "Adam" == Adam Megacz <megacz@cs.berkeley.edu> writes:

  # Passing a --with-cross-host argument lets the target libraries know
  # whether they are being built with a cross-compiler or being built
  # native.  However, it would be better to use other mechanisms to make the 
  # sorts of decisions they want to make on this basis.  Please consider
  # this option to be deprecated.  FIXME.

I wonder what those other mechanisms could be.

Perhaps, if we always use the canonical names for decision-making in
configure.ac, we can just:

if test -z "$with_cross_host"; then
  with_cross_host=$build
fi

$with_cross_host should only be empty if the user initially did not
pass --host to configure.  So, it should default to the build machine.

Tom

Re: canadian vs build==host configury (and $with_cross_host)

[Mohan Embar]

Hi All,

>  # Passing a --with-cross-host argument lets the target libraries know
>  # whether they are being built with a cross-compiler or being built
>  # native.  However, it would be better to use other mechanisms to make the 
>  # sorts of decisions they want to make on this basis.  Please consider
>  # this option to be deprecated.  FIXME.
>
>I wonder what those other mechanisms could be.
>
>Perhaps, if we always use the canonical names for decision-making in
>configure.ac, we can just:
>
>if test -z "$with_cross_host"; then
>  with_cross_host=$build
>fi
>
>$with_cross_host should only be empty if the user initially did not
>pass --host to configure.  So, it should default to the build machine.

My $0.02:

http://gcc.gnu.org/ml/java-patches/2006-q4/msg00319.html
http://gcc.gnu.org/ml/java-patches/2006-q4/msg00321.html

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: canadian vs build==host configury (and $with_cross_host)

[Tom Tromey]

>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:

>> $with_cross_host should only be empty if the user initially did not
>> pass --host to configure.  So, it should default to the build machine.

Mohan> http://gcc.gnu.org/ml/java-patches/2006-q4/msg00321.html

Yeah, these are equivalent.  In the URL cited you suggest using the
output of config.guess... that's the same as $build.

Tom

Re: canadian vs build==host configury

[Mohan Embar]

Hi Adam,

>> I don't see how this:
>>
>>> >   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
>>
>> ...could possibly be right. Adam, are you building on Linux or Mactel?
>
>Linux.
>
>> What the above line is assuming is that the intermediate compiler is
>> suitable for building libgcj. This is only true when build=host, which
>
>That is the case; at the moment I am doing (build==host)!=target.
>The previous configury was broken for that case.

I should have clarified this with you.

>> That means building the cross compiler, installing it, then adjusting your
>> system path accordingly before doing the crossed-native build.
>
>Perhaps, but this should not be necessary when build==host.

You're right. This isn't necessary with build==host. You can use the
intermediate compiler if build==host && host!=target. I am explicitly
setting build and host, which is why I'm not seeing the issues you're
describing. I have to rush out now, but will talk more when I get back.
If Tom's listening, he has a black belt in this and could chime in too.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: canadian vs build==host configury

[Adam Megacz]

Mohan Embar <gnustuff@thisiscool.com> writes:
> You're right. This isn't necessary with build==host. You can use the
> intermediate compiler if build==host && host!=target. I am explicitly
> setting build and host, which is why I'm not seeing the issues you're
> describing. I have to rush out now, but will talk more when I get back.
> If Tom's listening, he has a black belt in this and could chime in too.

My inclination is to figure out some way to choose $GCJ and $GCJH
without relying on $with_cross_host.

Is there any problem with something close to this?

  built_gcc_dash_v=${built_gcc_dir}/gcj${host_exeext} -v 2>&1
  built_gcc_dir_target=`${built_gcc_dash_v} | grep Target | sed 's_Target: __'`

  if test "x${built_gcc_dir_target}" = "x${target}"; then
      GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
      GCH="$built_gcc_dir/gch"

  else
      # $built_gcc won't help us, so it's up to the user to make sure
      # ${target_noncanonical}-foo is in their $PATH
      GCJ="${target_noncanonical}-gcj"
      GCH="${target_noncanonical}-gch"

  fi

Basically, "If ${built_gcc_dir}/gcj is executable (on ${build}) AND it
reports its target as our desired ${target}, then use it.  In all
other situations, leave it up to the user to ensure that
${target_noncanonical}-gcj is in the $PATH".

  - a

Re: canadian vs build==host configury

[Mohan Embar]

Hi Adam,

>My inclination is to figure out some way to choose $GCJ and $GCJH
>without relying on $with_cross_host.

This may be a worthy goal, and I understand the top-level configury
contains an admonition that this behavior shouldn't be relied on,
but doing an:

find . -name 'configure.ac' | xargs grep with_cross_host

...shows me a number of cases where this is being relied on.
I can't imagine this being yanked anytime soon without someone
screaming (but then again, what do I know....).

In particular, take a look at boehm-gc's configure.ac. What are
the implications of with_cross_host not being defined when it
really should be?

For me, the path of least resistance seems to be to throw in the towel
and simply set build, host and target explicitly (cf. cfgxgcc.sh, which
I got from Ranjit's original scripts):

BUILD=`$GCC_SRC_DIR/config.guess`
HOST=$BUILD
TARGET=$MINGW32_TARGET_NAME

Or else, it might be possible in the top-level configure script to test
if host="" and target!=`$GCC_SRC_DIR/config.guess` and then set host
to `$GCC_SRC_DIR/config.guess`. This would be legitimizing with_cross_host,
though, which seems to not be what the top-level folks want.

If we really wanted to insist on our right to not set the host explicitly
for cross builds and after verifying that this doesn't break the configury
of other subsystems, we could also check for target!=`$GCC_SRC_DIR/config.guess`
and with_cross_host="" in libjava configure.ac and if this is true, set
with_cross_host to `$GCC_SRC_DIR/config.guess`.

All of this seems like more trouble than it's worth, though. I'd be on
board with you with your "try to execute the built compiler" trick if it
weren't for other subsystems' reliance on with_cross_host.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: canadian vs build==host configury

[Adam Megacz]

Mohan Embar <gnustuff@thisiscool.com> writes:
> All of this seems like more trouble than it's worth, though. I'd be on
> board with you with your "try to execute the built compiler" trick if it
> weren't for other subsystems' reliance on with_cross_host.

Empirically, I can confirm that none of those other subsystems break
when with_cross_host="".  I can't speak to exactly what they use it
for, but they all cope properly with the case where it is missing.

I think the decision comes down to choosing one of:

  1. Add more code to handle $with_cross_host=""

  2. Don't rely on $with_cross_host

  3. Always bail out with an error when --target is set but --build is
     not, and declare this configuration to be illegal.

I'm okay with any of these, but I'm not really okay with the current
situation where libgcj relies on $with_cross_host to a degree which
other subsystems don't.

The suggestions for how to accomplish #1 without implicitly doing #2
sound reasonable, but I personally do not understand the ramifications
of those changes well enough to feel comfortable making them myself.
If we could convince the top-level people to make sure that
(canonical) $build, $target, and $host are always set to something
non-empty, that would be ideal.

Is #3 acceptable?

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380

Re: canadian vs build==host configury

[Mohan Embar]

Hi Adam,

>  1. Add more code to handle $with_cross_host=""
>
>  2. Don't rely on $with_cross_host
>
>  3. Always bail out with an error when --target is set but --build is
>     not, and declare this configuration to be illegal.
>
>I'm okay with any of these, but I'm not really okay with the current
>situation where libgcj relies on $with_cross_host to a degree which
>other subsystems don't.
>
>The suggestions for how to accomplish #1 without implicitly doing #2
>sound reasonable, but I personally do not understand the ramifications
>of those changes well enough to feel comfortable making them myself.
>If we could convince the top-level people to make sure that
>(canonical) $build, $target, and $host are always set to something
>non-empty, that would be ideal.
>
>Is #3 acceptable?

Does the top-level configure fill in a value for build when it's omitted or
does it leave it blank?

If it's decided that this is worth addressing, my vote would be to fill
in whatever is missing with the output of the top-level config.guess (option #1)
unless someone sees a reason why this wouldn't work, but I'm willing to go
with whatever the consensus is.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: retracting my retraction [patch included]

[Tom Tromey]

>>>>> "Adam" == Adam Megacz <megacz@cs.berkeley.edu> writes:

Sorry about the delay on reading this.
I finally read this whole thread.

Adam>   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
Adam>   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"

I think this patch is probably causing problems for Marco.
However I'm not certain.

How exactly do you run configure?

Tom

Re: retracting my retraction [patch included]

[Mohan Embar]

Hi All,

>Sorry about the delay on reading this.
>I finally read this whole thread.
>
>Adam>   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
>Adam>   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
>
>I think this patch is probably causing problems for Marco.
>However I'm not certain.

Whoa. Did this actually get committed? In one of the follow-ups,
I pointed out that this was wrong and Andrew came around and
agreed with me. This hadn't gotten committed to the ecj branch
at the time that I was working on an alternative patch.

OK. Looking at SVN, I see this has been committed. This is wrong
for the reasons I mentioned in the followup and should be reverted:

http://gcc.gnu.org/ml/java-patches/2006-q4/msg00313.html

For some reason, this was applied against the mainline and not to
gcj-eclipse-merge-branch. I would have never thought to check
for this scenario when I saw Marco's emails.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

libjava configury logic for cross builds (was Re: retracting my retraction [patch included])

[Mohan Embar]

Hi All,

>>Adam>   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
>>Adam>   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"

For the record, I'm going to be highly skeptical of any attempt to
mess with any of the libjava configury code related to cross builds
simply because I thought about it and tested it so heavily. That's
not to say that there are no mistakes, just that I'm going to
skeptical :):

http://gcc.gnu.org/ml/java-patches/2003-q2/msg00111.html

I haven't reread the analysis, which is almost four years old (I was two-months
fresh into this), so I'm not sure how much of it is correct.... However, I think
it should be required reading for anyone wanting to mess around with this stuff.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: retracting my retraction [patch included]

[Andrew Haley]

Mohan Embar writes:
 > Hi All,
 > 
 > >Sorry about the delay on reading this.
 > >I finally read this whole thread.
 > >
 > >Adam>   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
 > >Adam>   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
 > >
 > >I think this patch is probably causing problems for Marco.
 > >However I'm not certain.
 > 
 > Whoa. Did this actually get committed? In one of the follow-ups,
 > I pointed out that this was wrong and Andrew came around and
 > agreed with me. This hadn't gotten committed to the ecj branch
 > at the time that I was working on an alternative patch.
 > 
 > OK. Looking at SVN, I see this has been committed. This is wrong
 > for the reasons I mentioned in the followup and should be reverted:
 > 
 > http://gcc.gnu.org/ml/java-patches/2006-q4/msg00313.html

Go on, then.

Andrew.

Re: retracting my retraction [patch included]

[Marco Trudel]

Andrew Haley wrote:
> Mohan Embar writes:
>  > Hi All,
>  > 
>  > >Sorry about the delay on reading this.
>  > >I finally read this whole thread.
>  > >
>  > >Adam>   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
>  > >Adam>   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
>  > >
>  > >I think this patch is probably causing problems for Marco.
>  > >However I'm not certain.
>  > 
>  > Whoa. Did this actually get committed? In one of the follow-ups,
>  > I pointed out that this was wrong and Andrew came around and
>  > agreed with me. This hadn't gotten committed to the ecj branch
>  > at the time that I was working on an alternative patch.
>  > 
>  > OK. Looking at SVN, I see this has been committed. This is wrong
>  > for the reasons I mentioned in the followup and should be reverted:
>  > 
>  > http://gcc.gnu.org/ml/java-patches/2006-q4/msg00313.html
> 
> Go on, then.

Since this patch
- generally breaks all canadian cross-compilations
- this was pointed out already before committing
- Andrew gave his ok
I'd also go for reverting it. Mohan, would you do the honor?


thanks
Marco

Re: retracting my retraction [patch included]

[Mohan Embar]

Hi All,

>>  > >Adam>   -         GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
>>  > >Adam>   +         GCJ="$built_gcc_dir/gcj -B$built_gcc_dir/"
>>  > >
>>  > OK. Looking at SVN, I see this has been committed. This is wrong
>>  > for the reasons I mentioned in the followup and should be reverted:
>>  > 
>>  > http://gcc.gnu.org/ml/java-patches/2006-q4/msg00313.html
>> 
>> Go on, then.
>
>Since this patch
>- generally breaks all canadian cross-compilations
>- this was pointed out already before committing
>- Andrew gave his ok
>I'd also go for reverting it. Mohan, would you do the honor?

I told Andrew off list that I won't be able to do this
before Monday or Tuesday at the earliest. If someone else wants
to do this beforehand, be my guest.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: retracting my retraction [patch included]

[Tom Tromey]

>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:

Mohan> I told Andrew off list that I won't be able to do this
Mohan> before Monday or Tuesday at the earliest. If someone else wants
Mohan> to do this beforehand, be my guest.

I'm reverting it now.

Tom

Patch: Fix GCJH for cross builds (was Re: retracting my retraction [patch included])

[Mohan Embar]

Hi Tom,

>Mohan> I told Andrew off list that I won't be able to do this
>Mohan> before Monday or Tuesday at the earliest. If someone else wants
>Mohan> to do this beforehand, be my guest.
>
>I'm reverting it now.

Only one portion of Adam's patch was reverted. This patch
reverts the other piece. OK for trunk?

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

2007-02-03  Mohan Embar  <gnustuff@thisiscool.com>

	* configure: Rebuilt.
	* configure.ac (GCJH): Reverted second part of patch of 2006-12-20.

Index: configure.ac
===================================================================
--- configure.ac	(revision 121548)
+++ configure.ac	(working copy)
@@ -358,7 +358,7 @@
       else
          GCJ="${target_noncanonical}-gcj -B`${PWDCMD-pwd}`/"
       fi
-      GCJH="$built_gcc_dir/gcjh"
+      GCJH='$(target_noncanonical)-gcjh'
    ;;
    path)
       GCJ="gcj -B`${PWDCMD-pwd}`/"

Re: Patch: Fix GCJH for cross builds (was Re: retracting my retraction [patch included])

[Andrew Haley]

Mohan Embar writes:
 > Hi Tom,
 > 
 > >Mohan> I told Andrew off list that I won't be able to do this
 > >Mohan> before Monday or Tuesday at the earliest. If someone else wants
 > >Mohan> to do this beforehand, be my guest.
 > >
 > >I'm reverting it now.
 > 
 > Only one portion of Adam's patch was reverted. This patch
 > reverts the other piece. OK for trunk?

OK.

Andrew.

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Tom Tromey]

>>>>> "Adam" == Adam Megacz <adam@megacz.com> writes:

Adam>         * Makefile.am: add libgcj-$(gcc_version).jar to -fclasspath=

I think the bootclasspath setting should handle this ok.
What did this fix for you?  Or what went wrong originally?

Adam>         * configure.ac: change settings for GCJ and GCJFLAGS to fix
Adam>         cross-builds

I suspect the bug prompting this was fixed instead by Mohan's
top-level configure fix... is that so?

Tom

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Mohan Embar]

>I suspect the bug prompting this was fixed instead by Mohan's
>top-level configure fix... is that so?

FYI: I"m testing more configury fixes at the moment (build-x-host, etc.)
Stay tuned. Just built a native Windows gcj-ecj. I'm transferring from
Linux to Windows as we speak....

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Mohan Embar]

Hi All,

>FYI: I"m testing more configury fixes at the moment (build-x-host, etc.)
>Stay tuned. Just built a native Windows gcj-ecj. I'm transferring from
>Linux to Windows as we speak....

Promising, though with a couple of glitches. I want to revisit
my strategy for the configury, but I nonetheless got a Windows
compiler. It won't run on Windows because:the argument to -fbootclasspath
passed to jc1 and ecj1 can have spaces in it, which isn't being
quoted properly and because we unconditionally use ":" instead
of the system path separator to separate classpath entries.
I'll dig into this but if anyone's listening right now and can
tell me offhand where this is happening, I'd be grateful.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: [gcj-eclipse-merge-branch] fix cross-build configury/makery

[Tom Tromey]

>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:

Mohan> It won't run on Windows because:the argument to -fbootclasspath
Mohan> passed to jc1 and ecj1 can have spaces in it, which isn't being
Mohan> quoted properly and because we unconditionally use ":" instead
Mohan> of the system path separator to separate classpath entries.
Mohan> I'll dig into this but if anyone's listening right now and can
Mohan> tell me offhand where this is happening, I'd be grateful.

gcc/java/jvspec.c:lang_specific_driver()

This munges the command line arguments a little before specs
processing.

Tom

Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Mohan Embar]

Hi All,

This patch unbreaks the (linux,mingw) cross build and also
allows building the native Windows compiler on Linux. It
attempts to address the following issues we've discussed
previously.

- ecj1 and ecjx should be built with a build-x-host compiler,
  not a build-x-target compiler as is currently being done

- ecj.jar should be compiled for non-shared and cross builds
  and not interpreted

This patch probably doesn't properly handle the selection of
the build-x-host compiler. It simply picks the name based on
$with_cross_host instead of doing the proper configure tests
for it. This was a bit over my head and I rationalized it away
by saying to myself that we don't properly test for the proper
functioning of other things like gcjh, but this is a pretty
shallow rationalization. Anyway, it unbreaks the cross build
and renders it functional.

I didn't do the --whole-archive thing. With libtool in the
picture, this appears to be a pain in the *@($. The only
straightforward way of doing this with libtool seems to be
if libgcj were in a convenience library, which as far as I
can see, isn't the case.

http://gcc.gnu.org/ml/java-patches/2005-q1/msg00402.html

In any case, the statically-linked ecj1 seems to work okay,
so I guess we dodged a bullet here for now.

I tested this on the following (build,host,target) combinations:

- (i686-pc-linux-gnu,i686-pc-linux-gnu,i686-pc-linux-gnu)
- (i686-pc-linux-gnu,i686-pc-linux-gnu,i686-pc-mingw32)
- (i686-pc-linux-gnu,i686-pc-mingw32,i686-pc-mingw32)

...and everything seemed to work properly - it preserves
the original behavior for a Linux native build. I want to
do build these combinations once again completely from
scratch (after which I'll upload my MinGW ecj build).

Let me know what you think (and also whether I can check in
the PATH_SEPARATOR patch).

I'm feeling a bit burned out, so I'm not going to get to fixing
this up:

http://gcc.gnu.org/ml/java-patches/2006-q4/msg00209.html

...right away. (See the followups for Andrew's feedback.)
If anyone (<cough>Adam</cough>) wants to take this from me,
be my guest. Otherwise, I'll get to it next week or so.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

2006-12-07  Mohan Embar  <gnustuff@thisiscool.com>

	* configure, Makefile.in: Rebuilt.
	* configure.ac: (GCJ_FOR_ECJX) New substitution.
	(host_exeext): Likewise.
	(ENABLE_SHARED): New conditional,
	* Makefile.am: Added GCJ_FOR_ECJX and GCJ_FOR_ECJX_LINK.
	(install-exec-hook): Correctly rename ecjx to ecj1.
	(ecjx_LINK, ecjx_LDFLAGS, ecjx_LDADD, ecjx_DEPENDENCIES): Define
	as a function of whether we're doing a native and/or shared build.
	

Index: configure.ac
===================================================================
--- configure.ac	(revision 119567)
+++ configure.ac	(working copy)
@@ -308,19 +308,23 @@
 
 NATIVE=yes
 
-# Which gcj do we use?
+# Which gcj and host gcj (for ecjx) do we use?
 which_gcj=default
+host_exeext=${ac_exeext}
+GCJ_FOR_ECJX=
 built_gcc_dir="`cd ${builddotdot}/../../${host_subdir}/gcc && ${PWDCMD-pwd}`"
 if test -n "${with_cross_host}"; then
   # We are being configured with a cross compiler. We can't
   # use ac_exeext, because that is for the target platform.
   NATIVE=no
   cross_host_exeext=
+  GCJ_FOR_ECJX="${with_cross_host}-gcj"
   case "${with_cross_host}" in
      *mingw* | *cygwin*)
          cross_host_exeext=.exe
      ;;
   esac
+  host_exeext=${cross_host_exeext}
   if test -x "${built_gcc_dir}/gcj${cross_host_exeext}"; then
      if test x"$build_noncanonical" = x"$with_cross_host"; then
         # Ordinary cross (host!=target and host=build)
@@ -367,7 +371,9 @@
    ;;
 esac
 
+AC_SUBST(GCJ_FOR_ECJX)
 AC_SUBST(GCJH)
+AC_SUBST(host_exeext)
 
 # Create it, so that compile/link tests don't fail
 test -f libgcj.spec || touch libgcj.spec
@@ -1317,6 +1323,7 @@
 AC_SUBST(IEEESPEC)
 
 AM_CONDITIONAL(NATIVE, test "$NATIVE" = yes)
+AM_CONDITIONAL(ENABLE_SHARED, test "$enable_shared" = yes)
 AM_CONDITIONAL(NEEDS_DATA_START, test "$NEEDS_DATA_START" = yes && test "$NATIVE" = yes)
 AC_SUBST(GCC_UNWIND_INCLUDE)
 
Index: Makefile.am
===================================================================
--- Makefile.am	(revision 119567)
+++ Makefile.am	(working copy)
@@ -105,6 +105,8 @@
 
 GCJLINK = $(LIBTOOL) --tag=GCJ --mode=link $(GCJ) -L$(here) $(JC1FLAGS) \
           $(LDFLAGS) -o $@
+GCJ_FOR_ECJX = @GCJ_FOR_ECJX@
+GCJ_FOR_ECJX_LINK = $(GCJ_FOR_ECJX) -o $@
 LIBLINK = $(LIBTOOL) --tag=CXX --mode=link $(CXX) -L$(here) $(JC1FLAGS) \
           $(LDFLAGS) $(extra_ldflags_libjava) -o $@
 
@@ -441,8 +443,13 @@
 	rm $(toolexeclibdir)/libgcj_bc.la;
 endif
 if BUILD_ECJ1
-	mv $(DESTDIR)$(libexecsubdir)/ecjx $(DESTDIR)$(libexecsubdir)/ecj1
-endif
+if NATIVE
+	mv $(DESTDIR)$(libexecsubdir)/ecjx$(EXEEXT) $(DESTDIR)$(libexecsubdir)/ecj1$(host_exeext)
+else !NATIVE
+## Undo the prepending of the target prefix
+	mv $(DESTDIR)$(libexecsubdir)/$(target_noncanonical)-ecjx$(EXEEXT) $(DESTDIR)$(libexecsubdir)/ecj1$(host_exeext)
+endif !NATIVE
+endif BUILD_ECJ1
 
 ## Install the headers.  It is fairly ugly that we have to do this by
 ## hand.
@@ -672,13 +679,34 @@
 ## We use the BC ABI here so that we don't need to compile ecj.jar.
 ## Hopefully the user has compiled it into his system .db.
 ## However, even if not it will run reasonably quickly.
-ecjx_LDFLAGS = -findirect-dispatch \
-	--main=org.eclipse.jdt.internal.compiler.batch.GCCMain \
-	-Djava.class.path=$(ECJ_JAR)
+
+ECJX_BASE_FLAGS = -findirect-dispatch \
+	--main=org.eclipse.jdt.internal.compiler.batch.GCCMain
+
+if NATIVE
+
 ecjx_LINK = $(GCJLINK)
+
+if ENABLE_SHARED
+## Use ecj.jar at runtime.
+ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR)
+else !ENABLE_SHARED
+## Use ecj.jar at compile time.
+ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR)
+endif !ENABLE_SHARED
+
 ecjx_LDADD = -L$(here)/.libs libgcj.la
 ecjx_DEPENDENCIES = libgcj.la libgcj.spec
 
+else !NATIVE
+
+ecjx_LINK = $(GCJ_FOR_ECJX_LINK)
+ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR)
+ecjx_LDADD = 
+ecjx_DEPENDENCIES = 
+
+endif !NATIVE
+
 ## This is a dummy definition.
 gappletviewer_SOURCES =
 gappletviewer_LDFLAGS = --main=gnu.classpath.tools.appletviewer.Main \

Re: Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Andrew Haley]

Mohan Embar writes:
 > 
 > I'm feeling a bit burned out, so I'm not going to get to fixing
 > this up:
 > 
 > http://gcc.gnu.org/ml/java-patches/2006-q4/msg00209.html
 > 
 > ...right away. (See the followups for Andrew's feedback.)
 > If anyone (<cough>Adam</cough>) wants to take this from me,
 > be my guest. Otherwise, I'll get to it next week or so.

Fair enough.  The Linux code is more complicated than it needs to be,
anyway.  What we really need, rather than imitating the Linux code, is
the best Windows-specific way to do it.

From what I can determine by scanning the net, this is probably a call
to WaitForSingleObject() in park() and a call to SetEvent() in
unpark().  (See
http://www.codersource.net/win32_waitforsingleobject.html,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitforsingleobject.asp.)
It doesn't have to be anything more complicated than that.

So, apart from the timer code, park() and unpark() may be as simple as
this:


void
_Jv_ThreadPark (jboolean isAbsolute, jlong time)
{
  /* ... */

  /* If we have a permit, return immediately.  */
  if (compare_and_swap 
      (ptr, Thread::THREAD_PARK_PERMIT, Thread::THREAD_PARK_RUNNING))
    return;

  /* ... */
      
  if (compare_and_swap 
      (ptr, Thread::THREAD_PARK_RUNNING, Thread::THREAD_PARK_PARKED))
    {
      WaitForSingleObject (nt->park_event, millis); 

      /* If we were unparked by some other thread, this will already
	 be in state THREAD_PARK_RUNNING.  If we timed out, we have to
	 do it ourself.  */
      compare_and_swap 
	(ptr, Thread::THREAD_PARK_PARKED, Thread::THREAD_PARK_RUNNING);
    }
}


void
_Jv_ThreadUnpark (::java::lang::Thread *thread)
{

  /* ... */

  /* If this thread is in state RUNNING, give it a permit and return
     immediately.  */
  if (compare_and_swap 
      (ptr, Thread::THREAD_PARK_RUNNING, Thread::THREAD_PARK_PERMIT))
    return;
  
  /* If this thread is parked, put it into state RUNNING and send it a
     signal.  */
  if (compare_and_swap 
      (ptr, Thread::THREAD_PARK_PARKED, Thread::THREAD_PARK_RUNNING))
    {
      SetEvent (nt->park_event);       
    }
}


Andrew.

Re: Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Mohan Embar]

Hi Andrew,

From what I can determine by scanning the net, this is probably a call
>to WaitForSingleObject() in park() and a call to SetEvent() in
>unpark().  (See
>http://www.codersource.net/win32_waitforsingleobject.html,
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitforsingleobject.asp.)
>It doesn't have to be anything more complicated than that.

Thanks. I'm not puzzled about how to implement this and was
going to suggest something along these lines too, but the
devil is in the details :) It has to be coded up, built, and
most importantly, tested (i.e. find and doanload the TCK, etc.)
A tad too much for me after I've been at this for two days like a
madman with very little sleep....

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Andrew Haley]

Mohan Embar writes:
 > Hi Andrew,
 > 
 > >From what I can determine by scanning the net, this is probably a call
 > >to WaitForSingleObject() in park() and a call to SetEvent() in
 > >unpark().  (See
 > >http://www.codersource.net/win32_waitforsingleobject.html,
 > >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitforsingleobject.asp.)
 > >It doesn't have to be anything more complicated than that.
 > 
 > Thanks. I'm not puzzled about how to implement this and was
 > going to suggest something along these lines too, but the
 > devil is in the details :) It has to be coded up, built, and
 > most importantly, tested (i.e. find and doanload the TCK, etc.)

Yeah.  IIRC that part was a pain.

 > A tad too much for me after I've been at this for two days like a
 > madman with very little sleep....

Oh, fair enough.  It's just that park() and unpark() are a bit
underdocumented, so I wanted to make sure it was all clear.

Andrew.

Re: Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Mohan Embar]

Hi Andrew,

> > >From what I can determine by scanning the net, this is probably a call
> > >to WaitForSingleObject() in park() and a call to SetEvent() in
> > >unpark().  (See
> > >http://www.codersource.net/win32_waitforsingleobject.html,
> > >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitforsingleobject.asp.)
> > >It doesn't have to be anything more complicated than that.

>Oh, fair enough.  It's just that park() and unpark() are a bit
>underdocumented, so I wanted to make sure it was all clear.

I appreciate that. You've bascially saved me the trouble of sketching this out
myself.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Andrew Haley]

Mohan Embar writes:
 > Hi Andrew,
 > 
 > > > >From what I can determine by scanning the net, this is probably a call
 > > > >to WaitForSingleObject() in park() and a call to SetEvent() in
 > > > >unpark().  (See
 > > > >http://www.codersource.net/win32_waitforsingleobject.html,
 > > > >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitforsingleobject.asp.)
 > > > >It doesn't have to be anything more complicated than that.
 > 
 > >Oh, fair enough.  It's just that park() and unpark() are a bit
 > >underdocumented, so I wanted to make sure it was all clear.
 > 
 > I appreciate that. You've bascially saved me the trouble of sketching this out
 > myself.

Mmm, good.  

There are some very subtle details that are easy to miss: for example,
a Thread.interrupt() followed by a park() does not block the thread
because Thread.interrupt() always does an unpark().  This means that
there is no race between Thread.interrupt() and park(); it doesn't
matter in which order they occur.  I think your proposed change might
have broken that.

Andrew.

Re: Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Mohan Embar]

Hi Andrew,

>There are some very subtle details that are easy to miss: for example,
>a Thread.interrupt() followed by a park() does not block the thread
>because Thread.interrupt() always does an unpark().  This means that
>there is no race between Thread.interrupt() and park(); it doesn't
>matter in which order they occur.  I think your proposed change might
>have broken that.

You're right. I hadn't completely understood the concept of permits when
I wrote that patch. Rereading the JavaDoc for LockSupport, I see that I
can't eliminate the call to unpark() in Thread.interrupt().

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

LockSupportTest.java

[Mohan Embar]

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

Hi All,

I'm trying to stop myself from working on the park()/unpark()
stuff on MinGW ecj, but couldn't help already downloading the
appropriate TCK file and making it a standalone file independent
of JUnit. I've attached it if anyone's interested.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/


[-- Attachment #2: LockSupportTest.java --]
[-- Type: application/octet-stream, Size: 3624 bytes --]

import java.lang.reflect.Method;
import java.util.Date;
import java.util.concurrent.locks.LockSupport;
import java.util.concurrent.locks.ReentrantLock;

public class LockSupportTest
{
public static void main(String[] args)
{
	LockSupportTest lst = new LockSupportTest();
	
	for (Method m : lst.getClass().getDeclaredMethods())
	{
		String name = m.getName();
		if (name.startsWith("test") && m.getReturnType() == void.class)
		{
			System.out.println(name+"...");
			try
			{
				m.invoke(lst, (Object[]) null);
			}
			catch (Exception e)
			{
				unexpectedException(e);
			}
		}
	}
}
	
/**
 * park is released by unpark occurring after park
 */
public void testPark()
{
	Thread t = new Thread(new Runnable()
	{
		public void run()
		{
			try
			{
				LockSupport.park();
			}
			catch (Exception e)
			{
				threadUnexpectedException(e);
			}
		}
	});
	try
	{
		t.start();
		Thread.sleep(SHORT_DELAY_MS);
		LockSupport.unpark(t);
		t.join();
	}
	catch (Exception e)
	{
		unexpectedException(e);
	}
}

/**
 * park is released by unpark occurring before park
 */
public void testPark2()
{
	Thread t = new Thread(new Runnable()
	{
		public void run()
		{
			try
			{
				Thread.sleep(SHORT_DELAY_MS);
				LockSupport.park();
			}
			catch (Exception e)
			{
				threadUnexpectedException(e);
			}
		}
	});
	try
	{
		t.start();
		LockSupport.unpark(t);
		t.join();
	}
	catch (Exception e)
	{
		unexpectedException(e);
	}
}

/**
 * park is released by interrupt
 */
public void testPark3()
{
	Thread t = new Thread(new Runnable()
	{
		public void run()
		{
			try
			{
				LockSupport.park();
			}
			catch (Exception e)
			{
				threadUnexpectedException(e);
			}
		}
	});
	try
	{
		t.start();
		Thread.sleep(SHORT_DELAY_MS);
		t.interrupt();
		t.join();
	}
	catch (Exception e)
	{
		unexpectedException(e);
	}
}

/**
 * park returns if interrupted before park
 */
public void testPark4()
{
	final ReentrantLock lock = new ReentrantLock();
	lock.lock();
	Thread t = new Thread(new Runnable()
	{
		public void run()
		{
			try
			{
				lock.lock();
				LockSupport.park();
			}
			catch (Exception e)
			{
				threadUnexpectedException(e);
			}
		}
	});
	try
	{
		t.start();
		t.interrupt();
		lock.unlock();
		t.join();
	}
	catch (Exception e)
	{
		unexpectedException(e);
	}
}

/**
 * parkNanos times out if not unparked
 */
public void testParkNanos()
{
	Thread t = new Thread(new Runnable()
	{
		public void run()
		{
			try
			{
				LockSupport.parkNanos(1000);
			}
			catch (Exception e)
			{
				threadUnexpectedException(e);
			}
		}
	});
	try
	{
		t.start();
		t.join();
	}
	catch (Exception e)
	{
		unexpectedException(e);
	}
}

/**
 * parkUntil times out if not unparked
 */
public void testParkUntil()
{
	Thread t = new Thread(new Runnable()
	{
		public void run()
		{
			try
			{
				long d = new Date().getTime() + 100;
				LockSupport.parkUntil(d);
			}
			catch (Exception e)
			{
				threadUnexpectedException(e);
			}
		}
	});
	try
	{
		t.start();
		t.join();
	}
	catch (Exception e)
	{
		unexpectedException(e);
	}
}

// private //
static long SHORT_DELAY_MS = 100; 

private static void threadUnexpectedException(Exception e)
{
	System.err.println("["+Thread.currentThread().getName()+"] Unexpected exception: "+e);
	e.printStackTrace();
}

private static void unexpectedException(Exception e)
{
	System.err.println("Unexpected exception: "+e);
	e.printStackTrace();
}
}

Re: Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Mohan Embar]

Hi All,

>I tested this on the following (build,host,target) combinations:
>
>- (i686-pc-linux-gnu,i686-pc-linux-gnu,i686-pc-linux-gnu)
>- (i686-pc-linux-gnu,i686-pc-linux-gnu,i686-pc-mingw32)
>- (i686-pc-linux-gnu,i686-pc-mingw32,i686-pc-mingw32)
>
>...and everything seemed to work properly - it preserves
>the original behavior for a Linux native build. I want to
>do build these combinations once again completely from
>scratch (after which I'll upload my MinGW ecj build).

FWIW, I rebuilt everything from scratch and things check out
okay for all three build configurations. Pretty cool to see
this stuff in action. Thanks for all your help and the nice
work. I'll be releasing a MinGW build today.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Re: Patch [ecj]: Fix cross-configury issues / compile ecj.jar for non-shared builds

[Tom Tromey]

>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:

Mohan> This patch unbreaks the (linux,mingw) cross build and also
Mohan> allows building the native Windows compiler on Linux.

This is ok, thanks.

Mohan> This patch probably doesn't properly handle the selection of
Mohan> the build-x-host compiler. It simply picks the name based on
Mohan> $with_cross_host instead of doing the proper configure tests
Mohan> for it.

I think you're simply required to have one available.  If you're
building an ordinary cross, this is just the system compiler.  If
you're building a canadian cross, you need one to build gcc, etc.

Tom