Re: Link problems with xedit, may be Darwin-only(?)
On Tue, 24 Apr 2007, SciFi wrote: On Tue, 24 Apr 2007 08:08:24 -0600, Marc Aurele La France wrote: On Sun, 22 Apr 2007, SciFi wrote: On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] I'd like to see the _complete_ command line that fails, not just the tail end of it. Anything more on this? Is this related to your GNU make upgrade? oh I just saw this ... having weather & connection problems etc. here... No ... as I mentioned I've seen this kind of problem with other projects albeit rarely. I'd blame the Apple linker on such occasions for losing the symbols, whatever is causing it we have no idea. The symbols _are_ there in the .a files. (IIRC the libdvdread project does this, too, and there are others, all usually fixed by including the .a files...) One possibility here is that it is finding a libmp.dylib in a LD_LIBRARY_PATH path, /lib, /usr/lib, or /usr/local/lib. If so, then the fix would be to #define ExtraLoadOptions to -Wl,-search_paths_first. Holy guacamole this is getting too strange. Please bear with me, I really need to explain some things that are related to your reply. For background: Even though Apple's current docs say they would honour LD_LIBRARY_PATH (probably due to their promise to be more Linux-friendly), in actuality we've never seen it work. Instead we must set DYLD_LIBRARY_PATH for Darwin/OSX systems. Now to the meat of this issue: In my /usr/local/lib are the GNU MP 4.1.2 libraries named -- you guessed it -- libmp.a & libmp.dylib (plus symlinks to the versioned names). AFAICT this is their latest version. I need it for some other projects I think related to the FFT libs which again are needed for some other projects. Talk about a naming clash. I could try putting /usr/X11R6/lib ahead of /usr/local/lib for the DYLD_ env just for starting X11 and tasks it spawns, but we then have a crazy problem if we include /usr/X11R6/lib AT ALL in that path string -- anywhere: late, early, first, middle, last -- it makes no difference. The biggest crazy problem is that this will disable the Macromedia Flash plugin for any & all web-browsers: 2007-04-02 05:36:26.495 firefox-bin[6726] CFLog (21): Error loading /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player: error code 4, error number 0 (Symbol not found: _gluTessCallbackCFM Referenced from: /System/Library/Frameworks/AGL.framework/Versions/A/AGL Expected in: /usr/X11R6/lib/libGLU.dylib ) Another crazy problem is that we see the console printing this message for _any-and-all_ tasks using that DYLD_ setting: dyld: warning DYLD_ setting caused circular dependency in /usr/X11R6/lib/libGL.dylib Some weeks ago I opened problem #5104136 at http://bug-report.apple.com/ to log these interrelated issues with DYLD_LIBRARY_PATH and /usr/X11R6/lib. (By the nature of the 'free' ADC account, the bug-reports aren't made public, searchable, or otherwise sharable. If you want I could c&p the discussion going on there.) What's even more strange is that I cannot find any file whatsoever *anywhere* with the string 'gluTessCallbackCFM' -- even in the calling libs (AGL Frameworks & Flash plugin files)!!! (hmm I am assuming the symbol tables are not encoded with 16-bit ASCII/UTF like with some M$ stuff...) That happens with libGL[U].dylib coming from Apple's X11 on the Tiger install DVD with their updates from a few months ago. It also happens with the _new_ libGL[U].dylib being built from current XFree86-cvs!!! The only way to fix this for real is to remove /usr/X11R6/lib from the DYLD_ path entirely. But I want my test env to be sure to use my newer builds of libs in /usr/local/lib no matter what. (There are settings in each user's ~/.MacOSX/environment.plist that control these paths for the Finder and GUI stuff itself. To get the system itself to find stuff there first, we set+export DYLD_ in the /etc/rc.common script which ought to propagate to all other boot tasks. For the system GUI stuff, we edit root's ~/.MacOSX/environment.plist as well. This way we get the whole ball of wax to use e.g. the latest iconv+intl libs and many many many others.) So my test env isn't going to be able to scan /usr/X11R6/lib at all until/unless Apple fix this bug. But maybe that isn't the real problem with this particular xf86 build problem. Do you think I should add '.' as the very first path to DYLD_ -- I don't think it is implicit? (Right now I actually do have '.' as the very last path here.) Didn't mean to get so long with this post, but you brought up something related I needed to get out into the public for others to see anyway. ;) I'll definitely try your p
Re: Link problems with xedit, may be Darwin-only(?)
On Tue, 24 Apr 2007 08:08:24 -0600, Marc Aurele La France wrote: > On Sun, 22 Apr 2007, SciFi wrote: >>> On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: > > 4. Link problems with xedit, may be Darwin-only(?) > Possibly. > > Build Log snip: > > [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre > -lm -L/usr/X11R6/lib > /usr/bin/ld: Undefined symbols: > [...] > > collect2: ld returned 1 exit status > [...] > > I'd like to see the _complete_ command line that fails, not just the tail end of it. > >>> Anything more on this? Is this related to your GNU make upgrade? > >> oh I just saw this ... having weather & connection problems etc. >> here... > >> No ... as I mentioned I've seen this kind of problem with other >> projects albeit rarely. I'd blame the Apple linker on such occasions >> for losing the symbols, whatever is causing it we have no idea. The >> symbols _are_ there in the .a files. (IIRC the libdvdread project does >> this, too, and there are others, all usually fixed by including the .a >> files...) > > One possibility here is that it is finding a libmp.dylib in a > LD_LIBRARY_PATH path, /lib, /usr/lib, or /usr/local/lib. If so, then > the fix would be to #define ExtraLoadOptions to -Wl,-search_paths_first. > > Marc. Hi, Holy guacamole this is getting too strange. Please bear with me, I really need to explain some things that are related to your reply. For background: Even though Apple's current docs say they would honour LD_LIBRARY_PATH (probably due to their promise to be more Linux-friendly), in actuality we've never seen it work. Instead we must set DYLD_LIBRARY_PATH for Darwin/OSX systems. Now to the meat of this issue: In my /usr/local/lib are the GNU MP 4.1.2 libraries named -- you guessed it -- libmp.a & libmp.dylib (plus symlinks to the versioned names). AFAICT this is their latest version. I need it for some other projects I think related to the FFT libs which again are needed for some other projects. Talk about a naming clash. I could try putting /usr/X11R6/lib ahead of /usr/local/lib for the DYLD_ env just for starting X11 and tasks it spawns, but we then have a crazy problem if we include /usr/X11R6/lib AT ALL in that path string -- anywhere: late, early, first, middle, last -- it makes no difference. The biggest crazy problem is that this will disable the Macromedia Flash plugin for any & all web-browsers: 2007-04-02 05:36:26.495 firefox-bin[6726] CFLog (21): Error loading /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player: error code 4, error number 0 (Symbol not found: _gluTessCallbackCFM Referenced from: /System/Library/Frameworks/AGL.framework/Versions/A/AGL Expected in: /usr/X11R6/lib/libGLU.dylib ) Another crazy problem is that we see the console printing this message for _any-and-all_ tasks using that DYLD_ setting: dyld: warning DYLD_ setting caused circular dependency in /usr/X11R6/lib/libGL.dylib Some weeks ago I opened problem #5104136 at http://bug-report.apple.com/ to log these interrelated issues with DYLD_LIBRARY_PATH and /usr/X11R6/lib. (By the nature of the 'free' ADC account, the bug-reports aren't made public, searchable, or otherwise sharable. If you want I could c&p the discussion going on there.) What's even more strange is that I cannot find any file whatsoever *anywhere* with the string 'gluTessCallbackCFM' -- even in the calling libs (AGL Frameworks & Flash plugin files)!!! (hmm I am assuming the symbol tables are not encoded with 16-bit ASCII/UTF like with some M$ stuff...) That happens with libGL[U].dylib coming from Apple's X11 on the Tiger install DVD with their updates from a few months ago. It also happens with the _new_ libGL[U].dylib being built from current XFree86-cvs!!! The only way to fix this for real is to remove /usr/X11R6/lib from the DYLD_ path entirely. But I want my test env to be sure to use my newer builds of libs in /usr/local/lib no matter what. (There are settings in each user's ~/.MacOSX/environment.plist that control these paths for the Finder and GUI stuff itself. To get the system itself to find stuff there first, we set+export DYLD_ in the /etc/rc.common script which ought to propagate to all other boot tasks. For the system GUI stuff, we edit root's ~/.MacOSX/environment.plist as well. This way we get the whole ball of wax to use e.g. the latest iconv+intl libs and many many many others.) So my test env isn't going to be able to scan /usr/X11R6/lib at all until/unless Apple fix this bug. But maybe that isn't the real problem with this particular xf86 build problem. Do you think I should add '.' as the very first path to DYLD_ -- I don't think it is implicit? (Right now I actually do have '.' as the very last path here.) Didn't mean to get so long with this post, but you brought up something related I needed to get out into the public f
Re: Link problems with xedit, may be Darwin-only(?)
On Sun, 22 Apr 2007, SciFi wrote: On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] I'd like to see the _complete_ command line that fails, not just the tail end of it. Anything more on this? Is this related to your GNU make upgrade? oh I just saw this ... having weather & connection problems etc. here... No ... as I mentioned I've seen this kind of problem with other projects albeit rarely. I'd blame the Apple linker on such occasions for losing the symbols, whatever is causing it we have no idea. The symbols _are_ there in the .a files. (IIRC the libdvdread project does this, too, and there are others, all usually fixed by including the .a files...) One possibility here is that it is finding a libmp.dylib in a LD_LIBRARY_PATH path, /lib, /usr/lib, or /usr/local/lib. If so, then the fix would be to #define ExtraLoadOptions to -Wl,-search_paths_first. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
XFree86 driver for touchscreen
Hi, I need to develop a XFree86 driver for a touchscreen. There is no driver for this touchscreen in XFree86 nor in Linux. All I have is: 1. The hardware touchscreen controller's protocol document 2. The source code of other touch screen drivers ELO and 3M. The only documentation we've been able to find for this sort of thing is the actual XFree86 source code. Can anyone tell me how I could get started with the XFree86 driver development. Or, any suggestions on which website or book to refer to is most welcome. Thanks. pankaj. - Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.