Latest cvs doesn't compile

2003-08-16
2003-11-05
  • Compiled with no special configuration, it fails to link XDarwinApp, due to

    ld: Undefined symbols:
    _AppleWMSendEvent

    This symbol is defined in programs/Xserver/hw/darwin/quartz/applewm.c, but this file is not compiled nor linked in unless HasXplugin is set to YES, and the latter happens when XpLibDir is set which is not the case by default.

    So I got it to compile by putting a line

    #define XpLibDir        /usr/lib/

    into host.def (I have a libXplugin sitting around from Apple's X11-beta3.)

    I see that there is another applewm.c in the new lib/apple/, but this one doesn't define the above-mentioned function which is needed in quartz.c.

    Some questions:

    What is the story behind this new libAppleWM anyway? Is this supposed to be a replacement for libXplugin? And what is the latter doing?

    Does the link error just mean that these things are too new for public consumption? Or is it a bug?

    BTW, patched with that host.def line, it builds OK and seems to work so far.

    --
    Martin

     
    • Opps. :-)

      >What is the story behind this new libAppleWM anyway?

      This is the client side library for the new Apple-WM extension. This is the extension used by the latest (unreleased) versions of quartz-wm to allow it to get the X server and Aqua to interact more seemlessly. So far quartz-wm is the only client to use Apple-WM but I hope that other Mac specific window managers will be extended to use it in the future.

      >Is this supposed to be a replacement for libXplugin? And what is the latter doing?

      No, the idea was the Apple-WM would be supported with either the Xplugin or Cocoa based rootless implementations.

      >Does the link error just mean that these things are too new for public consumption? Or is it a bug?

      It is a bug that snuck in for building the Cocoa implementation (the default). Mostly I only build the Xplugin implementation so Cocoa has not been getting as much attention. I'll fix this up so Cocoa at least builds again. In any case, you found the right workaround: Build the Xplugin implementation instead by defining XpLibDir in your host.def file. BTW, if you build the Xplugin imp you get something that is fairly close in features to Apple's X11. Direct GLX works, Apple-WM almost works, ...

      Note the plan is to soon move both implementations into separate loadable modules, which will both be built (at least if libXplugin is present). The implementation to run can be chosen at run time. Of course for older versions of Mac OS X (10.1 for sure and possibly 10.2) only Cocoa will be available.

       
    • By the way, this bug was fixed awhile ago. Please let me know if the top of XFree86 CVS stops building again.

       
    • Right now (4.3.99.13 from cvs) I have no luck at all in compiling xfree86. There are a lot of include files not found, for example

      ../../../../config/makedepend/makedepend: warning:  aglGlx.c (reading ../../../../programs/Xserver/hw/darwin/quartz/quartzCommon.h,
      line 46): cannot find include file "ApplicationServices/ApplicationServices.h"

      Other such non-existing headers are

      "Carbon/Carbon.h"
      "AGL/agl.h"
      "IOKit/IOKitLib.h"
      "IOKit/hidsystem/IOHIDLib.h"
      "IOKit/hidsystem/ev_keymap.h"
      "IOKit/IOTypes.h"
      "IOKit/hidsystem/IOLLEvent.h"
      "IOKit/hidsystem/IOHIDTypes.h"

      This is on MacOSX 10.2.8.

       
      • There is an issue with the latest CVS that I am working on, but I don't think what you list is it. The message you quote is a warning from makedepend. The problem is that makedepend has never been taught to find header files in frameworks, so it always sprays a bunch of warnings like this. (A useful side project if anyone is interested.) If you search with something like "grep -w Error world.log" you will probably find that there are errors building the GLX libraries, which I am working on. These errors seem to have been introduced in upgrading the version of Mesa in XFree86.

         
        • You are right. Looking for fatal errors, I see one because of

          ld: Undefined symbols:
          _glXMakeContextCurrent

          in the compilation of libGL.1.2.dylib~ and another one:

          aglGlx.c: In function `glAquaSwapBuffers':
          aglGlx.c:1053: structure has no member named `glxc'

          when libOSMesa.a is created. In any case, no X server is created.

           
          • >You are right. Looking for fatal errors, I see one because of
            >
            >ld: Undefined symbols:
            >_glXMakeContextCurrent

            This and all other known build failures with XFree86 should be fixed now. These cropped up due to DRI merge. Let me know if you find further problems.

             
            • It compiles and runs now. I still see the following problems, some of them coming from the fact that I compiled with gcc3.3:
              1. The freetype-config bug is still there.
              2. The #pragma GCC set_debug... bug:
              Apple's buggy cpp3 writes this line at the top of all the scripts created using cpp. In particular the startx equivalent (forgot the name) in XDarwin.app has this. The effect is that when the user's default shell is tcsh, this script is run in tcsh and crashes: Starting XDarwin by double-clicking is impossible.
              The startx script in /usr/X11R6/bin doesn't have this bug, but xmkmf and a couple of others have it.
              This is a better score than Apple has in their latest Panther builds where they trapped themselves: Their X11 has this problem everywhere, every man page has this #pragma stuff at its top, and startx and all other scripts in /usr/X11R6/bin have it.
              The fix is to use gcc -E instead of cpp.
              3. On startup, there is a malloc error message. Here is a log snippet:

              Warning: no access to tty (Inappropriate ioctl for device).
              Thus no job control in this shell.
              Loading GLX bundle glxAGL.bundle (using Apple's OpenGL)
              *** malloc[16263]: error for object 0x1b69a30: Non-page-aligned, non-allocated pointer being freed
              Display mode: Rootless Quartz -- Cocoa implementation
              Screen 0 added: 1024x747 @ (0,21)

              It works in spite of this error message.

               
              • >1. The freetype-config bug is still there.

                Working on this one.

                >2. The #pragma GCC set_debug... bug:
                >The fix is to use gcc -E instead of cpp.

                Have you gotten this to work? The problem is that gcc -E does not like to be piped input as the Imakefiles are setup to do. It chokes with "cc: no input files".

                >3. On startup, there is a malloc error message. Here is a log snippet:

                Yeah, this is on the to fix list.

                 
                • >2. The #pragma GCC set_debug... bug:
                  >The fix is to use gcc -E instead of cpp.

                  I am wrong here. One can take cpp3, for example, instead of cpp.

                  BTW, Apple fell into their own trap: On Panther, all scripts in /usr/X11R6/bin and all X11 man pages from Apple's X11 have this #pragma crap as a first line.

                   
                  • From the CHANGELOG:

                    552. Miscellaneous fixes for Panther:
                           - Fix spurious #pragma getting inserted by cpp (Martin Costabel).

                    Thanks, I put in using cpp3 on Panther.