Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » more osx troubles

This thread is locked; no one can reply to it. rss feed Print
more osx troubles
Mike Farrell
Member #248
April 2000
avatar

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
avatar

Would putting a symlink to the library in /usr/X11R6/lib work?

---------------------------------------
By Hook or by Crook.... We WILL!

Mike Farrell
Member #248
April 2000
avatar

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
avatar

MIKE!!!

Don't take yourself too seriously, but do take your responsibilities very seriously.

Thomas Harte
Member #33
April 2000
avatar

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?

Mike Farrell
Member #248
April 2000
avatar

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
avatar

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?
Also, is you Mac a PowerPC Mac or an Intel Mac?

Anyway, next time, please report problems like these before deciding to try the X11 version. ;)

Mike Farrell
Member #248
April 2000
avatar

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
http://www.allegro.cc/files/svn/allegro-4.3-dev-2006-06-21.tar.bz2

I build with "fix.sh macosx && make"

Evert
Member #794
November 2000
avatar

Don't worry about 4.3 for the moment, but do check the SVN version of 4.2 if you can.
Also, please specify the type of Mac you have (Intel or PowerPC). I'm not sure if vanilla 4.2 will compile on an Intel based Mac, but it almost certainly will not work correctly.

Mike Farrell
Member #248
April 2000
avatar

sorry about that, I'm on a powerpc

Thomas Harte
Member #33
April 2000
avatar

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.

Mike Farrell
Member #248
April 2000
avatar

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.

1 
2#include <allegro.h>
3 
4int main()
5{
6 int mouse_down = FALSE, recording = FALSE, x, y;
7
8 allegro_init();
9 set_color_depth(desktop_color_depth());
10 if(set_gfx_mode(GFX_AUTODETECT_WINDOWED, 640, 480, 0, 0) != 0)
11 {
12 allegro_message("Total malfunction in the system!");
13 return 1;
14 }
15 
16 install_timer();
17 install_mouse();
18 install_keyboard();
19
20 show_mouse(screen);
21 while(!key[KEY_ESC])
22 {
23 //clear_bitmap(screen);
24
25 if(mouse_b & 1)
26 {
27 if(!mouse_down)
28 {
29 mouse_down = TRUE;
30 recording = TRUE;
31 x = mouse_x;
32 y = mouse_y;
33 }
34 }
35 else mouse_down = recording = FALSE;
36
37 if(recording)
38 {
39 //drawing_mode(DRAW_MODE_XOR, NULL, 0, 0);
40 //acquire_screen();
41 line(screen, x, y, mouse_x, mouse_y, makecol(0, 255, 0));
42 //release_screen();
43 }
44 }
45 
46 allegro_exit();
47 return 0;
48}
49END_OF_MAIN();

Here's the crash log. After it froze, I sent a force quit to find out where it was stuck.

1$:~/Desktop/mactest me$ gdb testmouse
2GNU gdb 6.3.50-20050815 (Apple version gdb-477) (Sun Apr 30 20:06:22 GMT 2006)
3Copyright 2004 Free Software Foundation, Inc.
4GDB is free software, covered by the GNU General Public License, and you are
5welcome to change it and/or distribute copies of it under certain conditions.
6Type "show copying" to see the conditions.
7There is absolutely no warranty for GDB. Type "show warranty" for details.
8This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries .... done
9 
10(gdb) r
11Starting program: /Users/me/Desktop/mactest/testmouse
12Reading symbols for shared libraries . done
13Reading symbols for shared libraries . done
14Reading symbols for shared libraries . done
15Reading symbols for shared libraries . done
16 
17Program received signal SIGTERM, Terminated.
180x9002c128 in semaphore_wait_signal_trap ()
19(gdb) bt
20#0 0x9002c128 in semaphore_wait_signal_trap ()
21#1 0x90001990 in pthread_mutex_lock ()
22#2 0x300d7d94 in _unix_lock_mutex ()
23#3 0x300d42a8 in osx_update_dirty_lines ()
24#4 0x00002f70 in -[AllegroAppDelegate applicationDidFinishLaunching:] ()
25#5 0x92975ad8 in _nsnote_callback ()
26#6 0x9080b010 in __CFXNotificationPost ()
27#7 0x908030ec in _CFXNotificationPostNotification ()
28#8 0x9295fee0 in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
29#9 0x93722338 in -[NSApplication _postDidFinishNotification] ()
30#10 0x93722224 in -[NSApplication _sendFinishLaunchingNotification] ()
31#11 0x93721d6c in -[NSApplication(NSAppleEventHandling) _handleAEOpen:] ()
32#12 0x93721914 in -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] ()
33#13 0x92976ae4 in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
34#14 0x92976944 in _NSAppleEventManagerGenericHandler ()
35#15 0x91534960 in aeDispatchAppleEvent ()
36#16 0x915347fc in dispatchEventAndSendReply ()
37#17 0x91534654 in aeProcessAppleEvent ()
38#18 0x932200e0 in AEProcessAppleEvent ()
39#19 0x9372005c in _DPSNextEvent ()
40#20 0x9371fb48 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
41#21 0x9371c08c in -[NSApplication run] ()
42#22 0x000034d0 in main ()
43(gdb) q
44The program is running. Exit anyway? (y or n) y
45$

Evert
Member #794
November 2000
avatar

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).
That will also make it hard to debug though. I'm not really familiar with the internals of the MacOS X port (I'm mostly a Linux person); it may be worthwhile to draw Peter Hull's attention to this thread as well.

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
avatar

Both calls did nothing (exited normally)

Evert
Member #794
November 2000
avatar

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

1/* osx_qz_acquire_win:
2 * Bitmap locking for Quartz windowed mode.
3 */
4static void osx_qz_acquire_win(BITMAP *bmp)
5{
6 /* to prevent the drawing threads and the rendering proc
7 from concurrently accessing the dirty lines array */
8 if (lock_nesting == 0) {
9 _unix_lock_mutex(osx_window_mutex);
10 bmp->id |= BMP_ID_LOCKED;
11 }
12 lock_nesting++;
13}
14 
15
16 
17/* osx_qz_release_win:
18 * Bitmap unlocking for Quartz windowed mode.
19 */
20static void osx_qz_release_win(BITMAP *bmp)
21{
22 if (lock_nesting > 0) {
23 lock_nesting--;
24 if (!lock_nesting) {
25 bmp->id &= ~BMP_ID_LOCKED;
26 _unix_unlock_mutex(osx_window_mutex);
27 }
28 }
29}

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
avatar

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);

?

Mike Farrell
Member #248
April 2000
avatar

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 ;D

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

Go to: