From doko at ubuntu.com Sun Aug 3 10:34:14 2008 From: doko at ubuntu.com (Matthias Klose) Date: Sun, 03 Aug 2008 19:34:14 +0200 Subject: [patch] fix build on architectures with a signed size_t Message-ID: <4895EC16.6030406@ubuntu.com> attached are three patches to build on architectures with a signed size_t (s390-linux-gnu). - jdk-signed-size_t.diff, there's already a compat SSIZE_T macro in the code, just use it. - hotspot-idx_t-signed-size_t.diff, the BitMap code assumes a unsigned size_t. - hotspot-params-signed-size_t.diff, command line parameters of type size_t currently are not supported. As a workaround, add casts. This may be better addressed. Matthias -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jdk-signed-size_t.diff Url: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080803/7513da86/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotspot-idx_t-signed-size_t.diff Url: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080803/7513da86/attachment-0001.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotspot-params-signed-size_t.diff Url: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080803/7513da86/attachment-0002.ksh From fw at deneb.enyo.de Sun Aug 3 15:55:04 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 00:55:04 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4895EC16.6030406@ubuntu.com> (Matthias Klose's message of "Sun, 03 Aug 2008 19:34:14 +0200") References: <4895EC16.6030406@ubuntu.com> Message-ID: <87ej55k8tz.fsf@mid.deneb.enyo.de> * Matthias Klose: > attached are three patches to build on architectures with a signed size_t > (s390-linux-gnu). Yuck. Is this really true? Seems so. C99 requires size_t to be unsigned (section 6.5.3.4), and so does POSIX. I suspsect this was also the case in C90, it's not listed as a change in C99. And if it's unsigned in C90, it's unsigned in C++ (and the The C++ Programming Language, 3rd edition, confirms this). In fact, the GNU C++ standard library assumes that std::size_t is unsigned. IIRC, there is code out there which performs security checks (against integer overflows, for instance) and which assumes that size_t is unsigned. Call me insane, but it's the architecture that needs fixing, not OpenJDK. From fw at deneb.enyo.de Sun Aug 3 16:01:04 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 01:01:04 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <87ej55k8tz.fsf@mid.deneb.enyo.de> (Florian Weimer's message of "Mon, 04 Aug 2008 00:55:04 +0200") References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> Message-ID: <877iaxk8jz.fsf@mid.deneb.enyo.de> * Florian Weimer: > * Matthias Klose: > >> attached are three patches to build on architectures with a signed size_t >> (s390-linux-gnu). > > Yuck. Is this really true? Seems so. No, it's not. At least not in the sid chroot on raptor.debian.org. FWIW, my corrected test case is: #include volatile size_t x; main() { x = -1; if (x < 0) puts("broken"); } From aph at redhat.com Mon Aug 4 04:24:02 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 04 Aug 2008 12:24:02 +0100 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <877iaxk8jz.fsf@mid.deneb.enyo.de> References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> Message-ID: <4896E6D2.9030109@redhat.com> Florian Weimer wrote: > * Florian Weimer: > >> * Matthias Klose: >> >>> attached are three patches to build on architectures with a signed size_t >>> (s390-linux-gnu). >> Yuck. Is this really true? Seems so. > > No, it's not. It's not. 7.17 Common definitions 1 The following types and macros are defined in the standard header . Some are also defined in other headers, as noted in their respective subclauses. 2 The types are ptrdiff_t which is the signed integer type of the result of subtracting two pointers; size_t which is the unsigned integer type of the result of the sizeof operator; Andrew. From fw at deneb.enyo.de Mon Aug 4 04:27:41 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 13:27:41 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4896E6D2.9030109@redhat.com> (Andrew Haley's message of "Mon, 04 Aug 2008 12:24:02 +0100") References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> <4896E6D2.9030109@redhat.com> Message-ID: <873allf2aa.fsf@mid.deneb.enyo.de> * Andrew Haley: > Florian Weimer wrote: >> * Florian Weimer: >> >>> * Matthias Klose: >>> >>>> attached are three patches to build on architectures with a signed size_t >>>> (s390-linux-gnu). >>> Yuck. Is this really true? Seems so. >> >> No, it's not. > > It's not. I was more concerned with the reality on s390, not what's in the standard. Unfortunately, my first test case was wrong. From aph at redhat.com Mon Aug 4 04:36:42 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 04 Aug 2008 12:36:42 +0100 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <873allf2aa.fsf@mid.deneb.enyo.de> References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> <4896E6D2.9030109@redhat.com> <873allf2aa.fsf@mid.deneb.enyo.de> Message-ID: <4896E9CA.60008@redhat.com> Florian Weimer wrote: > * Andrew Haley: > >> Florian Weimer wrote: >>> * Florian Weimer: >>> >>>> * Matthias Klose: >>>> >>>>> attached are three patches to build on architectures with a signed size_t >>>>> (s390-linux-gnu). >>>> Yuck. Is this really true? Seems so. >>> No, it's not. >> It's not. > > I was more concerned with the reality on s390, not what's in the > standard. Unfortunately, my first test case was wrong. Is the reality then that GNU C on s/390 is not ISO C compliant? I didn't know that. It must break a ton of code. Andrew. From aph at redhat.com Mon Aug 4 04:43:21 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 04 Aug 2008 12:43:21 +0100 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4896E9CA.60008@redhat.com> References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> <4896E6D2.9030109@redhat.com> <873allf2aa.fsf@mid.deneb.enyo.de> <4896E9CA.60008@redhat.com> Message-ID: <4896EB59.5010802@redhat.com> Andrew Haley wrote: > Florian Weimer wrote: >> * Andrew Haley: >> >>> Florian Weimer wrote: >>>> * Florian Weimer: >>>> >>>>> * Matthias Klose: >>>>> >>>>>> attached are three patches to build on architectures with a signed size_t >>>>>> (s390-linux-gnu). >>>>> Yuck. Is this really true? Seems so. >>>> No, it's not. >>> It's not. >> I was more concerned with the reality on s390, not what's in the >> standard. Unfortunately, my first test case was wrong. > > Is the reality then that GNU C on s/390 is not ISO C compliant? > I didn't know that. It must break a ton of code. I don't believe it. Here's s390/linux.h: #undef SIZE_TYPE #define SIZE_TYPE (TARGET_64BIT ? "long unsigned int" : "long unsigned int") #undef PTRDIFF_TYPE #define PTRDIFF_TYPE (TARGET_64BIT ? "long int" : "int") Andrew. From fw at deneb.enyo.de Mon Aug 4 07:55:41 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 04 Aug 2008 16:55:41 +0200 Subject: [patch] fix build on architectures with a signed size_t In-Reply-To: <4896E9CA.60008@redhat.com> (Andrew Haley's message of "Mon, 04 Aug 2008 12:36:42 +0100") References: <4895EC16.6030406@ubuntu.com> <87ej55k8tz.fsf@mid.deneb.enyo.de> <877iaxk8jz.fsf@mid.deneb.enyo.de> <4896E6D2.9030109@redhat.com> <873allf2aa.fsf@mid.deneb.enyo.de> <4896E9CA.60008@redhat.com> Message-ID: <8763qgakya.fsf@mid.deneb.enyo.de> * Andrew Haley: >> I was more concerned with the reality on s390, not what's in the >> standard. Unfortunately, my first test case was wrong. > > Is the reality then that GNU C on s/390 is not ISO C compliant? > I didn't know that. It must break a ton of code. Let me repeat: My initial test case was wrong. It reported size_t as signed, when it wasn't. Sorry about that. At least on raptor.debian.org, in the sid chroot, size_t is unsigned. From mateusz.kaduk at gmail.com Sat Aug 16 03:10:14 2008 From: mateusz.kaduk at gmail.com (Mateusz Kaduk) Date: Sat, 16 Aug 2008 12:10:14 +0200 Subject: OpenJDK Mozilla plugin bug report Message-ID: Hi, I am using OpenJava 1.6 on Debian sid, because it is the only 64bit Java with mozilla plugin. However some pages do not work. Applet is loading and stops, please refer to http://czateria.interia.pl/ For help thanks in advance, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080816/efcc1421/attachment.html From mark at klomp.org Sat Aug 16 11:08:20 2008 From: mark at klomp.org (Mark Wielaard) Date: Sat, 16 Aug 2008 20:08:20 +0200 Subject: OpenJDK Mozilla plugin bug report In-Reply-To: References: Message-ID: <1218910100.12389.13.camel@hermans.wildebeest.org> Hi Mateusz, On Sat, 2008-08-16 at 12:10 +0200, Mateusz Kaduk wrote: > I am using OpenJava 1.6 on Debian sid, because it is the only 64bit > Java with mozilla plugin. However some pages do not work. > Applet is loading and stops, please refer to > http://czateria.interia.pl/ Could you give some more information? What version of icedtea/openjdk are you using, what version of gcjwebplugin? I quickly looked at that page, but didn't see any applets (but I cannot read Polish). What are you expecting? Have to tried running mozilla with -g to get more debug output? Do you have a direct URL to the applet? Have you tried to run the applet directly with the appletviewer command? Do simple applets like the little water-droplet tap animation at the top-right of http://www.gnu.org/software/classpath/ work for you? You might also want to consult the bug database at http://icedtea.classpath.org/bugzilla/ to see if others have reported something similar or file a more complete report of your issue. Thanks, Mark From mateusz.kaduk at gmail.com Sat Aug 16 12:22:19 2008 From: mateusz.kaduk at gmail.com (Mateusz Kaduk) Date: Sat, 16 Aug 2008 21:22:19 +0200 Subject: OpenJDK Mozilla plugin bug report In-Reply-To: <1218907616.12389.11.camel@hermans.wildebeest.org> References: <1218907616.12389.11.camel@hermans.wildebeest.org> Message-ID: Hi, As it comes to applet open http://czateria.interia.pl/czat,room,70,Warszawa It should pop up a dialog asking for login and password. Password is optional and for registered users only, so you should be able to enter value in first entry, leave second empty and click button. The chat should appear. icedtea-gcjwebplugin 1.0-2 openjdk-6-jre 6b11-5 openjdk-6-jre-lib 6b11-6 openjdk-6-jre-headless 6b11-5 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080816/75278a13/attachment.html From mateusz.kaduk at gmail.com Sun Aug 17 03:09:29 2008 From: mateusz.kaduk at gmail.com (Mateusz Kaduk) Date: Sun, 17 Aug 2008 12:09:29 +0200 Subject: Applet do not work Message-ID: Here is what I get after running this http://czateria.interia.pl/czat,room,70,Warszawa 1. Exception in thread "Chat-GUI-Thread" java.lang.ExceptionInInitializerError 2. at java.lang.Class.forName0(Native Method) 3. at java.lang.Class.forName(Class.java:186) 4. at INTChat.jsFunction(INTChat.java) 5. at INTChat.run(INTChat.java) 6. at java.lang.Thread.run(Thread.java:636) 7. Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission netscape.jsj.dll read) 8. at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342) 9. at java.security.AccessController.checkPermission(AccessController.java:553) 10. at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 11. at net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:267) 12. at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) 13. at java.lang.System.getProperty(System.java:705) 14. at netscape.javascript.JSObject.(JSObject.java) 15. ... 5 more Full log is on http://pastebin.com/f6ab39580 I have ii openjdk-6-jre 6b11-6 OpenJDK Java runtime, using Hotspot JIT ii openjdk-6-jre-headless 6b11-6 OpenJDK Java runtime, using Hotspot JIT (hea ii openjdk-6-jre-lib 6b11-6 OpenJDK Java runtime (architecture independe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080817/2d09d97a/attachment.html From mark at klomp.org Sun Aug 17 07:21:30 2008 From: mark at klomp.org (Mark Wielaard) Date: Sun, 17 Aug 2008 16:21:30 +0200 Subject: Applet do not work In-Reply-To: References: Message-ID: <1218982890.3259.11.camel@dijkstra.wildebeest.org> Hi Mateusz, (CCed distro-pkg-dev where most of the development of the applet plugin is done and Deepak who is currently hacking on the plugin and the liveconnect integration.) On Sun, 2008-08-17 at 12:09 +0200, Mateusz Kaduk wrote: > Here is what I get after running this > http://czateria.interia.pl/czat,room,70,Warszawa > Exception in thread "Chat-GUI-Thread" > java.lang.ExceptionInInitializerError > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:186) > at INTChat.jsFunction(INTChat.java) > at INTChat.run(INTChat.java) > at java.lang.Thread.run(Thread.java:636) > Caused by: java.security.AccessControlException: access denied > (java.util.PropertyPermission netscape.jsj.dll read) > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:342) > at > java.security.AccessController.checkPermission(AccessController.java:553) > at > java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > at > net.sourceforge.jnlp.runtime.JNLPSecurityManager.checkPermission(JNLPSecurityManager.java:267) > at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) > at java.lang.System.getProperty(System.java:705) > at > netscape.javascript.JSObject.(JSObject.java) > ... 5 more > > > Full log is on http://pastebin.com/f6ab39580 Thanks. That is very useful. Although I don't immediately have an answer. I am unsure why or whether an applet should have access this this system property and I couldn't find any documentation on it. It seems to have to do with LiveConnect (the java<->javascript bridge). Could you file a bug report at http://icedtea.classpath.org/bugzilla/ with the full log attached? Then we won't forget about the issue. Hopefully Deepak know a bit more about the issues still needing to be resolved with LiveConnect. Thanks, Mark From martinrb at google.com Sat Aug 23 16:22:03 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 23 Aug 2008 16:22:03 -0700 Subject: Crash in ciTypeFlow.cpp Message-ID: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> Hi hotspot maintainers, For a while now, there's been a crash in hotspot compiled with gcc 4.2 in ciTypeFlow.cpp (crashes in Swingset demo) There have been a number of approaches to fixing it. It appears that Matthias Klose has patched icedtea6 as follows: --- openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp~ 2008-07-10 22:04:30.000000000 +0200 +++ openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp 2008-07-25 14:32:03.544802121 +0200 @@ -130,7 +130,7 @@ // Used as a combined index for locals and temps enum Cell { - Cell_0 + Cell_0, Cell_max = UINT_MAX }; // A StateVector summarizes the type information at some Unfortunately, this fails to compile (at least with gcc 4.0 and OpenJDK7) cc1plus: warnings being treated as errors /usr/local/google/home/martin/ws/hotspot/hotspot/src/share/vm/ci/ciTypeFlow.cpp: In member function 'const ciTypeFlow::StateVector* ciTypeFlow::get_start_state()': /usr/local/google/home/martin/ws/hotspot/hotspot/src/share/vm/ci/ciTypeFlow.cpp:392: warning: comparison between signed and unsigned integer expressions make[6]: *** [ciTypeFlow.o] Error 1 Here's another try, and this time let's try to get it into both OpenJDK7 and OpenJDK6. I'll do the push into OpenJDK7. # HG changeset patch # User martin # Date 1219532277 25200 # Node ID 52c7e88431fc50fd682a0506cd9588c476ca7a00 # Parent f8068895c22d848b6f0e6998886652c3d2f51b24 6666666: Crash in ciTypeFlow with gcc 4.2, enum Cell range too small Reviewed-by: Contributed-by: doko at ubuntu.com diff --git a/src/share/vm/ci/ciTypeFlow.hpp b/src/share/vm/ci/ciTypeFlow.hpp --- a/src/share/vm/ci/ciTypeFlow.hpp +++ b/src/share/vm/ci/ciTypeFlow.hpp @@ -127,7 +127,7 @@ // Used as a combined index for locals and temps enum Cell { - Cell_0 + Cell_0, Cell_max = INT_MAX }; // A StateVector summarizes the type information at some There doesn't seem to be a bug for this in bugtraq. Sun folk, please file a bug, and let me know which team hg forest to push this into. For those of us using newer gccs, this is a P1 bug. As justification, note that the existing code is illegal C++ Enum variables must take on values in the range of the enum constants, which was not the case with the old code. @doko: please review. My version of this change maintains the signedness of enum Cell, avoiding possible changes in behavior and subtleties with signed/unsigned comparison. Let's all try harder to get "community"-developed patches upstream. Thanks, Martin From martinrb at google.com Sat Aug 23 17:44:30 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 23 Aug 2008 17:44:30 -0700 Subject: splashscreen.so is missing pnggccrd.c Message-ID: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> Hi splashscreen/build maintainers, I'm using a non-standard gnu toolchain to build OpenJDK7, and I got errors linking libsplashscreen.so: ../../../build/linux-i586/tmp/sun/sun.awt/splashscreen/obj/png.o: In function `png_init_mmx_flags': png.c:(.text+0xbb): undefined reference to `png_mmx_support' (and many other undefined references) What's up with that? The gcc command includes "-z defs", explicitly asking for an error with unresolved references. Seems like good software engineering. I wonder if the behavior of "-z defs" has changed... Some detective work shows the missing symbols being defined in pnggccrd.c. Why isn't that being found? Ahh, the list of files to be compiled in make/sun/splashscreen/FILES_c.gmk is incomplete. We just need to add in pnggccrd.c.... Not so fast. New compile errors rear their ugly head: ../../../src/share/native/sun/awt/libpng/pnggccrd.c: In function 'png_squelch_warnings': ../../../src/share/native/sun/awt/libpng/pnggccrd.c:390: error: assignment of read-only variable '_const4' The ironically named and long suffering function png_squelch_warnings is trying to assign a read-only variable to itself. That's not a good idea. Newer version of libpng have tried to fix png_squelch_warnings, but have finally squelched png_squelch_warnings itself by annihilating it from the code base. Anyways, please: - review the change below - file a bug - let me know which forest to push this into (awt or build?) BTW, upgrading to the latest libpng probably *is* a good idea. Also, the icedtea folks simply link against the system libs, which is a good idea in the context of distro development, but might not work when trying to produce "portable binaries". Thanks, Martin # HG changeset patch # User martin # Date 1219537969 25200 # Node ID e02349ef40196557bd2561754e51f3c977d1e009 # Parent af4668faae426222f072827ced8522e9c22ea18a 6666666: libsplashscreen.so unresolved link-time references Summary: Compile forgotten source file pnggccrd.c, fix warnings Reviewed-by: diff --git a/make/sun/splashscreen/FILES_c.gmk b/make/sun/splashscreen/FILES_c.gmk --- a/make/sun/splashscreen/FILES_c.gmk +++ b/make/sun/splashscreen/FILES_c.gmk @@ -33,6 +33,7 @@ splashscreen_sys.c \ png.c \ pngerror.c \ + pnggccrd.c \ pngget.c \ pngmem.c \ pngpread.c \ diff --git a/src/share/native/sun/awt/libpng/pnggccrd.c b/src/share/native/sun/awt/libpng/pnggccrd.c --- a/src/share/native/sun/awt/libpng/pnggccrd.c +++ b/src/share/native/sun/awt/libpng/pnggccrd.c @@ -278,9 +278,9 @@ int PNGAPI png_mmx_support(void); #ifdef PNG_USE_LOCAL_ARRAYS -const static int FARDATA png_pass_start[7] = {0, 4, 0, 2, 0, 1, 0}; -const static int FARDATA png_pass_inc[7] = {8, 8, 4, 4, 2, 2, 1}; -const static int FARDATA png_pass_width[7] = {8, 4, 4, 2, 2, 1, 1}; +static const int FARDATA png_pass_start[7] = {0, 4, 0, 2, 0, 1, 0}; +static const int FARDATA png_pass_inc[7] = {8, 8, 4, 4, 2, 2, 1}; +static const int FARDATA png_pass_width[7] = {8, 4, 4, 2, 2, 1, 1}; #endif #if defined(PNG_MMX_CODE_SUPPORTED) @@ -339,30 +339,30 @@ static int _unmask; #endif -const static unsigned long long _mask8_0 = 0x0102040810204080LL; - -const static unsigned long long _mask16_1 = 0x0101020204040808LL; -const static unsigned long long _mask16_0 = 0x1010202040408080LL; - -const static unsigned long long _mask24_2 = 0x0101010202020404LL; -const static unsigned long long _mask24_1 = 0x0408080810101020LL; -const static unsigned long long _mask24_0 = 0x2020404040808080LL; - -const static unsigned long long _mask32_3 = 0x0101010102020202LL; -const static unsigned long long _mask32_2 = 0x0404040408080808LL; -const static unsigned long long _mask32_1 = 0x1010101020202020LL; -const static unsigned long long _mask32_0 = 0x4040404080808080LL; - -const static unsigned long long _mask48_5 = 0x0101010101010202LL; -const static unsigned long long _mask48_4 = 0x0202020204040404LL; -const static unsigned long long _mask48_3 = 0x0404080808080808LL; -const static unsigned long long _mask48_2 = 0x1010101010102020LL; -const static unsigned long long _mask48_1 = 0x2020202040404040LL; -const static unsigned long long _mask48_0 = 0x4040808080808080LL; - -const static unsigned long long _const4 = 0x0000000000FFFFFFLL; -//const static unsigned long long _const5 = 0x000000FFFFFF0000LL; // NOT USED -const static unsigned long long _const6 = 0x00000000000000FFLL; +static const unsigned long long _mask8_0 = 0x0102040810204080LL; + +static const unsigned long long _mask16_1 = 0x0101020204040808LL; +static const unsigned long long _mask16_0 = 0x1010202040408080LL; + +static const unsigned long long _mask24_2 = 0x0101010202020404LL; +static const unsigned long long _mask24_1 = 0x0408080810101020LL; +static const unsigned long long _mask24_0 = 0x2020404040808080LL; + +static const unsigned long long _mask32_3 = 0x0101010102020202LL; +static const unsigned long long _mask32_2 = 0x0404040408080808LL; +static const unsigned long long _mask32_1 = 0x1010101020202020LL; +static const unsigned long long _mask32_0 = 0x4040404080808080LL; + +static const unsigned long long _mask48_5 = 0x0101010101010202LL; +static const unsigned long long _mask48_4 = 0x0202020204040404LL; +static const unsigned long long _mask48_3 = 0x0404080808080808LL; +static const unsigned long long _mask48_2 = 0x1010101010102020LL; +static const unsigned long long _mask48_1 = 0x2020202040404040LL; +static const unsigned long long _mask48_0 = 0x4040808080808080LL; + +static const unsigned long long _const4 = 0x0000000000FFFFFFLL; +//static const unsigned long long _const5 = 0x000000FFFFFF0000LL; // NOT USED +static const unsigned long long _const6 = 0x00000000000000FFLL; // These are used in the row-filter routines and should/would be local // variables if not for gcc addressing limitations. @@ -380,31 +380,6 @@ void /* PRIVATE */ png_squelch_warnings(void) { -#ifdef PNG_THREAD_UNSAFE_OK - _dif = _dif; - _patemp = _patemp; - _pbtemp = _pbtemp; - _pctemp = _pctemp; - _MMXLength = _MMXLength; -#endif - _const4 = _const4; - _const6 = _const6; - _mask8_0 = _mask8_0; - _mask16_1 = _mask16_1; - _mask16_0 = _mask16_0; - _mask24_2 = _mask24_2; - _mask24_1 = _mask24_1; - _mask24_0 = _mask24_0; - _mask32_3 = _mask32_3; - _mask32_2 = _mask32_2; - _mask32_1 = _mask32_1; - _mask32_0 = _mask32_0; - _mask48_5 = _mask48_5; - _mask48_4 = _mask48_4; - _mask48_3 = _mask48_3; - _mask48_2 = _mask48_2; - _mask48_1 = _mask48_1; - _mask48_0 = _mask48_0; } #endif /* PNG_MMX_CODE_SUPPORTED */ From aph at redhat.com Sun Aug 24 03:55:37 2008 From: aph at redhat.com (Andrew Haley) Date: Sun, 24 Aug 2008 11:55:37 +0100 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> Message-ID: <48B13E29.1040205@redhat.com> What's the point of these changes? > -const static unsigned long long _mask8_0 = 0x0102040810204080LL; > - > -const static unsigned long long _mask16_1 = 0x0101020204040808LL; > -const static unsigned long long _mask16_0 = 0x1010202040408080LL; > - > -const static unsigned long long _mask24_2 = 0x0101010202020404LL; > -const static unsigned long long _mask24_1 = 0x0408080810101020LL; > -const static unsigned long long _mask24_0 = 0x2020404040808080LL; > - > -const static unsigned long long _mask32_3 = 0x0101010102020202LL; > -const static unsigned long long _mask32_2 = 0x0404040408080808LL; > -const static unsigned long long _mask32_1 = 0x1010101020202020LL; > -const static unsigned long long _mask32_0 = 0x4040404080808080LL; > - > -const static unsigned long long _mask48_5 = 0x0101010101010202LL; > -const static unsigned long long _mask48_4 = 0x0202020204040404LL; > -const static unsigned long long _mask48_3 = 0x0404080808080808LL; > -const static unsigned long long _mask48_2 = 0x1010101010102020LL; > -const static unsigned long long _mask48_1 = 0x2020202040404040LL; > -const static unsigned long long _mask48_0 = 0x4040808080808080LL; > - > -const static unsigned long long _const4 = 0x0000000000FFFFFFLL; > -//const static unsigned long long _const5 = 0x000000FFFFFF0000LL; > // NOT USED > -const static unsigned long long _const6 = 0x00000000000000FFLL; > +static const unsigned long long _mask8_0 = 0x0102040810204080LL; > + > +static const unsigned long long _mask16_1 = 0x0101020204040808LL; > +static const unsigned long long _mask16_0 = 0x1010202040408080LL; > + > +static const unsigned long long _mask24_2 = 0x0101010202020404LL; > +static const unsigned long long _mask24_1 = 0x0408080810101020LL; > +static const unsigned long long _mask24_0 = 0x2020404040808080LL; > + > +static const unsigned long long _mask32_3 = 0x0101010102020202LL; > +static const unsigned long long _mask32_2 = 0x0404040408080808LL; > +static const unsigned long long _mask32_1 = 0x1010101020202020LL; > +static const unsigned long long _mask32_0 = 0x4040404080808080LL; > + > +static const unsigned long long _mask48_5 = 0x0101010101010202LL; > +static const unsigned long long _mask48_4 = 0x0202020204040404LL; > +static const unsigned long long _mask48_3 = 0x0404080808080808LL; > +static const unsigned long long _mask48_2 = 0x1010101010102020LL; > +static const unsigned long long _mask48_1 = 0x2020202040404040LL; > +static const unsigned long long _mask48_0 = 0x4040808080808080LL; > + > +static const unsigned long long _const4 = 0x0000000000FFFFFFLL; > +//static const unsigned long long _const5 = 0x000000FFFFFF0000LL; > // NOT USED > +static const unsigned long long _const6 = 0x00000000000000FFLL; From martinrb at google.com Sun Aug 24 09:57:17 2008 From: martinrb at google.com (Martin Buchholz) Date: Sun, 24 Aug 2008 09:57:17 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B13E29.1040205@redhat.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B13E29.1040205@redhat.com> Message-ID: <1ccfd1c10808240957l422b3d04g2af0e545a7785ec0@mail.gmail.com> On Sun, Aug 24, 2008 at 3:55 AM, Andrew Haley wrote: > What's the point of these changes? > > >> -const static unsigned long long _mask8_0 = 0x0102040810204080LL; I didn't want to introduce new warnings, and my gcc warned that static should come at the beginning of a declaration. so I did s/const static/static const/g which seems very safe. Martin From martinrb at google.com Mon Aug 25 09:17:07 2008 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Aug 2008 09:17:07 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B28679.20900@sun.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> Message-ID: <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> Hi Anthony, Thanks for the link, but... - The fix for 6613927 is applied in my workspace - The error I'm seeing (and as reported in 6613927) is a link error, not a compile or runtime error - I was seeing the error building in 32-bit mode, as you note. I don't quite understand, but it seems to be due to a change in the way that the GNU toolchain handles unresolved references. In any case, resolving unresolved references can only be good, so is there any reason not to apply my patch? It might even make the fix for 6613927 unnecessary. The 64-bit-ness of that system may have been a red herring. Martin On Mon, Aug 25, 2008 at 3:16 AM, Anthony Petrov wrote: > Hi Martin, > > On 08/24/2008 04:44 AM Martin Buchholz wrote: >> >> ../../../build/linux-i586/tmp/sun/sun.awt/splashscreen/obj/png.o: In >> function `png_init_mmx_flags': >> png.c:(.text+0xbb): undefined reference to `png_mmx_support' > > It looks like another reincarnation of > http://bugs.sun.com/view_bug.do?bug_id=6613927 > It seems strange the problem arises on a 32-bit system though... > > Could you please try using the workaround from this bug to see if it solves > the issue? > > -- > best regards, > Anthony > From Anthony.Petrov at Sun.COM Mon Aug 25 03:16:25 2008 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Mon, 25 Aug 2008 14:16:25 +0400 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> Message-ID: <48B28679.20900@sun.com> Hi Martin, On 08/24/2008 04:44 AM Martin Buchholz wrote: > ../../../build/linux-i586/tmp/sun/sun.awt/splashscreen/obj/png.o: In > function `png_init_mmx_flags': > png.c:(.text+0xbb): undefined reference to `png_mmx_support' It looks like another reincarnation of http://bugs.sun.com/view_bug.do?bug_id=6613927 It seems strange the problem arises on a 32-bit system though... Could you please try using the workaround from this bug to see if it solves the issue? -- best regards, Anthony From Thomas.Rodriguez at Sun.COM Tue Aug 26 13:19:23 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 26 Aug 2008 13:19:23 -0700 Subject: Crash in ciTypeFlow.cpp In-Reply-To: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> References: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> Message-ID: Sorry this took so long. I had intended to pick this up when it was first discussed but with vacation and other things I lost track of it. Since we want everything, even trivial things, to go through our jprt build system, I picked this up and put it into the queue on its way to hotspot-comp/hotspot. It should be completed by the end of the day since it is second in line. The webrev is at http://webrev.invokedynamic.info/never/6741642 . INT_MAX is a good enough value since it should only contain positive integers. Again sorry for the delay in handling this. tom On Aug 23, 2008, at 4:22 PM, Martin Buchholz wrote: > Hi hotspot maintainers, > > For a while now, there's been a crash in hotspot compiled with gcc 4.2 > in ciTypeFlow.cpp (crashes in Swingset demo) > > There have been a number of approaches to fixing it. > It appears that Matthias Klose has patched icedtea6 as follows: > > > > --- openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp~ 2008-07-10 > 22:04:30.000000000 +0200 > +++ openjdk/hotspot/src/share/vm/ci/ciTypeFlow.hpp 2008-07-25 > 14:32:03.544802121 +0200 > @@ -130,7 +130,7 @@ > > // Used as a combined index for locals and temps > enum Cell { > - Cell_0 > + Cell_0, Cell_max = UINT_MAX > }; > > // A StateVector summarizes the type information at some > > > Unfortunately, this fails to compile (at least with gcc 4.0 > and OpenJDK7) > > cc1plus: warnings being treated as errors > /usr/local/google/home/martin/ws/hotspot/hotspot/src/share/vm/ci/ > ciTypeFlow.cpp: > In member function 'const ciTypeFlow::StateVector* > ciTypeFlow::get_start_state()': > /usr/local/google/home/martin/ws/hotspot/hotspot/src/share/vm/ci/ > ciTypeFlow.cpp:392: > warning: comparison between signed and unsigned integer expressions > make[6]: *** [ciTypeFlow.o] Error 1 > > > Here's another try, > and this time let's try to get it into both OpenJDK7 and OpenJDK6. > I'll do the push into OpenJDK7. > > # HG changeset patch > # User martin > # Date 1219532277 25200 > # Node ID 52c7e88431fc50fd682a0506cd9588c476ca7a00 > # Parent f8068895c22d848b6f0e6998886652c3d2f51b24 > 6666666: Crash in ciTypeFlow with gcc 4.2, enum Cell range too small > Reviewed-by: > Contributed-by: doko at ubuntu.com > > diff --git a/src/share/vm/ci/ciTypeFlow.hpp b/src/share/vm/ci/ > ciTypeFlow.hpp > --- a/src/share/vm/ci/ciTypeFlow.hpp > +++ b/src/share/vm/ci/ciTypeFlow.hpp > @@ -127,7 +127,7 @@ > > // Used as a combined index for locals and temps > enum Cell { > - Cell_0 > + Cell_0, Cell_max = INT_MAX > }; > > // A StateVector summarizes the type information at some > > > There doesn't seem to be a bug for this in bugtraq. > Sun folk, please file a bug, > and let me know which team hg forest to push this into. > For those of us using newer gccs, this is a P1 bug. > > As justification, note that the existing code is illegal C++ > Enum variables must take on values in the range of the enum constants, > which was not the case with the old code. > > @doko: please review. My version of this change maintains the > signedness of enum Cell, avoiding possible changes in behavior > and subtleties with signed/unsigned comparison. > > Let's all try harder to get "community"-developed patches upstream. > > Thanks, > > Martin From martinrb at google.com Tue Aug 26 13:48:02 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Aug 2008 13:48:02 -0700 Subject: Crash in ciTypeFlow.cpp In-Reply-To: References: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> Message-ID: <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> Thanks, Tom. Could you include me ("martin") in the Reviewed-by: list? It would be nice if there was a JPRT "service" that non-Sun committers (pushers?) could use. One would think it would be good enough to push into a tributary forest like hotspot-runtime, since JPRT runs are certain to happen (twice, even!) on their way to the MASTER. If that's not good enough, provide a sub-sub-tributary forest. Martin From Joe.Darcy at Sun.COM Tue Aug 26 13:49:42 2008 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 26 Aug 2008 13:49:42 -0700 Subject: Crash in ciTypeFlow.cpp In-Reply-To: <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> References: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> Message-ID: <48B46C66.8020709@sun.com> Martin Buchholz wrote: > Thanks, Tom. > > Could you include me ("martin") in the Reviewed-by: list? > > It would be nice if there was a JPRT "service" that > non-Sun committers (pushers?) could use. > > One would think it would be good enough to push > into a tributary forest like hotspot-runtime, > since JPRT runs are certain to happen (twice, even!) > on their way to the MASTER. > If that's not good enough, provide a sub-sub-tributary forest. > > Martin > This fix will also be in OpenJDK 6 build 12. -Joe From Thomas.Rodriguez at Sun.COM Tue Aug 26 14:33:00 2008 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 26 Aug 2008 14:33:00 -0700 Subject: Crash in ciTypeFlow.cpp In-Reply-To: <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> References: <1ccfd1c10808231622x25ab2b16i52459b96ce74e361@mail.gmail.com> <1ccfd1c10808261348k7ac4df03t67ef20790601d1b5@mail.gmail.com> Message-ID: On Aug 26, 2008, at 1:48 PM, Martin Buchholz wrote: > Thanks, Tom. > > Could you include me ("martin") in the Reviewed-by: list? Sure thing. > > It would be nice if there was a JPRT "service" that > non-Sun committers (pushers?) could use. I know there's been talk about such a thing but I have no idea what's actually happening in that direction. tom From Anthony.Petrov at Sun.COM Wed Aug 27 05:48:04 2008 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Wed, 27 Aug 2008 16:48:04 +0400 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> Message-ID: <48B54D04.1000508@sun.com> Hi Martin, On 08/25/2008 08:17 PM Martin Buchholz wrote: > Thanks for the link, but... > - The fix for 6613927 is applied in my workspace And it gets activated when building on a 64-bit system only. Could you please take a look at the make/sun/splashscreen/Makefile file and make sure it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is really very interesting if this will resolve the issue. Thank you in advance. This is not an ideal solution. Updating to a new libpng version would be fine, however these should be some clean sources (i.e. vanilla libpng source tarball, w/o any static <-> const swaps, etc.), and secondly it requires some Sun-internal bureaucratic process to put these sources to the OpenJDK source tree. Currently I don't see the suggested change is justified since using the standard build environment does not reproduce the problem. However, you might probably be interested in fixing the following CR: http://bugs.sun.com/view_bug.do?bug_id=6565114 This would eliminate this problem at once and forever. Diego 'Flameeyes' Petten? didn't provide us with a working patch (please see the archives of the awt-dev mailing list), hence the CR has been suspended. -- best regards, Anthony From martinrb at google.com Wed Aug 27 15:23:36 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Aug 2008 15:23:36 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B54D04.1000508@sun.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> Message-ID: <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> Anthony, Thanks for your patience; you were entirely right, it was indeed necessary to define PNG_NO_MMX_CODE. Since pnggccrd.c is never compiled, and it contains the MMX code, the only correct thing appears to be to define this macro unconditionally. The obvious patch follows (tested on 32-bit Ubuntu Linux with very recent gcc toolchain) (Has anyone actually tested png splashscreen images on 32 or 64-bit Linux?) # HG changeset patch # User martin # Date 1219875308 25200 # Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c # Parent 1267605489211c6c162bb246f653759e933bd06e 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit) Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux Reviewed-by: anthony diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile --- a/make/sun/splashscreen/Makefile +++ b/make/sun/splashscreen/Makefile @@ -85,13 +85,6 @@ CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3 -ifeq ($(PLATFORM), linux) - ifeq ($(ARCH_DATA_MODEL), 64) - # 64-bit gcc has problems compiling MMX instructions. - # Google it for more details. Possibly the newer versions of - # the PNG-library and/or the new compiler will not need this - # option in the future. - CPPFLAGS += -DPNG_NO_MMX_CODE - endif -endif - +# Shun the less than portable MMX assembly code in pnggccrd.c. +# Newer versions of the PNG-library may not need this option. +CPPFLAGS += -DPNG_NO_MMX_CODE Martin On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov wrote: > Hi Martin, > > On 08/25/2008 08:17 PM Martin Buchholz wrote: >> >> Thanks for the link, but... >> - The fix for 6613927 is applied in my workspace > > And it gets activated when building on a 64-bit system only. Could you > please take a look at the make/sun/splashscreen/Makefile file and make sure > it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is really > very interesting if this will resolve the issue. Thank you in advance. From martinrb at google.com Wed Aug 27 15:34:55 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Aug 2008 15:34:55 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B54D04.1000508@sun.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> Message-ID: <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov wrote: > This is not an ideal solution. Updating to a new libpng version would be > fine, however these should be some clean sources (i.e. vanilla libpng source > tarball, w/o any static <-> const swaps, etc.), and secondly it requires > some Sun-internal bureaucratic process to put these sources to the OpenJDK > source tree. I'm well acquainted with the Sun-internal bureaucratic process. I encourage the libpng upgrade to happen, but it's not high enough priority for me to do the work. > Currently I don't see the suggested change is justified since using the > standard build environment does not reproduce the problem. OpenJDK is a community effort, and no longer just a Sun effort. For us this is a P1 bug, since it is a compilation error in our environment. If we cannot get a fix for this accepted upstream, we would be forced to fork. However, you > might probably be interested in fixing the following CR: > http://bugs.sun.com/view_bug.do?bug_id=6565114 > This would eliminate this problem at once and forever. Diego 'Flameeyes' > Petten? didn't provide us with a working patch (please see the archives of > the awt-dev mailing list), hence the CR has been suspended. Adding options to use the system versions of these graphics libraries is integrated into IcedTea already. IcedTea and Sun AWT engineers should work together to put such changes into OpenJDK7. Martin From mark at klomp.org Thu Aug 28 01:51:11 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 28 Aug 2008 10:51:11 +0200 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> Message-ID: <1219913471.3325.17.camel@hermans.wildebeest.org> Hi, On Wed, 2008-08-27 at 15:34 -0700, Martin Buchholz wrote: > Adding options to use the system versions of these graphics libraries > is integrated into IcedTea already. IcedTea and Sun AWT engineers > should work together to put such changes into OpenJDK7. Yes, this would be great so we don't have to maintain so many extra external patches. The patch to do this in icedtea6 is at: http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-libraries.patch That makes sure the system versions of the png, jpeg and zlib libraries are used. Cheers, Mark From Anthony.Petrov at Sun.COM Thu Aug 28 03:11:19 2008 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Thu, 28 Aug 2008 14:11:19 +0400 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> Message-ID: <48B679C7.8060605@sun.com> Hello Martin, Thank you for the patch. Though there's a little concern: how does the bare libpng deal with this issue when compiled using the toolchain you use? I mean, the problem is not reproducible when compiling on a "regular" 32-bit system, so it might be important to identify the root cause of this issue. Could you please take a look at the libpng source (the version that was forked for the purposes of OpenJDK is 1.2.18) and try compiling it with your tools (by the way, what are they?)? If this is the problem with this particular version of libpng, and newer versions do not experience this problem, then this might be probably a justification for updating our version of libpng rather than disabling the usage of MMX for all platforms. What do you think? -- best regards, Anthony On 08/28/2008 02:23 AM Martin Buchholz wrote: > Anthony, > > Thanks for your patience; you were entirely right, > it was indeed necessary to define PNG_NO_MMX_CODE. > Since pnggccrd.c is never compiled, and it contains the MMX code, > the only correct thing appears to be to define this macro unconditionally. > The obvious patch follows (tested on 32-bit Ubuntu Linux with > very recent gcc toolchain) > > (Has anyone actually tested png splashscreen images on 32 or 64-bit Linux?) > > # HG changeset patch > # User martin > # Date 1219875308 25200 > # Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c > # Parent 1267605489211c6c162bb246f653759e933bd06e > 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit) > Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux > Reviewed-by: anthony > > diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile > --- a/make/sun/splashscreen/Makefile > +++ b/make/sun/splashscreen/Makefile > @@ -85,13 +85,6 @@ > CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen > -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen > CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg > -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3 > > -ifeq ($(PLATFORM), linux) > - ifeq ($(ARCH_DATA_MODEL), 64) > - # 64-bit gcc has problems compiling MMX instructions. > - # Google it for more details. Possibly the newer versions of > - # the PNG-library and/or the new compiler will not need this > - # option in the future. > - CPPFLAGS += -DPNG_NO_MMX_CODE > - endif > -endif > - > +# Shun the less than portable MMX assembly code in pnggccrd.c. > +# Newer versions of the PNG-library may not need this option. > +CPPFLAGS += -DPNG_NO_MMX_CODE > > Martin > > On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov wrote: >> Hi Martin, >> >> On 08/25/2008 08:17 PM Martin Buchholz wrote: >>> Thanks for the link, but... >>> - The fix for 6613927 is applied in my workspace >> And it gets activated when building on a 64-bit system only. Could you >> please take a look at the make/sun/splashscreen/Makefile file and make sure >> it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is really >> very interesting if this will resolve the issue. Thank you in advance. > From Anthony.Petrov at Sun.COM Thu Aug 28 03:23:24 2008 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Thu, 28 Aug 2008 14:23:24 +0400 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1219913471.3325.17.camel@hermans.wildebeest.org> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> <1219913471.3325.17.camel@hermans.wildebeest.org> Message-ID: <48B67C9C.9050502@sun.com> Hi Mark, Thanks for pointing this. Actually, the patch existing in the IcedTea seems to have two potential issues that we at Sun are worried about: 1. The patch cuts off the embedded versions of these libraries from OpenJDK source code. In fact, there may exist systems where these libraries are not installed. And currently OpenJDK runs perfectly on these systems since it have the libraries compiled in. 2. The system libraries may contain issues/errors/bugs/whatever which our code cannot deal with (I think Java2D folks may collaborate on this). Throwing the libraries away from the OpenJDK code may reveal some of the issues, but we obviously can't fix the libraries as fast as our code. And also, we do guarantee some behavior (like understanding file format versions or whatever) that we wouldn't be able to guarantee if we can't ship our copies of the libraries. So, it seems that a better patch would allow choosing whether the user wants to build the OpenJDK using the embedded versions of the libraries (with which the OpenJDK is guaranteed to behave as it should), or the user is brave enough to dynamically link to the system copies and the user is not going to redistribute the OpenJDK to systems that do not have these libraries installed. That actually was the main idea of the patch for http://bugs.sun.com/view_bug.do?bug_id=6565114. Could the IcedTea maintainers do some similar stuff and provide us with the patch? Thanks in advance! -- best regards, Anthony On 08/28/2008 12:51 PM Mark Wielaard wrote: > Hi, > > On Wed, 2008-08-27 at 15:34 -0700, Martin Buchholz wrote: >> Adding options to use the system versions of these graphics libraries >> is integrated into IcedTea already. IcedTea and Sun AWT engineers >> should work together to put such changes into OpenJDK7. > > Yes, this would be great so we don't have to maintain so many extra > external patches. The patch to do this in icedtea6 is at: > http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-libraries.patch > That makes sure the system versions of the png, jpeg and zlib libraries > are used. > > Cheers, > > Mark > > From martinrb at google.com Thu Aug 28 09:33:10 2008 From: martinrb at google.com (Martin Buchholz) Date: Thu, 28 Aug 2008 09:33:10 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B679C7.8060605@sun.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> <48B679C7.8060605@sun.com> Message-ID: <1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com> I'm thinking: - the MMX support is in pnggccrd.c, - but that file is never compiled in OpenJDK - so... how could png ever work when PNG_NO_MMX_CODE is not defined, on any platform? I am suspicious that png splashscreens are actually broken without my proposed patch. Has this actually been tested? I googled a little and have a theory. "-z defs" is supposed to be ignored for shared libs (but why are we using it to build libsplashscreen.so?) but very recent gcc toolchains don't ignore it the way they perhaps should. E.g. Here's a debian bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142 On hppa -Wl,-z,defs is not ignored for shared libraries But using "-z defs" is actually good engineering practice, since it catches problems at link time instead of run time. Whether or not it's a bug in my toolchain, my toolchain detects the unsatisfied symbols in the link. There's a good chance that my change will be necessary to build OpenJDK on future stock Linux systems. Martin On Thu, Aug 28, 2008 at 3:11 AM, Anthony Petrov wrote: > Hello Martin, > > Thank you for the patch. Though there's a little concern: how does the bare > libpng deal with this issue when compiled using the toolchain you use? I > mean, the problem is not reproducible when compiling on a "regular" 32-bit > system, so it might be important to identify the root cause of this issue. > Could you please take a look at the libpng source (the version that was > forked for the purposes of OpenJDK is 1.2.18) and try compiling it with your > tools (by the way, what are they?)? If this is the problem with this > particular version of libpng, and newer versions do not experience this > problem, then this might be probably a justification for updating our > version of libpng rather than disabling the usage of MMX for all platforms. > What do you think? > > -- > best regards, > Anthony > > > On 08/28/2008 02:23 AM Martin Buchholz wrote: >> >> Anthony, >> >> Thanks for your patience; you were entirely right, >> it was indeed necessary to define PNG_NO_MMX_CODE. >> Since pnggccrd.c is never compiled, and it contains the MMX code, >> the only correct thing appears to be to define this macro unconditionally. >> The obvious patch follows (tested on 32-bit Ubuntu Linux with >> very recent gcc toolchain) >> >> (Has anyone actually tested png splashscreen images on 32 or 64-bit >> Linux?) >> >> # HG changeset patch >> # User martin >> # Date 1219875308 25200 >> # Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c >> # Parent 1267605489211c6c162bb246f653759e933bd06e >> 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 >> (64bit) >> Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit >> Linux >> Reviewed-by: anthony >> >> diff --git a/make/sun/splashscreen/Makefile >> b/make/sun/splashscreen/Makefile >> --- a/make/sun/splashscreen/Makefile >> +++ b/make/sun/splashscreen/Makefile >> @@ -85,13 +85,6 @@ >> CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen >> -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen >> CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg >> -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3 >> >> -ifeq ($(PLATFORM), linux) >> - ifeq ($(ARCH_DATA_MODEL), 64) >> - # 64-bit gcc has problems compiling MMX instructions. >> - # Google it for more details. Possibly the newer versions of >> - # the PNG-library and/or the new compiler will not need this >> - # option in the future. >> - CPPFLAGS += -DPNG_NO_MMX_CODE >> - endif >> -endif >> - >> +# Shun the less than portable MMX assembly code in pnggccrd.c. >> +# Newer versions of the PNG-library may not need this option. >> +CPPFLAGS += -DPNG_NO_MMX_CODE >> >> Martin >> >> On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov >> wrote: >>> >>> Hi Martin, >>> >>> On 08/25/2008 08:17 PM Martin Buchholz wrote: >>>> >>>> Thanks for the link, but... >>>> - The fix for 6613927 is applied in my workspace >>> >>> And it gets activated when building on a 64-bit system only. Could you >>> please take a look at the make/sun/splashscreen/Makefile file and make >>> sure >>> it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is >>> really >>> very interesting if this will resolve the issue. Thank you in advance. >> > From martinrb at google.com Thu Aug 28 09:48:22 2008 From: martinrb at google.com (Martin Buchholz) Date: Thu, 28 Aug 2008 09:48:22 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1219913471.3325.17.camel@hermans.wildebeest.org> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> <1219913471.3325.17.camel@hermans.wildebeest.org> Message-ID: <1ccfd1c10808280948v7074a85dve7723bcaf37b308f@mail.gmail.com> In its current form, the icedtea-libraries.patch would probably be rejected by Sun, because it unconditionally changes to using the system libraries. Instead it should be an option. Also, it appears that the changes introduce a run-time dependency on libpng that wasn't there before. This is fine for building packages as part of a Linux distro that manages such dependencies, but is unacceptable in other environments. A quick look at the changes suggests they are insufficiently portable (i.e. a quick hack): e.g. + void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL); Martin On Thu, Aug 28, 2008 at 1:51 AM, Mark Wielaard wrote: > Hi, > > On Wed, 2008-08-27 at 15:34 -0700, Martin Buchholz wrote: >> Adding options to use the system versions of these graphics libraries >> is integrated into IcedTea already. IcedTea and Sun AWT engineers >> should work together to put such changes into OpenJDK7. > > Yes, this would be great so we don't have to maintain so many extra > external patches. The patch to do this in icedtea6 is at: > http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-libraries.patch > That makes sure the system versions of the png, jpeg and zlib libraries > are used. > > Cheers, > > Mark > > From mark at klomp.org Thu Aug 28 10:35:32 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 28 Aug 2008 19:35:32 +0200 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B67C9C.9050502@sun.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> <1219913471.3325.17.camel@hermans.wildebeest.org> <48B67C9C.9050502@sun.com> Message-ID: <1219944932.23036.3.camel@hermans.wildebeest.org> Hi Anthony, On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote: > 1. The patch cuts off the embedded versions of these libraries from > OpenJDK source code. In fact, there may exist systems where these > libraries are not installed. And currently OpenJDK runs perfectly on > these systems since it have the libraries compiled in. Yes it does remove the upstream sources. But I admit to be slightly confused about this practice of embedding upstream source code into your own code repository. If we want to support static linking of libraries wouldn't it be enough to configure and detect the static library .a versions and link against those? > 2. The system libraries may contain issues/errors/bugs/whatever which > our code cannot deal with (I think Java2D folks may collaborate on > this). Throwing the libraries away from the OpenJDK code may reveal some > of the issues, but we obviously can't fix the libraries as fast as our > code. And also, we do guarantee some behavior (like understanding file > format versions or whatever) that we wouldn't be able to guarantee if we > can't ship our copies of the libraries. It would be good to have a list of the guarantees so we can write tests and configure checks to make sure only correct libraries are linked in. Cheers, Mark From mark at klomp.org Thu Aug 28 10:41:59 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 28 Aug 2008 19:41:59 +0200 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808280948v7074a85dve7723bcaf37b308f@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> <1219913471.3325.17.camel@hermans.wildebeest.org> <1ccfd1c10808280948v7074a85dve7723bcaf37b308f@mail.gmail.com> Message-ID: <1219945319.23036.11.camel@hermans.wildebeest.org> On Thu, 2008-08-28 at 09:48 -0700, Martin Buchholz wrote: > In its current form, the icedtea-libraries.patch > would probably be rejected by Sun, because it > unconditionally changes to using the system libraries. > Instead it should be an option. Yeah, it would be interesting to look into that. Although I think the option should be between linking static or shared libraries. Embedding the sources seem a bit fragile and apparently hard to update inside openjdk because of sun legal issues. > A quick look at the changes suggests > they are insufficiently portable (i.e. a quick hack): > e.g. > + void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL); icedtea INSTALL explicitly mentions this version to use. But it would indeed be better if configure does explicitly check for this version of the library. Thanks, Mark From Dalibor.Topic at Sun.COM Thu Aug 28 12:14:27 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Thu, 28 Aug 2008 21:14:27 +0200 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1219945319.23036.11.camel@hermans.wildebeest.org> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> <1219913471.3325.17.camel@hermans.wildebeest.org> <1ccfd1c10808280948v7074a85dve7723bcaf37b308f@mail.gmail.com> <1219945319.23036.11.camel@hermans.wildebeest.org> Message-ID: <48B6F913.4040402@Sun.COM> On 28.08.08 19:41, Mark Wielaard wrote: > Embedding > the sources seem a bit fragile and apparently hard to update inside > openjdk because of sun legal issues. > There is a legal review process associated with dragging in new external code, just like there is a process for that at the FSF - but it is necessarily not as lightweight as [1]. cheers, dalibor topic [1] http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From Phil.Race at Sun.COM Thu Aug 28 12:27:11 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 28 Aug 2008 12:27:11 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B6F913.4040402@Sun.COM> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> <1219913471.3325.17.camel@hermans.wildebeest.org> <1ccfd1c10808280948v7074a85dve7723bcaf37b308f@mail.gmail.com> <1219945319.23036.11.camel@hermans.wildebeest.org> <48B6F913.4040402@Sun.COM> Message-ID: <48B6FC0F.7070809@sun.com> Bringing in an updated version is fairly lightweight. I recently did this for a fontconfig header file. There's a web-based form where you fill in the info, confirming the license hasn't changed, and it gets a short review by a lawyer and that's about it. Filling in the form takes about 20 mins max. Most of the time is waiting for a lawyer to be assigned and approve it. A little under 6 days elapsed time for me from submission to approval. -phil. Dalibor Topic wrote: > On 28.08.08 19:41, Mark Wielaard wrote: >> Embedding >> the sources seem a bit fragile and apparently hard to update inside >> openjdk because of sun legal issues. >> > > There is a legal review process associated with dragging in new external > code, just like > there is a process for that at the FSF - but it is necessarily not as > lightweight as [1]. > > cheers, > dalibor topic > > [1] > http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries > > From martinrb at google.com Thu Aug 28 14:58:21 2008 From: martinrb at google.com (Martin Buchholz) Date: Thu, 28 Aug 2008 14:58:21 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> <48B679C7.8060605@sun.com> <1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com> Message-ID: <1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com> Hi Anthony, I investigated yet a bit more, and finally am sure about the underlying cause: Standard gcc does not define __MMX__, but ours does, perhaps because it has been configured to make MMX support the default. $ gcc -E -dM main.c | grep __MMX__ $ /usr/local/google/fauxJDKCompiler/gcc -E -dM main.c | grep __MMX__ #define __MMX__ 1 By default, pngconf.h uses mmx instructions if __MMX__ is defined. But this can be disabled by -DPNG_NO_MMX_CODE. Since the existing code in OpenJDK depends on MMX not being used (since pnggccrd.c is never compiled) -DPNG_NO_MMX_CODE should be added to CPPFLAGS in the splashscreen makefile unconditionally. Requesting permission to push... You could file a new bug, or we could reuse 6613927, at your option. Martin # HG changeset patch # User martin # Date 1219960566 25200 # Node ID 198b5e82cd0fa4b42cafabce3e763e2a2cb3888c # Parent 1267605489211c6c162bb246f653759e933bd06e 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit) Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux Reviewed-by: anthony diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile --- a/make/sun/splashscreen/Makefile +++ b/make/sun/splashscreen/Makefile @@ -85,13 +85,6 @@ CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3 -ifeq ($(PLATFORM), linux) - ifeq ($(ARCH_DATA_MODEL), 64) - # 64-bit gcc has problems compiling MMX instructions. - # Google it for more details. Possibly the newer versions of - # the PNG-library and/or the new compiler will not need this - # option in the future. - CPPFLAGS += -DPNG_NO_MMX_CODE - endif -endif - +# Shun the less than portable MMX assembly code in pnggccrd.c, +# and use alternative implementations in C. +CPPFLAGS += -DPNG_NO_MMX_CODE On Thu, Aug 28, 2008 at 9:33 AM, Martin Buchholz wrote: > I'm thinking: > - the MMX support is in pnggccrd.c, > - but that file is never compiled in OpenJDK > - so... how could png ever work when PNG_NO_MMX_CODE is not defined, > on any platform? > > I am suspicious that png splashscreens are actually broken > without my proposed patch. Has this actually been tested? > > I googled a little and have a theory. > "-z defs" is supposed to be ignored for shared libs > (but why are we using it to build libsplashscreen.so?) > but very recent gcc toolchains don't ignore it the way they > perhaps should. > > E.g. Here's a debian bug report > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142 > On hppa -Wl,-z,defs is not ignored for shared libraries > > But using "-z defs" is actually good engineering practice, > since it catches problems at link time instead of run time. > Whether or not it's a bug in my toolchain, my toolchain > detects the unsatisfied symbols in the link. > There's a good chance that my change will be necessary > to build OpenJDK on future stock Linux systems. > > Martin > > > On Thu, Aug 28, 2008 at 3:11 AM, Anthony Petrov wrote: >> Hello Martin, >> >> Thank you for the patch. Though there's a little concern: how does the bare >> libpng deal with this issue when compiled using the toolchain you use? I >> mean, the problem is not reproducible when compiling on a "regular" 32-bit >> system, so it might be important to identify the root cause of this issue. >> Could you please take a look at the libpng source (the version that was >> forked for the purposes of OpenJDK is 1.2.18) and try compiling it with your >> tools (by the way, what are they?)? If this is the problem with this >> particular version of libpng, and newer versions do not experience this >> problem, then this might be probably a justification for updating our >> version of libpng rather than disabling the usage of MMX for all platforms. >> What do you think? >> >> -- >> best regards, >> Anthony >> >> >> On 08/28/2008 02:23 AM Martin Buchholz wrote: >>> >>> Anthony, >>> >>> Thanks for your patience; you were entirely right, >>> it was indeed necessary to define PNG_NO_MMX_CODE. >>> Since pnggccrd.c is never compiled, and it contains the MMX code, >>> the only correct thing appears to be to define this macro unconditionally. >>> The obvious patch follows (tested on 32-bit Ubuntu Linux with >>> very recent gcc toolchain) >>> >>> (Has anyone actually tested png splashscreen images on 32 or 64-bit >>> Linux?) >>> >>> # HG changeset patch >>> # User martin >>> # Date 1219875308 25200 >>> # Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c >>> # Parent 1267605489211c6c162bb246f653759e933bd06e >>> 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 >>> (64bit) >>> Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit >>> Linux >>> Reviewed-by: anthony >>> >>> diff --git a/make/sun/splashscreen/Makefile >>> b/make/sun/splashscreen/Makefile >>> --- a/make/sun/splashscreen/Makefile >>> +++ b/make/sun/splashscreen/Makefile >>> @@ -85,13 +85,6 @@ >>> CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen >>> -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen >>> CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg >>> -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3 >>> >>> -ifeq ($(PLATFORM), linux) >>> - ifeq ($(ARCH_DATA_MODEL), 64) >>> - # 64-bit gcc has problems compiling MMX instructions. >>> - # Google it for more details. Possibly the newer versions of >>> - # the PNG-library and/or the new compiler will not need this >>> - # option in the future. >>> - CPPFLAGS += -DPNG_NO_MMX_CODE >>> - endif >>> -endif >>> - >>> +# Shun the less than portable MMX assembly code in pnggccrd.c. >>> +# Newer versions of the PNG-library may not need this option. >>> +CPPFLAGS += -DPNG_NO_MMX_CODE >>> >>> Martin >>> >>> On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov >>> wrote: >>>> >>>> Hi Martin, >>>> >>>> On 08/25/2008 08:17 PM Martin Buchholz wrote: >>>>> >>>>> Thanks for the link, but... >>>>> - The fix for 6613927 is applied in my workspace >>>> >>>> And it gets activated when building on a 64-bit system only. Could you >>>> please take a look at the make/sun/splashscreen/Makefile file and make >>>> sure >>>> it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is >>>> really >>>> very interesting if this will resolve the issue. Thank you in advance. >>> >> > From smuwanga at gmail.com Thu Aug 28 22:50:47 2008 From: smuwanga at gmail.com (Simon Peter Muwanga) Date: Fri, 29 Aug 2008 08:50:47 +0300 Subject: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) Message-ID: Hi guys, Am using Linux 10.3, 64 bit. I get the following error with my wireless toolkit. *java.lang.UnsatisfiedLinkError: /home/smuwanga/WTK2.5.1/bin/sublime.so: /home/smuwanga/WTK2.5.1/bin/sublime.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674) at java.lang.Runtime.load0(Runtime.java:770) at java.lang.System.load(System.java:1005) at com.sun.kvem.Sublime.(Unknown Source) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at com.sun.kvem.Lime.createLime(Unknown Source) at com.sun.kvem.KVMBridge.(Unknown Source) at com.sun.kvem.KVMBridge.getBridge(Unknown Source) at com.sun.kvem.midp.MIDP.run(Unknown Source) at com.sun.kvem.environment.EmulatorInvoker.runEmulatorImpl(Unknown Source) at com.sun.kvem.environment.EmulatorInvoker.main(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.kvem.environment.JVM.main(Unknown Source)* Any help? Simon. On Thu, Aug 28, 2008 at 10:00 PM, wrote: > Send jdk6-dev mailing list submissions to > jdk6-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev > or, via email, send a message with subject or body 'help' to > jdk6-dev-request at openjdk.java.net > > You can reach the person managing the list at > jdk6-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of jdk6-dev digest..." > > > Today's Topics: > > 1. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard) > 2. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Aug 2008 19:35:32 +0200 > From: Mark Wielaard > Subject: Re: splashscreen.so is missing pnggccrd.c > To: Anthony Petrov > Cc: awt-dev at openjdk.java.net, build-dev , > jdk6-dev , > distro-pkg-dev at openjdk.java.net > Message-ID: <1219944932.23036.3.camel at hermans.wildebeest.org> > Content-Type: text/plain > > Hi Anthony, > > On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote: > > 1. The patch cuts off the embedded versions of these libraries from > > OpenJDK source code. In fact, there may exist systems where these > > libraries are not installed. And currently OpenJDK runs perfectly on > > these systems since it have the libraries compiled in. > > Yes it does remove the upstream sources. But I admit to be slightly > confused about this practice of embedding upstream source code into your > own code repository. If we want to support static linking of libraries > wouldn't it be enough to configure and detect the static library .a > versions and link against those? > > > 2. The system libraries may contain issues/errors/bugs/whatever which > > our code cannot deal with (I think Java2D folks may collaborate on > > this). Throwing the libraries away from the OpenJDK code may reveal some > > of the issues, but we obviously can't fix the libraries as fast as our > > code. And also, we do guarantee some behavior (like understanding file > > format versions or whatever) that we wouldn't be able to guarantee if we > > can't ship our copies of the libraries. > > It would be good to have a list of the guarantees so we can write tests > and configure checks to make sure only correct libraries are linked in. > > Cheers, > > Mark > > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Aug 2008 19:41:59 +0200 > From: Mark Wielaard > Subject: Re: splashscreen.so is missing pnggccrd.c > To: Martin Buchholz > Cc: awt-dev at openjdk.java.net, Anthony Petrov , > build-dev , jdk6-dev > , distro-pkg-dev at openjdk.java.net > Message-ID: <1219945319.23036.11.camel at hermans.wildebeest.org> > Content-Type: text/plain > > On Thu, 2008-08-28 at 09:48 -0700, Martin Buchholz wrote: > > In its current form, the icedtea-libraries.patch > > would probably be rejected by Sun, because it > > unconditionally changes to using the system libraries. > > Instead it should be an option. > > Yeah, it would be interesting to look into that. Although I think the > option should be between linking static or shared libraries. Embedding > the sources seem a bit fragile and apparently hard to update inside > openjdk because of sun legal issues. > > > A quick look at the changes suggests > > they are insufficiently portable (i.e. a quick hack): > > e.g. > > + void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL); > > icedtea INSTALL explicitly mentions this version to use. But it would > indeed be better if configure does explicitly check for this version of > the library. > > Thanks, > > Mark > > > > ------------------------------ > > _______________________________________________ > jdk6-dev mailing list > jdk6-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev > > > End of jdk6-dev Digest, Vol 8, Issue 9 > ************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080829/c31604e7/attachment.html From Anthony.Petrov at Sun.COM Fri Aug 29 03:30:14 2008 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Fri, 29 Aug 2008 14:30:14 +0400 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> <48B679C7.8060605@sun.com> <1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com> <1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com> Message-ID: <48B7CFB6.3020006@sun.com> Hi Martin, The AWT folks think we need to guard this CPPFLAGS setting with the following condition: ifneq ($(PLATFORM), windows) ... endif We don't use gcc on Windows, and everything works just fine with MS VS. Please feel free to submit the patch with this change, and please add OpenJDK user 'art' to the reviewers list. Given this modification applied, I'm approving the fix. The push is going to be performed by Artem (CC'ed). Thanks in advance! -- best regards, Anthony On 08/29/2008 01:58 AM Martin Buchholz wrote: > Hi Anthony, > > I investigated yet a bit more, and finally am sure about the underlying cause: > Standard gcc does not define __MMX__, but ours does, > perhaps because it has been configured to make MMX support the default. > > $ gcc -E -dM main.c | grep __MMX__ > $ /usr/local/google/fauxJDKCompiler/gcc -E -dM main.c | grep __MMX__ > #define __MMX__ 1 > > By default, pngconf.h uses mmx instructions if __MMX__ is defined. > But this can be disabled by -DPNG_NO_MMX_CODE. > > Since the existing code in OpenJDK depends on MMX not being used > (since pnggccrd.c is never compiled) -DPNG_NO_MMX_CODE should > be added to CPPFLAGS in the splashscreen makefile unconditionally. > > Requesting permission to push... > > You could file a new bug, or we could reuse 6613927, at your option. > > Martin > > # HG changeset patch > # User martin > # Date 1219960566 25200 > # Node ID 198b5e82cd0fa4b42cafabce3e763e2a2cb3888c > # Parent 1267605489211c6c162bb246f653759e933bd06e > 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit) > Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux > Reviewed-by: anthony > > diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile > --- a/make/sun/splashscreen/Makefile > +++ b/make/sun/splashscreen/Makefile > @@ -85,13 +85,6 @@ > CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen > -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen > CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg > -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3 > > -ifeq ($(PLATFORM), linux) > - ifeq ($(ARCH_DATA_MODEL), 64) > - # 64-bit gcc has problems compiling MMX instructions. > - # Google it for more details. Possibly the newer versions of > - # the PNG-library and/or the new compiler will not need this > - # option in the future. > - CPPFLAGS += -DPNG_NO_MMX_CODE > - endif > -endif > - > +# Shun the less than portable MMX assembly code in pnggccrd.c, > +# and use alternative implementations in C. > +CPPFLAGS += -DPNG_NO_MMX_CODE > > On Thu, Aug 28, 2008 at 9:33 AM, Martin Buchholz wrote: >> I'm thinking: >> - the MMX support is in pnggccrd.c, >> - but that file is never compiled in OpenJDK >> - so... how could png ever work when PNG_NO_MMX_CODE is not defined, >> on any platform? >> >> I am suspicious that png splashscreens are actually broken >> without my proposed patch. Has this actually been tested? >> >> I googled a little and have a theory. >> "-z defs" is supposed to be ignored for shared libs >> (but why are we using it to build libsplashscreen.so?) >> but very recent gcc toolchains don't ignore it the way they >> perhaps should. >> >> E.g. Here's a debian bug report >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142 >> On hppa -Wl,-z,defs is not ignored for shared libraries >> >> But using "-z defs" is actually good engineering practice, >> since it catches problems at link time instead of run time. >> Whether or not it's a bug in my toolchain, my toolchain >> detects the unsatisfied symbols in the link. >> There's a good chance that my change will be necessary >> to build OpenJDK on future stock Linux systems. >> >> Martin >> >> >> On Thu, Aug 28, 2008 at 3:11 AM, Anthony Petrov wrote: >>> Hello Martin, >>> >>> Thank you for the patch. Though there's a little concern: how does the bare >>> libpng deal with this issue when compiled using the toolchain you use? I >>> mean, the problem is not reproducible when compiling on a "regular" 32-bit >>> system, so it might be important to identify the root cause of this issue. >>> Could you please take a look at the libpng source (the version that was >>> forked for the purposes of OpenJDK is 1.2.18) and try compiling it with your >>> tools (by the way, what are they?)? If this is the problem with this >>> particular version of libpng, and newer versions do not experience this >>> problem, then this might be probably a justification for updating our >>> version of libpng rather than disabling the usage of MMX for all platforms. >>> What do you think? >>> >>> -- >>> best regards, >>> Anthony >>> >>> >>> On 08/28/2008 02:23 AM Martin Buchholz wrote: >>>> Anthony, >>>> >>>> Thanks for your patience; you were entirely right, >>>> it was indeed necessary to define PNG_NO_MMX_CODE. >>>> Since pnggccrd.c is never compiled, and it contains the MMX code, >>>> the only correct thing appears to be to define this macro unconditionally. >>>> The obvious patch follows (tested on 32-bit Ubuntu Linux with >>>> very recent gcc toolchain) >>>> >>>> (Has anyone actually tested png splashscreen images on 32 or 64-bit >>>> Linux?) >>>> >>>> # HG changeset patch >>>> # User martin >>>> # Date 1219875308 25200 >>>> # Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c >>>> # Parent 1267605489211c6c162bb246f653759e933bd06e >>>> 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 >>>> (64bit) >>>> Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit >>>> Linux >>>> Reviewed-by: anthony >>>> >>>> diff --git a/make/sun/splashscreen/Makefile >>>> b/make/sun/splashscreen/Makefile >>>> --- a/make/sun/splashscreen/Makefile >>>> +++ b/make/sun/splashscreen/Makefile >>>> @@ -85,13 +85,6 @@ >>>> CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen >>>> -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen >>>> CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg >>>> -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3 >>>> >>>> -ifeq ($(PLATFORM), linux) >>>> - ifeq ($(ARCH_DATA_MODEL), 64) >>>> - # 64-bit gcc has problems compiling MMX instructions. >>>> - # Google it for more details. Possibly the newer versions of >>>> - # the PNG-library and/or the new compiler will not need this >>>> - # option in the future. >>>> - CPPFLAGS += -DPNG_NO_MMX_CODE >>>> - endif >>>> -endif >>>> - >>>> +# Shun the less than portable MMX assembly code in pnggccrd.c. >>>> +# Newer versions of the PNG-library may not need this option. >>>> +CPPFLAGS += -DPNG_NO_MMX_CODE >>>> >>>> Martin >>>> >>>> On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov >>>> wrote: >>>>> Hi Martin, >>>>> >>>>> On 08/25/2008 08:17 PM Martin Buchholz wrote: >>>>>> Thanks for the link, but... >>>>>> - The fix for 6613927 is applied in my workspace >>>>> And it gets activated when building on a 64-bit system only. Could you >>>>> please take a look at the make/sun/splashscreen/Makefile file and make >>>>> sure >>>>> it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is >>>>> really >>>>> very interesting if this will resolve the issue. Thank you in advance. > From Anthony.Petrov at Sun.COM Fri Aug 29 03:37:50 2008 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Fri, 29 Aug 2008 14:37:50 +0400 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> <48B679C7.8060605@sun.com> <1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com> Message-ID: <48B7D17E.1090103@sun.com> On 08/28/2008 08:33 PM Martin Buchholz wrote: > I'm thinking: > - the MMX support is in pnggccrd.c, > - but that file is never compiled in OpenJDK Why? There's the following line in the make/sun/splashscreen/Makefile: vpath %.c $(SHARE_SRC)/native/$(PKGDIR)/libpng that effectively includes all *.c files in the libpng sources directory (src/share/native/sun/awt/libpng/) in the compilation process. Honestly, to me this seems to be a problem with the #ifdef's/#define's logic in libpng, rather than the strong necessity to disable MMX support at all. At least the correct working of this code on MS Windows and 32-bit Linux systems (if compiling using the recommended build environment) somewhat proves this point of view. -- best regards, Anthony > - so... how could png ever work when PNG_NO_MMX_CODE is not defined, > on any platform? > > I am suspicious that png splashscreens are actually broken > without my proposed patch. Has this actually been tested? > > I googled a little and have a theory. > "-z defs" is supposed to be ignored for shared libs > (but why are we using it to build libsplashscreen.so?) > but very recent gcc toolchains don't ignore it the way they > perhaps should. > > E.g. Here's a debian bug report > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142 > On hppa -Wl,-z,defs is not ignored for shared libraries > > But using "-z defs" is actually good engineering practice, > since it catches problems at link time instead of run time. > Whether or not it's a bug in my toolchain, my toolchain > detects the unsatisfied symbols in the link. > There's a good chance that my change will be necessary > to build OpenJDK on future stock Linux systems. From Anthony.Petrov at Sun.COM Fri Aug 29 03:40:03 2008 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Fri, 29 Aug 2008 14:40:03 +0400 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <1219944932.23036.3.camel@hermans.wildebeest.org> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271534u7d322619s2fd3682d70af3793@mail.gmail.com> <1219913471.3325.17.camel@hermans.wildebeest.org> <48B67C9C.9050502@sun.com> <1219944932.23036.3.camel@hermans.wildebeest.org> Message-ID: <48B7D203.6080607@sun.com> Hi Mark, On 08/28/2008 09:35 PM Mark Wielaard wrote: > On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote: >> 1. The patch cuts off the embedded versions of these libraries from >> OpenJDK source code. In fact, there may exist systems where these >> libraries are not installed. And currently OpenJDK runs perfectly on >> these systems since it have the libraries compiled in. > Yes it does remove the upstream sources. But I admit to be slightly > confused about this practice of embedding upstream source code into your > own code repository. If we want to support static linking of libraries > wouldn't it be enough to configure and detect the static library .a > versions and link against those? This seems to be a very neat idea. I personally like it. But what about MS Windows builds? -- best regards, Anthony From Joe.Darcy at Sun.COM Fri Aug 29 08:54:41 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 29 Aug 2008 08:54:41 -0700 Subject: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) In-Reply-To: References: Message-ID: <48B81BC1.2000800@sun.com> Simon Peter Muwanga wrote: > Hi guys, > Am using Linux 10.3, 64 bit. I get the following error with my wireless > toolkit. Looks like your trying to use a 32-bit shared library on a 64 bit system... -Joe > /java.lang.UnsatisfiedLinkError: /home/smuwanga/WTK2.5.1/bin/sublime.so: > /home/smuwanga/WTK2.5.1/bin/sublime.so: wrong ELF class: ELFCLASS32 > (Possible cause: architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674) > at java.lang.Runtime.load0(Runtime.java:770) > at java.lang.System.load(System.java:1005) > at com.sun.kvem.Sublime.(Unknown Source) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at com.sun.kvem.Lime.createLime(Unknown Source) > at com.sun.kvem.KVMBridge.(Unknown Source) > at com.sun.kvem.KVMBridge.getBridge(Unknown Source) > at com.sun.kvem.midp.MIDP.run(Unknown Source) > at com.sun.kvem.environment.EmulatorInvoker.runEmulatorImpl(Unknown > Source) > at com.sun.kvem.environment.EmulatorInvoker.main(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.sun.kvem.environment.JVM.main(Unknown Source)/ > > Any help? > > Simon. > > On Thu, Aug 28, 2008 at 10:00 PM, > wrote: > > Send jdk6-dev mailing list submissions to > jdk6-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev > or, via email, send a message with subject or body 'help' to > jdk6-dev-request at openjdk.java.net > > > You can reach the person managing the list at > jdk6-dev-owner at openjdk.java.net > > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of jdk6-dev digest..." > > > Today's Topics: > > 1. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard) > 2. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Aug 2008 19:35:32 +0200 > From: Mark Wielaard > > Subject: Re: splashscreen.so is missing pnggccrd.c > To: Anthony Petrov > Cc: awt-dev at openjdk.java.net , > build-dev >, > jdk6-dev >, distro-pkg-dev at openjdk.java.net > > Message-ID: <1219944932.23036.3.camel at hermans.wildebeest.org > > > Content-Type: text/plain > > Hi Anthony, > > On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote: > > 1. The patch cuts off the embedded versions of these libraries from > > OpenJDK source code. In fact, there may exist systems where these > > libraries are not installed. And currently OpenJDK runs perfectly on > > these systems since it have the libraries compiled in. > > Yes it does remove the upstream sources. But I admit to be slightly > confused about this practice of embedding upstream source code into your > own code repository. If we want to support static linking of libraries > wouldn't it be enough to configure and detect the static library .a > versions and link against those? > > > 2. The system libraries may contain issues/errors/bugs/whatever which > > our code cannot deal with (I think Java2D folks may collaborate on > > this). Throwing the libraries away from the OpenJDK code may > reveal some > > of the issues, but we obviously can't fix the libraries as fast > as our > > code. And also, we do guarantee some behavior (like understanding > file > > format versions or whatever) that we wouldn't be able to > guarantee if we > > can't ship our copies of the libraries. > > It would be good to have a list of the guarantees so we can write tests > and configure checks to make sure only correct libraries are linked in. > > Cheers, > > Mark > > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Aug 2008 19:41:59 +0200 > From: Mark Wielaard > > Subject: Re: splashscreen.so is missing pnggccrd.c > To: Martin Buchholz > > Cc: awt-dev at openjdk.java.net , > Anthony Petrov >, > build-dev >, jdk6-dev > >, distro-pkg-dev at openjdk.java.net > > Message-ID: <1219945319.23036.11.camel at hermans.wildebeest.org > > > Content-Type: text/plain > > On Thu, 2008-08-28 at 09:48 -0700, Martin Buchholz wrote: > > In its current form, the icedtea-libraries.patch > > would probably be rejected by Sun, because it > > unconditionally changes to using the system libraries. > > Instead it should be an option. > > Yeah, it would be interesting to look into that. Although I think the > option should be between linking static or shared libraries. Embedding > the sources seem a bit fragile and apparently hard to update inside > openjdk because of sun legal issues. > > > A quick look at the changes suggests > > they are insufficiently portable (i.e. a quick hack): > > e.g. > > + void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL); > > icedtea INSTALL explicitly mentions this version to use. But it would > indeed be better if configure does explicitly check for this version of > the library. > > Thanks, > > Mark > > > > ------------------------------ > > _______________________________________________ > jdk6-dev mailing list > jdk6-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev > > > End of jdk6-dev Digest, Vol 8, Issue 9 > ************************************** > > From smuwanga at gmail.com Fri Aug 29 09:54:14 2008 From: smuwanga at gmail.com (Simon Peter Muwanga) Date: Fri, 29 Aug 2008 19:54:14 +0300 Subject: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) In-Reply-To: <48B81BC1.2000800@sun.com> References: <48B81BC1.2000800@sun.com> Message-ID: Oh yeah. I would like to know how the wireless tool kit can be successfully run on a 64-bit linux machine. Some has suggested to me that it would be nice to get the source for the sun wireless took kit(WTK2.5.2) and compile it from my machine. Then later run it. He noticed that the WTK2.5.2 appears to have been designed/compiled from a 32 bit machine. How can I access the source for WTK2.5,2 and compile it? Probably it may work. More solutions are really welcome. Thank you Joseph for your quick response! Simon. On 8/29/08, Joseph D. Darcy wrote: > Simon Peter Muwanga wrote: >> Hi guys, >> Am using Linux 10.3, 64 bit. I get the following error with my wireless >> toolkit. > > Looks like your trying to use a 32-bit shared library on a 64 bit system... > > -Joe > >> /java.lang.UnsatisfiedLinkError: /home/smuwanga/WTK2.5.1/bin/sublime.so: >> /home/smuwanga/WTK2.5.1/bin/sublime.so: wrong ELF class: ELFCLASS32 >> (Possible cause: architecture word width mismatch) >> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >> at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778) >> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674) >> at java.lang.Runtime.load0(Runtime.java:770) >> at java.lang.System.load(System.java:1005) >> at com.sun.kvem.Sublime.(Unknown Source) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >> at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >> at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >> at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >> at java.lang.Class.newInstance0(Class.java:355) >> at java.lang.Class.newInstance(Class.java:308) >> at com.sun.kvem.Lime.createLime(Unknown Source) >> at com.sun.kvem.KVMBridge.(Unknown Source) >> at com.sun.kvem.KVMBridge.getBridge(Unknown Source) >> at com.sun.kvem.midp.MIDP.run(Unknown Source) >> at com.sun.kvem.environment.EmulatorInvoker.runEmulatorImpl(Unknown >> Source) >> at com.sun.kvem.environment.EmulatorInvoker.main(Unknown Source) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at com.sun.kvem.environment.JVM.main(Unknown Source)/ >> >> Any help? >> >> Simon. >> >> On Thu, Aug 28, 2008 at 10:00 PM, > > wrote: >> >> Send jdk6-dev mailing list submissions to >> jdk6-dev at openjdk.java.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev >> or, via email, send a message with subject or body 'help' to >> jdk6-dev-request at openjdk.java.net >> >> >> You can reach the person managing the list at >> jdk6-dev-owner at openjdk.java.net >> >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of jdk6-dev digest..." >> >> >> Today's Topics: >> >> 1. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard) >> 2. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 28 Aug 2008 19:35:32 +0200 >> From: Mark Wielaard > >> Subject: Re: splashscreen.so is missing pnggccrd.c >> To: Anthony Petrov >> Cc: awt-dev at openjdk.java.net , >> build-dev > >, >> jdk6-dev > >, distro-pkg-dev at openjdk.java.net >> >> Message-ID: <1219944932.23036.3.camel at hermans.wildebeest.org >> > >> Content-Type: text/plain >> >> Hi Anthony, >> >> On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote: >> > 1. The patch cuts off the embedded versions of these libraries from >> > OpenJDK source code. In fact, there may exist systems where these >> > libraries are not installed. And currently OpenJDK runs perfectly >> on >> > these systems since it have the libraries compiled in. >> >> Yes it does remove the upstream sources. But I admit to be slightly >> confused about this practice of embedding upstream source code into >> your >> own code repository. If we want to support static linking of libraries >> wouldn't it be enough to configure and detect the static library .a >> versions and link against those? >> >> > 2. The system libraries may contain issues/errors/bugs/whatever >> which >> > our code cannot deal with (I think Java2D folks may collaborate on >> > this). Throwing the libraries away from the OpenJDK code may >> reveal some >> > of the issues, but we obviously can't fix the libraries as fast >> as our >> > code. And also, we do guarantee some behavior (like understanding >> file >> > format versions or whatever) that we wouldn't be able to >> guarantee if we >> > can't ship our copies of the libraries. >> >> It would be good to have a list of the guarantees so we can write >> tests >> and configure checks to make sure only correct libraries are linked >> in. >> >> Cheers, >> >> Mark >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 28 Aug 2008 19:41:59 +0200 >> From: Mark Wielaard > >> Subject: Re: splashscreen.so is missing pnggccrd.c >> To: Martin Buchholz > >> Cc: awt-dev at openjdk.java.net , >> Anthony Petrov > >, >> build-dev > >, jdk6-dev >> > >, distro-pkg-dev at openjdk.java.net >> >> Message-ID: <1219945319.23036.11.camel at hermans.wildebeest.org >> > >> Content-Type: text/plain >> >> On Thu, 2008-08-28 at 09:48 -0700, Martin Buchholz wrote: >> > In its current form, the icedtea-libraries.patch >> > would probably be rejected by Sun, because it >> > unconditionally changes to using the system libraries. >> > Instead it should be an option. >> >> Yeah, it would be interesting to look into that. Although I think the >> option should be between linking static or shared libraries. Embedding >> the sources seem a bit fragile and apparently hard to update inside >> openjdk because of sun legal issues. >> >> > A quick look at the changes suggests >> > they are insufficiently portable (i.e. a quick hack): >> > e.g. >> > + void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | >> RTLD_GLOBAL); >> >> icedtea INSTALL explicitly mentions this version to use. But it would >> indeed be better if configure does explicitly check for this version >> of >> the library. >> >> Thanks, >> >> Mark >> >> >> >> ------------------------------ >> >> _______________________________________________ >> jdk6-dev mailing list >> jdk6-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev >> >> >> End of jdk6-dev Digest, Vol 8, Issue 9 >> ************************************** >> >> > > From martinrb at google.com Fri Aug 29 10:36:45 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 29 Aug 2008 10:36:45 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B7CFB6.3020006@sun.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> <48B679C7.8060605@sun.com> <1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com> <1ccfd1c10808281458t4ce2543difcb2f3442826e095@mail.gmail.com> <48B7CFB6.3020006@sun.com> Message-ID: <1ccfd1c10808291036j3f554c0qa41d65b7ea0e4561@mail.gmail.com> Hi Anthony, On Fri, Aug 29, 2008 at 3:30 AM, Anthony Petrov wrote: > Hi Martin, > > The AWT folks think we need to guard this CPPFLAGS setting with the > following condition: > > ifneq ($(PLATFORM), windows) > ... > endif I am certain this would "work" for everyone, but ... I am a perfectionist and I am also quite certain that it is wrong. But if you insist, it's OK. > We don't use gcc on Windows, and everything works just fine with MS VS. "We" are now a community of folks with different platforms in mind. People will want to use gcc on Windows. > Please feel free to submit the patch with this change, and please add > OpenJDK user 'art' to the reviewers list. Given this modification applied, > I'm approving the fix. The push is going to be performed by Artem (CC'ed). > Thanks in advance! Again, sorry to be contrary, but I am an OpenJDK committer, and I would prefer to do hg pushes myself, for "community development" reasons. I propose to push these changes to jdk7/awt-gate/jdk It appears that currently every changeset needs a unique bugid, so a new bug would have to be filed. Anthony, could you take care of this? Thanks, Martin From martinrb at google.com Fri Aug 29 10:46:03 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 29 Aug 2008 10:46:03 -0700 Subject: splashscreen.so is missing pnggccrd.c In-Reply-To: <48B7D17E.1090103@sun.com> References: <1ccfd1c10808231744y3be4c6b9kd40f54d52c2d7102@mail.gmail.com> <48B28679.20900@sun.com> <1ccfd1c10808250917w1fd85e1ft58b73effb7bb8ec3@mail.gmail.com> <48B54D04.1000508@sun.com> <1ccfd1c10808271523v4db6e71bt990ea3d6123923fa@mail.gmail.com> <48B679C7.8060605@sun.com> <1ccfd1c10808280933i3266ff60x909cdad36273c791@mail.gmail.com> <48B7D17E.1090103@sun.com> Message-ID: <1ccfd1c10808291046v193d7045vbd13cde154b7095@mail.gmail.com> On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov wrote: > On 08/28/2008 08:33 PM Martin Buchholz wrote: >> >> I'm thinking: >> - the MMX support is in pnggccrd.c, >> - but that file is never compiled in OpenJDK > > Why? There's the following line in the make/sun/splashscreen/Makefile: > > vpath %.c $(SHARE_SRC)/native/$(PKGDIR)/libpng > > that effectively includes all *.c files in the libpng sources directory > (src/share/native/sun/awt/libpng/) in the compilation process. Anthony, I believe this is a small misunderstanding of how vpath works. vpath changes the _search path_ for files, but does not affect which files are actually compiled. That is defined in make/sun/splashscreen/FILES_c.gmk and pnggccrd.c is notably absent from that file. If you actually try a clean build, on any platform, you will see no references to pnggccrd (or pngvcrd) in the logs (prove me wrong!). Martin From Dalibor.Topic at Sun.COM Fri Aug 29 11:45:53 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 29 Aug 2008 20:45:53 +0200 Subject: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) In-Reply-To: References: <48B81BC1.2000800@sun.com> Message-ID: <48B843E1.4060107@Sun.COM> On 08/29/08 18:54, Simon Peter Muwanga wrote: > Oh yeah. > I would like to know how the wireless tool kit can be successfully run > on a 64-bit linux machine. The system requirements listed on http://java.sun.com/products/sjwtoolkit/download.html are "*System Requirements - Software* * Microsoft Windows XP and Linux-x86 (English version tested with Ubuntu 6.x)" The links here may help to point you to some hacks to work around the issues which may or may not work, depending on your distribution, etc.: http://www.google.co.uk/search?hl=en&client=firefox-a&rls=org.mozilla:en-US:official&hs=BbT&pwst=1&q=+site:forums.sun.com+sun+wireless+toolkit++64+bit+linux cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From smuwanga at gmail.com Fri Aug 29 21:18:18 2008 From: smuwanga at gmail.com (Simon Peter Muwanga) Date: Sat, 30 Aug 2008 07:18:18 +0300 Subject: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) In-Reply-To: References: Message-ID: Hi the WTK2.5.2 is now working well. I fixed. You can find the work around at http://forums.sun.com/thread.jspa?messageID=10403593 . Regards, Simon. On Fri, Aug 29, 2008 at 8:50 AM, Simon Peter Muwanga wrote: > Hi guys, > Am using Linux 10.3, 64 bit. I get the following error with my wireless > toolkit. > > *java.lang.UnsatisfiedLinkError: /home/smuwanga/WTK2.5.1/bin/sublime.so: > /home/smuwanga/WTK2.5.1/bin/sublime.so: wrong ELF class: ELFCLASS32 > (Possible cause: architecture word width mismatch) > at java.lang.ClassLoader$NativeLibrary.load(Native Method) > at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778) > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1674) > at java.lang.Runtime.load0(Runtime.java:770) > at java.lang.System.load(System.java:1005) > at com.sun.kvem.Sublime.(Unknown Source) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at com.sun.kvem.Lime.createLime(Unknown Source) > at com.sun.kvem.KVMBridge.(Unknown Source) > at com.sun.kvem.KVMBridge.getBridge(Unknown Source) > at com.sun.kvem.midp.MIDP.run(Unknown Source) > at com.sun.kvem.environment.EmulatorInvoker.runEmulatorImpl(Unknown > Source) > at com.sun.kvem.environment.EmulatorInvoker.main(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.sun.kvem.environment.JVM.main(Unknown Source)* > > Any help? > > Simon. > > On Thu, Aug 28, 2008 at 10:00 PM, wrote: > >> Send jdk6-dev mailing list submissions to >> jdk6-dev at openjdk.java.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev >> or, via email, send a message with subject or body 'help' to >> jdk6-dev-request at openjdk.java.net >> >> You can reach the person managing the list at >> jdk6-dev-owner at openjdk.java.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of jdk6-dev digest..." >> >> >> Today's Topics: >> >> 1. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard) >> 2. Re: splashscreen.so is missing pnggccrd.c (Mark Wielaard) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 28 Aug 2008 19:35:32 +0200 >> From: Mark Wielaard >> Subject: Re: splashscreen.so is missing pnggccrd.c >> To: Anthony Petrov >> Cc: awt-dev at openjdk.java.net, build-dev , >> jdk6-dev , >> distro-pkg-dev at openjdk.java.net >> Message-ID: <1219944932.23036.3.camel at hermans.wildebeest.org> >> Content-Type: text/plain >> >> Hi Anthony, >> >> On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote: >> > 1. The patch cuts off the embedded versions of these libraries from >> > OpenJDK source code. In fact, there may exist systems where these >> > libraries are not installed. And currently OpenJDK runs perfectly on >> > these systems since it have the libraries compiled in. >> >> Yes it does remove the upstream sources. But I admit to be slightly >> confused about this practice of embedding upstream source code into your >> own code repository. If we want to support static linking of libraries >> wouldn't it be enough to configure and detect the static library .a >> versions and link against those? >> >> > 2. The system libraries may contain issues/errors/bugs/whatever which >> > our code cannot deal with (I think Java2D folks may collaborate on >> > this). Throwing the libraries away from the OpenJDK code may reveal some >> > of the issues, but we obviously can't fix the libraries as fast as our >> > code. And also, we do guarantee some behavior (like understanding file >> > format versions or whatever) that we wouldn't be able to guarantee if we >> > can't ship our copies of the libraries. >> >> It would be good to have a list of the guarantees so we can write tests >> and configure checks to make sure only correct libraries are linked in. >> >> Cheers, >> >> Mark >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 28 Aug 2008 19:41:59 +0200 >> From: Mark Wielaard >> Subject: Re: splashscreen.so is missing pnggccrd.c >> To: Martin Buchholz >> Cc: awt-dev at openjdk.java.net, Anthony Petrov , >> build-dev , jdk6-dev >> , distro-pkg-dev at openjdk.java.net >> Message-ID: <1219945319.23036.11.camel at hermans.wildebeest.org> >> Content-Type: text/plain >> >> On Thu, 2008-08-28 at 09:48 -0700, Martin Buchholz wrote: >> > In its current form, the icedtea-libraries.patch >> > would probably be rejected by Sun, because it >> > unconditionally changes to using the system libraries. >> > Instead it should be an option. >> >> Yeah, it would be interesting to look into that. Although I think the >> option should be between linking static or shared libraries. Embedding >> the sources seem a bit fragile and apparently hard to update inside >> openjdk because of sun legal issues. >> >> > A quick look at the changes suggests >> > they are insufficiently portable (i.e. a quick hack): >> > e.g. >> > + void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL); >> >> icedtea INSTALL explicitly mentions this version to use. But it would >> indeed be better if configure does explicitly check for this version of >> the library. >> >> Thanks, >> >> Mark >> >> >> >> ------------------------------ >> >> _______________________________________________ >> jdk6-dev mailing list >> jdk6-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev >> >> >> End of jdk6-dev Digest, Vol 8, Issue 9 >> ************************************** >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080830/1e90efc8/attachment.html