more osx troubles http://www.allegro.cc/forums/view/586345 Allegro.cc Forum Thread matthew@allegro.cc (Matthew Leverton) Wed, 26 Jul 2006 02:14:41 +0000

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?

]]> no-reply@allegro.cc (Mike Farrell) Sat, 08 Jul 2006 04:50:00 +0000

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

]]> no-reply@allegro.cc (Number Six) Sat, 08 Jul 2006 07:39:59 +0000

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?

]]> no-reply@allegro.cc (Mike Farrell) Tue, 11 Jul 2006 01:40:40 +0000

MIKE!!!

]]> no-reply@allegro.cc (superstar4410) Tue, 11 Jul 2006 04:44:13 +0000
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?

]]> no-reply@allegro.cc (Thomas Harte) Tue, 11 Jul 2006 23:16:47 +0000

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.

]]> no-reply@allegro.cc (Mike Farrell) Tue, 18 Jul 2006 01:03:59 +0000
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. ;)

]]> no-reply@allegro.cc (Evert) Tue, 18 Jul 2006 03:08:28 +0000

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"

]]> no-reply@allegro.cc (Mike Farrell) Fri, 21 Jul 2006 00:25:24 +0000

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.

]]> no-reply@allegro.cc (Evert) Fri, 21 Jul 2006 00:29:42 +0000

sorry about that, I'm on a powerpc

]]> no-reply@allegro.cc (Mike Farrell) Fri, 21 Jul 2006 00:43:04 +0000
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.

]]> no-reply@allegro.cc (Thomas Harte) Fri, 21 Jul 2006 03:37:14 +0000

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$

]]> no-reply@allegro.cc (Mike Farrell) Fri, 21 Jul 2006 23:56:48 +0000
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()?

]]> no-reply@allegro.cc (Evert) Sat, 22 Jul 2006 01:56:18 +0000

Both calls did nothing (exited normally)

]]> no-reply@allegro.cc (Mike Farrell) Sat, 22 Jul 2006 06:26:44 +0000

Ok, but it didn't prevent the crash then...?

]]> no-reply@allegro.cc (Evert) Sat, 22 Jul 2006 12:01:36 +0000

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

]]> no-reply@allegro.cc (Peter Hull) Sat, 22 Jul 2006 17:54:46 +0000
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);

?

]]> no-reply@allegro.cc (Thomas Harte) Sat, 22 Jul 2006 21:13:40 +0000

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

]]> no-reply@allegro.cc (Mike Farrell) Tue, 25 Jul 2006 05:02:02 +0000

Dear Mike,

Thanks for the offer. I'm looking at the mouse stuff now, and also some 'sticky' joystick problems that Jay reported.

Pete

]]> no-reply@allegro.cc (Peter Hull) Wed, 26 Jul 2006 02:14:41 +0000