[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives

2018-03-08 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #9 from Eric Gallager  ---
libjava has been removed from gcc.

[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives

2009-06-01 Thread eduardo dot m dot costa at gmail dot com


--- Comment #8 from eduardo dot m dot costa at gmail dot com  2009-06-01 
19:48 ---
(In reply to comment #7)
 Subject: Re:  [arm] libjava build failure due to missing
  thread synchronization primitives
 
  I'm not quite sure what you're trying to do.
 
  What did you change to support arm-eabi* ?
  
  I changed libjava/configure.host to also support arm-eabi
  (arm*-elf|arm*-eabi)but that probably wasn't enough. Given that arm-elf 
  appears
  to be supported for this as per the last comment in the bug report, I 
  thought
  it would make sense to have it working for arm-eabi.
  
  I decided to go back and try an arm-elf build as well just now. I get a 
  failure
  with jni-libjvm.cc with an error about ParkHelper not naming a type. Hence 
  this
  appears to be broken on trunk as revision 146222 for arm-elf as well as
  arm-eabi.
 
 Probably.  The java.lang.concurrent library requires thread support,
 so the only way you're going to get it to run with no threads is to
 create dummy definitions for ParkHelper.  That should be easy, since
 null definitions for park() and unpark() will be fine.
 
 Just add these to libjava/no-threads.cc and libjava/include/no-threads.h.
 
 Andrew.
 

I tryed this:

libjava/include/no-threads.h

struct ParkHelper
{
  void init ();
  void deactivate ();
  void destroy ();
  void park (jboolean isAbsolute, jlong time);
  void unpark ();
};

libjava/no-threads.cc

void ParkHelper::init () {}
void ParkHelper::deactivate () {}
void ParkHelper::destroy () {}
void ParkHelper::park (jboolean isAbsolute, jlong time) {}
void ParkHelper::unpark () {}

But I got more errors on libjava/sysdep/arm/locks.h (thumb mode does not
recognize swp and swpne). 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340



[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives

2009-04-20 Thread aph at redhat dot com


--- Comment #5 from aph at redhat dot com  2009-04-20 08:48 ---
Subject: Re:  [arm] libjava build failure due to missing
 thread synchronization primitives

ramana at gcc dot gnu dot org wrote:
 --- Comment #4 from ramana at gcc dot gnu dot org  2009-04-20 05:58 
 ---
 The build is broken currently for arm-none-eabi targets on trunk. 
 
 Attempting a simple fix of supporting arm-eabi* got me past the error reported
 in the original bug report. but I still get a failure with the following error
 message.

I'm not quite sure what you're trying to do.

What did you change to support arm-eabi* ?

Andrew.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340



[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives

2009-04-20 Thread ramana at gcc dot gnu dot org


--- Comment #6 from ramana at gcc dot gnu dot org  2009-04-20 14:30 ---
Hi Andrew, 

 
 
 I'm not quite sure what you're trying to do.
 
 What did you change to support arm-eabi* ?

I changed libjava/configure.host to also support arm-eabi
(arm*-elf|arm*-eabi)but that probably wasn't enough. Given that arm-elf appears
to be supported for this as per the last comment in the bug report, I thought
it would make sense to have it working for arm-eabi.

I decided to go back and try an arm-elf build as well just now. I get a failure
with jni-libjvm.cc with an error about ParkHelper not naming a type. Hence this
appears to be broken on trunk as revision 146222 for arm-elf as well as
arm-eabi.


Ramana
 
 Andrew.
 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340



[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives

2009-04-20 Thread aph at redhat dot com


--- Comment #7 from aph at redhat dot com  2009-04-20 15:44 ---
Subject: Re:  [arm] libjava build failure due to missing
 thread synchronization primitives

 I'm not quite sure what you're trying to do.

 What did you change to support arm-eabi* ?
 
 I changed libjava/configure.host to also support arm-eabi
 (arm*-elf|arm*-eabi)but that probably wasn't enough. Given that arm-elf 
 appears
 to be supported for this as per the last comment in the bug report, I thought
 it would make sense to have it working for arm-eabi.
 
 I decided to go back and try an arm-elf build as well just now. I get a 
 failure
 with jni-libjvm.cc with an error about ParkHelper not naming a type. Hence 
 this
 appears to be broken on trunk as revision 146222 for arm-elf as well as
 arm-eabi.

Probably.  The java.lang.concurrent library requires thread support,
so the only way you're going to get it to run with no threads is to
create dummy definitions for ParkHelper.  That should be easy, since
null definitions for park() and unpark() will be fine.

Just add these to libjava/no-threads.cc and libjava/include/no-threads.h.

Andrew.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340



[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives

2009-04-19 Thread ramana at gcc dot gnu dot org


--- Comment #4 from ramana at gcc dot gnu dot org  2009-04-20 05:58 ---
The build is broken currently for arm-none-eabi targets on trunk. 

Attempting a simple fix of supporting arm-eabi* got me past the error reported
in the original bug report. but I still get a failure with the following error
message.

 /home/ramana/cos/build-java-also/./gcc/xgcc -shared-libgcc
-B/home/ramana/cos/build-java-also/./gcc -nostdinc++
-L/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libstdc++-v3/src
-L/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libstdc++-v3/src/.libs
-nostdinc -B/home/ramana/cos/build-java-also/arm-none-eabi/thumb/newlib/
-isystem
/home/ramana/cos/build-java-also/arm-none-eabi/thumb/newlib/targ-include
-isystem /home/ramana/cos/combined/newlib/libc/include
-B/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libgloss/arm
-L/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libgloss/libnosys
-L/home/ramana/cos/combined/libgloss/arm -B/usr/local/arm-none-eabi/bin/
-B/usr/local/arm-none-eabi/lib/ -isystem /usr/local/arm-none-eabi/include
-isystem /usr/local/arm-none-eabi/sys-include
-L/home/ramana/cos/build-java-also/./ld -mthumb -DHAVE_CONFIG_H -I.
-I../../../../combined/libjava -I./include -I./gcj
-I../../../../combined/libjava -Iinclude -I../../../../combined/libjava/include
-I../../../../combined/libjava/classpath/include -Iclasspath/include
-I../../../../combined/libjava/classpath/native/fdlibm
-I../../../../combined/libjava/../boehm-gc/include -I../boehm-gc/include
-I../../../../combined/libjava/.././libjava/../gcc
-I../../../../combined/libjava/../zlib -fno-rtti -fnon-call-exceptions
-fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall
-D_GNU_SOURCE -DPREFIX=\/usr/local\
-DTOOLEXECLIBDIR=\/usr/local/arm-none-eabi/lib/thumb\
-DJAVA_HOME=\/usr/local\
-DBOOT_CLASS_PATH=\/usr/local/share/java/libgcj-4.5.0.jar\
-DJAVA_EXT_DIRS=\/usr/local/share/java/ext\
-DGCJ_ENDORSED_DIRS=\/usr/local/share/java/gcj-endorsed\
-DGCJ_VERSIONED_LIBDIR=\/usr/local/lib/thumb/gcj-4.5.0-10\
-DPATH_SEPARATOR=\:\ -DECJ_JAR_FILE=\\
-DLIBGCJ_DEFAULT_DATABASE=\/usr/local/lib/thumb/gcj-4.5.0-10/classmap.db\
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.5.0-10/classmap.db\ -g -O2 -mthumb
-MT jni-libjvm.lo -MD -MP -MF .deps/jni-libjvm.Tpo -c
../../../../combined/libjava/jni-libjvm.cc -o jni-libjvm.o
In file included from ../../../../combined/libjava/include/jvmpi.h:17,
 from ../../../../combined/libjava/include/jvm.h:670,
 from ../../../../combined/libjava/jni-libjvm.cc:14:
../../../../combined/libjava/classpath/include/jni.h:660: note: the mangling of
‘va_list’ has changed in GCC 4.4
In file included from ../../../../combined/libjava/jni-libjvm.cc:14:
../../../../combined/libjava/include/jvm.h:795: error: ‘ParkHelper’ does not
name a type
make[5]: *** [jni-libjvm.lo] Error 1
make[5]: Leaving directory
`/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libjava'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/home/ramana/cos/build-java-also/arm-none-eabi/thumb/libjava'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
`/home/ramana/cos/build-java-also/arm-none-eabi/libjava'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory
`/home/ramana/cos/build-java-also/arm-none-eabi/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/home/ramana/cos/build-java-also'


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aph at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-20 05:58:18
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340