|
more osx troubles |
Mike Farrell
Member #248
April 2000
|
So I've installed allegro for mac osx but I want x11 support. The configure script keeps telling me I don't have the X11 developer libs installed because xcode put them in /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/lib as opposed to their normal home in /usr/X11R6/lib Anyone know how to get this thing find the libraries? |
Number Six
Member #3,912
October 2003
|
Would putting a symlink to the library in /usr/X11R6/lib work? --------------------------------------- |
Mike Farrell
Member #248
April 2000
|
So I symlinked /Developer/SDk-whatever/usr/X11R6 into /usr and that sort of worked. I'm using this darwin ports thing to compile a library now and I'm getting this ridiculous error. Scott-Lozanoffs-Computer-4:~/Desktop/gtk_devel scottlozanoff$ sudo port install gtk2 ---> Staging pango into destroot Error: Target com.apple.destroot returned: shell command "env LANG=C DYLD_LIBRARY_PATH=/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_x11_pango/work/destroot/opt/local/lib /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_x11_pango/work/destroot/opt/local/bin/pango-querymodules /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_x11_pango/work/destroot/opt/local/lib/pango/1.5.0/modules/*.so >/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_x11_pango/work/destroot/opt/local/etc/pango/pango.modules" returned error 133 Command output: dyld: Library not loaded: /usr/X11R6/lib/libX11.6.dylib Referenced from: /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_x11_pango/work/destroot/opt/local/bin/pango-querymodules Reason: no suitable image found. Did find: /usr/X11R6/lib/libX11.6.dylib: can't map Error: The following dependencies failed to build: pango tiff jpeg Anyone seen the likes of this before? |
superstar4410
Member #926
January 2001
|
MIKE!!! Don't take yourself too seriously, but do take your responsibilities very seriously. |
Thomas Harte
Member #33
April 2000
|
Quote: Anyone seen the likes of this before? No, but as I understand it the problem is that libX11.6.dylib can't be found. That isn't surprising, since both the 10.4 SDK that you're using and the 10.3 SDK call the file libX11.6.2.dylib. The 10.2 SDK doesn't seem to have any X11 at all and earlier SDKs are no longer available. So, this looks like a ports issue. Perhaps it wants you to download and install a ports-friendly version of the X11 libraries? DarwinPorts, Fink, etc are all about pretending that the OS is a vanilla UNIX so it wouldn't be surprising if they're not very well integrated with the Apple stuff — especially as they're meant to work with plain Darwin and don't require full-OS X. If you want to try a quick fix, perhaps try another symbolic link but I wouldn't be surprised if there are more problems ahead. Out of curiousity, why do you want an X11 version of Allegro on OS X? [My site] [Tetrominoes] |
Mike Farrell
Member #248
April 2000
|
Because the allegro program keeps freezing when I click down on the mouse. I thought maybe the x11 code would run better. Also sometimes instead of freezing allegro programs will print "bus error" and quit. Ah, I fixed the gtk2 install problem. I removed the symlink of /usr/X11R6 to the one in /developer and now ports is installing its own xfree. |
Evert
Member #794
November 2000
|
Quote: Because the allegro program keeps freezing when I click down on the mouse. Example code? Quote: I thought maybe the x11 code would run better. Unlikely. Quote: Also sometimes instead of freezing allegro programs will print "bus error" and quit.
Do all Allegro programs do this, or just some? Anyway, next time, please report problems like these before deciding to try the X11 version. |
Mike Farrell
Member #248
April 2000
|
Sorry to be brief in the report, I've been working on other projects concurrently with trying to port over the allegro programs (just got my gtk2+gtkglext program running on the mac yesterday). All the allegro examples do this, some even fade out and switch into a full screen "bogus" video mode where the colors are all wrong (yellow and orange) and the keyboard + mouse doesn't respond. At this point, my only way to get out short of unplugging the mac is to hit apple+option+esc. In the windowed programs, I still get no response from the keyboard or mouse until the terminal finally prints "bus error" and the program quits. I'm using the following versions of allegro with the same problem in both: http://www.allegro.cc/files/4.2.0/allegro-4.2.0.tar.gz I build with "fix.sh macosx && make" |
Evert
Member #794
November 2000
|
Don't worry about 4.3 for the moment, but do check the SVN version of 4.2 if you can. |
Mike Farrell
Member #248
April 2000
|
sorry about that, I'm on a powerpc |
Thomas Harte
Member #33
April 2000
|
Quote: All the allegro examples do this That always happens if you start them from the Finder. If you open a terminal and start them from their home directory then they should work. It's a side effect of the course that the Allegro team have charted between pretending that OS X is a vanilla UNIX and dealing with it properly. I don't know exactly what is going on (perhaps the startup code that decides which directory to switch to can't cope if the binary isn't in an application bundle? Just a guess!) but crucially this is not a limitation that affects programs built in XCode or probably in other more verbose ways. Quote: sorry about that, I'm on a powerpc Me too, so if you don't want to share source I could at least give your binary a go on my machine. There were quite a few bugs uncovered in Allegro in the run up to 4.2.0, including some to do with mouse handling, so it may be worth investigating further. [My site] [Tetrominoes] |
Mike Farrell
Member #248
April 2000
|
I was starting them from the terminal. That problem was unique to the 4.3 svn branch though like you predicted. The 4.2 svn works ok in the examples, but my "proven" working allegro programs for work still lock up when I click down on the mouse in some cases. I can't seem to trace where the lockup is happening but I will work more on it today. I'd send you some binaries but they are way too complicated with dynamic dependancies to other libraries and whatnot. I may try to write a simple allegro mouse program that reproduces the problem. Later: I got the test program that'll cause the freeze. It doesn't always occur with this one, but always within the first 10 tries. All I do is run it and drag the mouse around until it locks up. If it doesn't lock up after awhile, I can make it happen by quitting and starting again. It also might help to note that I'm on a dual core cpu.
Here's the crash log. After it froze, I sent a force quit to find out where it was stuck.
|
Evert
Member #794
November 2000
|
Quote: It also might help to note that I'm on a dual core cpu.
The crash log suggests that it's a race condition, which would explain why I've never seen the problem on my laptop (not that I use it much for Allegro-related stuff; it's for work). Out of curiosity, what happens if you call show_mouse(NULL) or set_gfx_mode(GFX_TEXT, ...) before allegro_exit()? |
Mike Farrell
Member #248
April 2000
|
Both calls did nothing (exited normally) |
Evert
Member #794
November 2000
|
Ok, but it didn't prevent the crash then...? |
Peter Hull
Member #1,136
March 2001
|
I've reproduced this on my system, too. It's a tricky one to debug - the event thread gets deadlocked waiting to update the screen, but there's no indication of which part of the code took the lock and then didn't release it. I don't know if this is the cause, but can anyone help with a more robust 'counted lock' scheme; at the moment the code looks like this
which I think is vulnerable to another thread jumping in between lock_nesting being tested, and the mutex being taken. Pete
|
Thomas Harte
Member #33
April 2000
|
Quote: which I think is vulnerable to another thread jumping in between lock_nesting being tested, and the mutex being taken. Then why not just: _unix_lock_mutex(lock_nesting_check_mutex); if (lock_nesting == 0) { _unix_lock_mutex(osx_window_mutex); bmp->id |= BMP_ID_LOCKED; } _unix_unlock_mutex(lock_nesting_check_mutex); ? [My site] [Tetrominoes] |
Mike Farrell
Member #248
April 2000
|
If you need me to test any patches on my end, let me know. I'm more than willing to try to help fix this bug so I can port my apps |
Peter Hull
Member #1,136
March 2001
|
Dear Mike, Thanks for the offer. I'm looking at the mouse stuff now, and also some 'sticky' joystick problems that Jay reported. Pete
|
|