libstdc++ devel package is installed but libstdc.so is not found. How can I solve this problem?
> Message du 01/07/11 14:34 > De : "David Holmes" > A : goues...@orange.fr > Copie à : "Anthony Petrov" , awt-dev@openjdk.java.net > Objet : Re: KDE Task bar is always on top of fullscreen Java applications > > goues...@orange.fr said the following on 07/01/11 08:27: > > I get this at the end of the compilation: > > "/usr/bin/ld: cannot open output file libjvm.so: Too many levels of > > symbolic links" > > > > I tried to recompile after cleaning all. What can I do to work around this > > problem? > > Are you building hotspot? This is a quirk in the hotspot makefiles. If > the link fails to create the libjvm you get a symbolic link that refers > to itself. Subsequent build attempts don't try to rebuild libjvm as it > seems to exist but when ld tries to access it you get the "too many > levels of symbolic links" error. > > A full clean should fix it, but then you need to see what the original > error was caused by. > > David Holmes > ------------- > > >> Message du 29/06/11 21:29 > >> De : "Anthony Petrov" > >> A : goues...@orange.fr > >> Copie à : awt-dev@openjdk.java.net > >> Objet : Re: KDE Task bar is always on top of fullscreen Java applications > >> > >> On 6/29/2011 5:59 PM, goues...@orange.fr wrote: > >>> How can I detect whether a window is mapped? When XQueryTree returns > >>> zero, does it mean that the window is unmapped? > >> You could use XGetWindowAttributes() and examine the map_state field of > >> the XWindowAttributes() structure. > >> > >> Alternatively, you could pass an additional argument to the > >> X11GD_SetFullscreenMode() because at AWT level we always know whether a > >> window is mapped (see XBaseWindow.isMapped()). > >> > >> > >> PS. Your email client seems to replace the correct mailing list address > >> "awt-dev@openjdk.java.net" with something strange: > >> "awt-...@rea.oracle.com" when pressing Reply All. Could you please > >> configure it properly? > >> > >> -- > >> best regards, > >> Anthony > >> > >> > >> > >>> I can create another patch, I will do this as soon as possible. I will > >>> ask to the KDE team that it is up to them not to promote only windows on > >>> top of the stack. > >>> > >>>> Message du 29/06/11 15:17 > >>>> De : "Anthony Petrov" > >>>> A : goues...@orange.fr > >>>> Copie à : awt-...@rea.oracle.com > >>>> Objet : Re: KDE Task bar is always on top of fullscreen Java applications > >>>> > >>>> Hi Julien, > >>>> > >>>> So in your sample application you first set the window to the full > >>>> screen mode, and only then you setVisible(true) it. In this case the > >>>> EWMH spec states the following: > >>>> > >>>> *********************************************************** > >>>> The Window Manager SHOULD honor _NET_WM_STATE whenever a withdrawn > >>>> window requests to be mapped. > >>>> *********************************************************** > >>>> > >>>> In other words, the X11GD_SetFullscreenMode() should actually check > >>>> whether the window is currently mapped, and if so, do exactly what it > >>>> currently does. However, if the window is currently unmapped, then we > >>>> indeed have to use the XChangeProperty() call instead of the > >>>> XSendEvent() one. > >>>> > >>>> Please note that in either case we should not set the > >>>> _NET_WM_STATE_ABOVE state. The _NET_WM_STATE_FULLSCREEN alone should > >>>> work just fine. If it doesn't, then this is a problem with KDE. > >>>> > >>>> Could you please try to create such a patch and test it on KDE4? > >>>> > >>>> -- > >>>> best regards, > >>>> Anthony > >>>> > >>>> On 6/29/2011 3:49 PM, goues...@orange.fr wrote: > >>>>> One guy of the KDE team answered that we have misunderstood the EWMH > >>>>> specification, that some window managers derivate from it and that > >>>>> using XChangeProperty there has some sense. What should I do now? > >>>>> > >>>>> > >>>>>> Message du 28/06/11 22:13 > >>>>>> De : "Anthony Petrov" > >>>>>> A : "Phil Race" > >>>>> , goues...@orange.fr > >>>>>> Copie à : awt-dev@openjdk.java.net > >>>>>> Objet : Re: KDE Task bar is always on top of fullscreen Java > >>>>>> applications > >>>>>> > >>>>>> Phil: Ah, right! Haven't used to the new rules yet. Thanks for > >>>>>> reminding > >>>>>> us about that. > >>>>>> > >>>>>> Julien: I have a few questions about your patch: > >>>>>> > >>>>>> 1. The xprop output that you've attached to the KDE bug report [1] > >>>>>> indicates that the full screen window is maximized (i.e. using the > >>>>>> emulated full screen mode rather than the exclusive one). In this > >>>>>> case, > >>>>>> the behavior is correct. But I assume you did try to do the same with > >>>>>> the exclusive FS mode enabled, didn't you? Could you please provide an > >>>>>> xprop output in that case, too? > >>>>>> > >>>>>> 2. The EWMH specification [2] states that "A Client wishing to change > >>>>>> the state of a window MUST send a _NET_WM_STATE client message to the > >>>>>> root window". However, your proposed patch calls XChangeProperty() > >>>>>> which > >>>>>> changes the property manually, and therefore violates the EWMH spec. I > >>>>>> think that a subsequent XSendEvent() to the root window should be > >>>>>> enough > >>>>>> for our purposes. > >>>>>> > >>>>>> 3. The comments at the KDE bug report, as well as the EWMH spec (see > >>>>>> the > >>>>>> "Stacking order" section) suggest that a window with the > >>>>>> _NET_WM_STATE_FULLSCREEN state should already be above any other > >>>>>> windows > >>>>>> (including the _NET_WM_STATE_ABOVE windows). Also, the specification > >>>>>> states that the latter state should not be used by applications > >>>>>> directly. Note that the function X11GD_SetFullscreenMode() which > >>>>>> you're > >>>>>> changing with your patch already sets the _NET_WM_STATE_FULLSCREEN > >>>>>> state > >>>>>> to the full screen window, and, according to the EWMH specification, > >>>>>> that alone should work fine for full screen windows. So doesn't this > >>>>>> then seem to be a bug in KDE4 actually? > >>>>>> > >>>>>> [1] https://bugs.kde.org/show_bug.cgi?id=276159 > >>>>>> > >>>>>> [2] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html > >>>>>> > >>>>>> -- > >>>>>> best regards, > >>>>>> Anthony > >>>>>> > >>>>>> On 6/28/2011 8:26 PM, Phil Race wrote: > >>>>>>> Anthony, > >>>>>>> > >>>>>>> That looks like a "small patch" so by the recent relaxation of the > >>>>>>> rules an OCA isn't needed. > >>>>>>> > >>>>>>> -phil. > >>>>>>> > >>>>>>> On 6/28/2011 5:02 AM, Anthony Petrov wrote: > >>>>>>>> Hi Julien, > >>>>>>>> > >>>>>>>> For your contribution to be acceptable, you have to sign an OCA. > >>>>>>>> Please refer to this page for details on how to become an OpenJDK > >>>>>>>> contributor: > >>>>>>>> > >>>>>>>> http://openjdk.java.net/contribute/ > >>>>>>>> > >>>>>>>> -- > >>>>>>>> best regards, > >>>>>>>> Anthony > >>>>>>>> > >>>>>>>> On 6/27/2011 4:03 PM, goues...@orange.fr wrote: > >>>>>>>>> Hi! > >>>>>>>>> > >>>>>>>>> I think I have found a fix for this bug. On GNOME and on KDE the > >>>>>>>>> atoms remain unchanged according to xprops but the X client message > >>>>>>>>> is sent, that is why I call XChangeProperty. On the other hand, > >>>>>>>>> only > >>>>>>>>> a window on top of the stack can become fullscreen, that is why I > >>>>>>>>> use > >>>>>>>>> _NET_WM_STATE_ABOVE. I fear that building OpenJDK requires a lot of > >>>>>>>>> time. Could someone with a ready environment make a build for me > >>>>>>>>> with > >>>>>>>>> this fix? My "patch" is in the bug report here: > >>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057287 > >>>>>>>>> > >>>>>>>>> Best regards > >>>>>>>>> > >>>>>>>>> Julien Gouesse > >>>>>>>>> > >>>>>>>>>> Message du 23/06/11 14:50 > >>>>>>>>>> De : "Anthony Petrov" A : goues...@orange.fr > >>>>>>>>>> Copie à : Objet : Re: KDE Task bar is always on top of fullscreen > >>>>>>>>>> Java applications > >>>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> On 06/22/2011 02:28 PM, goues...@orange.fr wrote: > >>>>>>>>>>> Yes, that's it. I'm sad because I'm using JOGL AWT canvas called > >>>>>>>>>>> GLCanvas and this bug impacts my first person shooter. If I knew > >>>>>>>>>>> better the source code of AWT, I would try to write a patch. I > >>>>>>>>>>> assume > >>>>>>>>>>> there is a way of detecting the window manager to apply this fix > >>>>>>>>>>> only > >>>>>>>>>>> in this case, isn't it? > >>>>>>>>>> This window state is a part of EWMH specification, so there's no > >>>>>>>>>> need to set it for specific WMs only. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Does AWT currently rely on xrandr or VidMode on Linux? Best > >>>>>>>>>>> regards. > >>>>>>>>>> I think this question belongs to the 2d-dev@openjdk mailing list. > >>>>>>>>>> I'm not a Java2D expert. Please ask 2D folks about that. > >>>>>>>>>> > >>>>>>>>>> PS. Please remember to use Reply All rather than just Reply so > >>>>>>>>>> that > >>>>>>>>>> your message hits the mailing list. > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> best regards, > >>>>>>>>>> Anthony > >>>>>>>>>> > >>>>>>>>>>>> Message du 22/06/11 12:11 > >>>>>>>>>>>> De : "Anthony Petrov" A : goues...@orange.fr > >>>>>>>>>>>> Copie à : awt-dev@openjdk.java.net > >>>>>>>>>>>> Objet : Re: KDE Task bar is always on top of fullscreen Java > >>>>>>>>>>>> applications > >>>>>>>>>>>> > >>>>>>>>>>>> Hello, > >>>>>>>>>>>> > >>>>>>>>>>>> On 6/22/2011 1:14 PM, goues...@orange.fr wrote: > >>>>>>>>>>>>> The exclusive fullscreen mode is broken in KDE for Java > >>>>>>>>>>>>> applications as I explained here: > >>>>>>>>>>>>> https://bugs.kde.org/show_bug.cgi?id=276159 > >>>>>>>>>>>>> > >>>>>>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057287 > >>>>>>>>>>>>> (not yet visible) > >>>>>>>>>>>>> > >>>>>>>>>>>>> After some investigations, the problem comes from Java which > >>>>>>>>>>>>> does > >>>>>>>>>>>>> not > >>>>>>>>>>>>> tag the window as fullscreen. Do you know how to fix this bug? > >>>>>>>>>>>> To tag full screen windows with the _NET_WM_STATE_FULLSCREEN > >>>>>>>>>>>> state? That's easy. :) > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks for filing the bug report. AWT team will take care of > >>>>>>>>>>>> this > >>>>>>>>>>>> issue. > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> best regards, > >>>>>>>>>>>> Anthony > >>>>>>>>>>>> >
