Latest cvs doesn't compile

2003-08-16
2003-11-05
  • Martin Costabel

    Martin Costabel - 2003-08-16

    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

     
    • Torrey T. Lyons

      Torrey T. Lyons - 2003-08-16

      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.

       
    • Torrey T. Lyons

      Torrey T. Lyons - 2003-10-01

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

       
    • Martin Costabel

      Martin Costabel - 2003-10-09

      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.

       
      • Torrey T. Lyons

        Torrey T. Lyons - 2003-10-09

        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.

         
        • Martin Costabel

          Martin Costabel - 2003-10-09

          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.

           
          • Torrey T. Lyons

            Torrey T. Lyons - 2003-10-13

            >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.

             
            • Martin Costabel

              Martin Costabel - 2003-10-15

              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.

               
              • Torrey T. Lyons

                Torrey T. Lyons - 2003-10-30

                >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.

                 
                • Martin Costabel

                  Martin Costabel - 2003-11-01

                  >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.

                   
                  • Torrey T. Lyons

                    Torrey T. Lyons - 2003-11-05

                    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.

                     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks