Xojo Conferences
XDCMay2019MiamiUSA

Developing plugins with Xcode (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: Re: Developing plugins with Xcode (James Milne)
Next thread: Dynamic access failures and REALnewInstance failures


macosx and unix paths   -   GOLD
  Developing plugins with Xcode   -   James Milne
   Re: Developing plugins with Xcode   -   Alfred Van Hoek
    Re: Developing plugins with Xcode   -   James Milne
   Re: Developing plugins with Xcode   -   Seth Willits
    RE: Developing plugins with Xcode   -   Stys, Peter
     Re: Developing plugins with Xcode   -   James Milne
    RE: Developing plugins with Xcode   -   Campbell, Jason
     RE: Developing plugins with Xcode   -   James Milne
    RE: Developing plugins with Xcode   -   Campbell, Jason
     Re: Developing plugins with Xcode   -   James Milne
   Debugging plugins with Xcode   -   Seth Willits

Developing plugins with Xcode
Date: 22.11.04 01:41 (Mon, 22 Nov 2004 00:41:25 +0000)
From: James Milne
Hi guys,

Just thought I'd share some of my experiences developing plugins with
Xcode.

I've recently moved most of my plugins across to Xcode. This has been
made more practical with the release of REALbasic 5.5.4, which allows
you to load plugins from Mach-O format without having to include a CFM
stub.

I did this for a couple of reasons:

a) It moves me away from the constant treadmill of upgrading
Codewarrior, saving me money every 12 months

b) It makes it easier to debug my plugins, since I've always had
problems using Codewarrior's debugger on Mac OS X

Now that I've got them moved over, I'm fairly happy. The one thing I
have lost is the ability to compile my Win32 plugin targets from within
the same IDE as my Mac ones. However, there are ways around that (which
I will detail at a later date! :-)

Apple have documentation which is helpful for moving Codewarrior
projects over to Xcode. It is a decent starting point for someone who,
like myself, has previously been developing plugins in Codewarrior.

There will probably be a few stumbling blocks for people who try to
move their plugins across to Xcode. Here are the ones I encountered,
and how I addressed them. Hopefully this might help anyone else who is
looking to move across to Xcode.

1) Precompiled headers

I had some problems with the RB Plugin SDK being used in precompiled
headers in Xcode. For the uninitiated, a precompiled header file is a
file which #include's a number of headers you need for the whole of
your project, and caches them into a form which makes it quicker to
compile the other source files in your app.

The RB Plugin SDK uses C++ namespaces to isolate QT movie types. This
is an old constraint for dealing with Win32. However, Xcode balks at
this at first, as it usually interprets precompiled header files as
referencing C code.

At first, I modified the RB Plugin SDK to remove the use of namespaces.
However, this has transpired to be unnecessary.

To combat this, you can set a preference for you target. Specifically,
if you open the info window for your plugin target in Xcode, then click
on the Build tab and select GNU C/C++ Compiler from the list, you can
modify the Compile Sources As option. Set this to C++, and this should
avoid this problem.

2) Bundling your plugin dylib so that REALbasic can load it

To do this, I wrote a simple RB command-line project which takes the
contents of a folder and builds it into a .rbx file (which is really
just a REALbasic Virtual Volume.)

You can integrate this tool into the Xcode build process by creating a
Shell Script Build Phase.

For a Shell Script Build Phase, you can write a bunch of shell commands
which are executed after the main part of compiling your target has
completed.

In my Shell Script build phase, I copy the dylib file from the Xcode
build directory for my project, and put it into a folder hierarchy
which is laid out as it should be inside the virtual volume. I then get
the shell script to execute my command line RB plugin assembler app.

The assembler app produces the .rbx file. Out of convenience, for my
'Development' build style, I get it to copy the .rbx file straight into
the REALbasic plugins directory.

3) Debugging your plugin

At first glance, there is no obvious way to set up Xcode to debug your
plugin.

To debug your plugin, you first need to add an Executable to your
project. You don't want to add REALbasic itself as the executable.
REALbasic is a CFM application, and as such will not be recognised by
Xcode's debugger as a valid host executable for your plugin.

Instead, you need to add a support application called LaunchCFMApp to
your project as the executable. The path to LaunchCFMApp is:

/System/Library/Frameworks/Carbon.framework/Versions/A/Support/
LaunchCFMApp

As an argument to LaunchCFMApp, you want to pass the path to REALbasic,
which on my machine is:

/Volumes/Development/Applications/REALbasic/REALbasic\ 5.5.4\
X.app/Contents/MacOS/REALbasic\ 5.5.4\ Mac\ OS\ X

With this executable added to your project, the Run Executable and
Debug Executable options in the Debug menu will be enabled. This will
fire up REALbasic, and you will be able to debug your plugin with
breakpoints, etc.

Re: Developing plugins with Xcode
Date: 22.11.04 03:07 (Sun, 21 Nov 2004 21:07:38 -0500)
From: Alfred Van Hoek
on 11/21/04 7:41 PM, James Milne at <email address removed> wrote:

> I did this for a couple of reasons:
>
> a) It moves me away from the constant treadmill of upgrading
> Codewarrior, saving me money every 12 months

That's not necessary if you would set a path to

:MSL:
::SDKs:MacOSX10.3.0.sdk:
{System}:Library:CFMSupport:StubLibraries:
:MacOS Suport:Libraries:Runtime:Libs:
:Plugin SDK

and link to MSL_All_Carbon.Lib and CarbonLibStub. Make sure you tell CW to
interpret DOS and UNIX Paths.

I am using CW7.

This will let you use the latest OS headers etc., while CW will complain
with

#warning "Compiler support for c99 has been turned on"

This allows you to build cfm stuff. And yes I have successfully used Xcode
too to build a dylib.

This above to let you know that you still can produce decent cfm for MacOSX.
Because it links to carbon in OSX, this cfm cannot be used in carbon OS9.


Alfred

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Developing plugins with Xcode
Date: 22.11.04 03:55 (Mon, 22 Nov 2004 02:55:40 +0000)
From: James Milne

On 22 Nov, 2004, at 02:07, Alfred Van Hoek wrote:

> on 11/21/04 7:41 PM, James Milne at <email address removed> wrote:
>
>> I did this for a couple of reasons:
>>
>> a) It moves me away from the constant treadmill of upgrading
>> Codewarrior, saving me money every 12 months
>
> That's not necessary if you would set a path to
>
> :MSL:
> ::SDKs:MacOSX10.3.0.sdk:
> {System}:Library:CFMSupport:StubLibraries:
> :MacOS Suport:Libraries:Runtime:Libs:
> :Plugin SDK
>
> and link to MSL_All_Carbon.Lib and CarbonLibStub. Make sure you tell
> CW to
> interpret DOS and UNIX Paths.
>
> I am using CW7.
>
> This will let you use the latest OS headers etc., while CW will
> complain
> with
>
> #warning "Compiler support for c99 has been turned on"
>
> This allows you to build cfm stuff. And yes I have successfully used
> Xcode
> too to build a dylib.
>
> This above to let you know that you still can produce decent cfm for
> MacOSX.
> Because it links to carbon in OSX, this cfm cannot be used in carbon
> OS9.

It wasn't getting the latest version of CarbonLib that kept me updating
Codewarrior. It was problems with their debugger, etc.

Anyhow, moving to Xcode ensures I've always got the latest development
tools for free. :-)

Re: Developing plugins with Xcode
Date: 22.11.04 03:53 (Sun, 21 Nov 2004 18:53:04 -0800)
From: Seth Willits
On Nov 21, 2004, at 4:41 PM, James Milne wrote:

> 3) Debugging your plugin
>
> At first glance, there is no obvious way to set up Xcode to debug your
> plugin.
>
> To debug your plugin...
>
> With this executable added to your project, the Run Executable and
> Debug Executable options in the Debug menu will be enabled. This will
> fire up REALbasic, and you will be able to debug your plugin with
> breakpoints, etc.

Ok, if this works (I'll have to try it later) I'll seriously give you a
virtual hug. I haven't worked on my SpriteWorld plugin for quite a
while because it was a pain to debug with numerous DebugStr's.


Seth Willits
------------------------------------------------------------------------
---
President and Head Developer of Freak Software - http://www.freaksw.com
REALbasic Guru at ResExcellence - http://www.resexcellence.com/realbasic

"Rather fail with honor than succeed by fraud."
-- Sophocles
------------------------------------------------------------------------
---

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Developing plugins with Xcode
Date: 22.11.04 02:27 (Sun, 21 Nov 2004 20:27:36 -0500)
From: Stys, Peter
This is very useful info James. Could you make a simple sample Xcode
project available, either from your web site if you have one or maybe RS
could host it for you.

This would be a great help to many of us trying to migrate to Xcode.

Nice work!

Peter.

-----------------------------------------------------------
Peter K. Stys, MD e-mail: <email address removed>
Professor of Medicine tel: (613)761-5444
Ottawa Health Res. Inst. fax: (613)761-5330
Div. of Neuroscience
Ottawa Hosp./ Univ of Ottawa
Ontario, CANADA
http://www.ohri.ca/profiles/stys.asp
-----------------------------------------------------------


-----Original Message-----
From: <email address removed>
[mailto:<email address removed>] On Behalf Of
James Milne
Sent: November 21, 2004 7:41 PM
To: REALbasic Plugins
Subject: Developing plugins with Xcode

Hi guys,

Just thought I'd share some of my experiences developing plugins with
Xcode.

I've recently moved most of my plugins across to Xcode. This has been
made more practical with the release of REALbasic 5.5.4, which allows
you to load plugins from Mach-O format without having to include a CFM
stub.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Developing plugins with Xcode
Date: 22.11.04 02:33 (Mon, 22 Nov 2004 01:33:34 +0000)
From: James Milne

On 22 Nov, 2004, at 01:27, Stys, Peter wrote:

> This is very useful info James. Could you make a simple sample Xcode
> project available, either from your web site if you have one or maybe
> RS
> could host it for you.
>
> This would be a great help to many of us trying to migrate to Xcode.
>
> Nice work!

Thanks; just thought it might help some folk.

REAL Software provide an example project, and stationery you can
install in Xcode which the Xcode New Project Wizard can use to produce
a new plugin project. However, there are a few things missing from it,
which are the issues I outlined in my e-mail.

But sure, I could certainly create an example project which contained
my changes, used pre-compiled headers, etc.

RE: Developing plugins with Xcode
Date: 22.11.04 18:14 (Mon, 22 Nov 2004 12:14:01 -0500)
From: Campbell, Jason
James,

I think it is great you have managed to spur some feedback on this topic. I've been awaiting some actual working debug-capable steps for XCode. Though I cannot seem to reproduce your solution... I don't have the setup for automatically bundling the dylib to .rbx, but I did that by hand with the sdk's plugin converter. XCode fires up RB IDE, but does not break anywhere in my plugin when the program is executed. I had two questions: 1) I assume we set RB to 'OS X Carbon Mach-O' versus the PEF option or does it matter?, and 2) not sure why/how it works being set to the IDE when all past discussion (i.e. CW debugging) has centered around pointing at a built RB project? Can you clarify these points?

> ----------
> From: <email address removed> on behalf of James Milne
> Reply To: REALbasic Plugins
> Sent: Sunday, November 21, 2004 7:41 PM
> To: REALbasic Plugins
> Subject: Developing plugins with Xcode
>
> Hi guys,
>
> Just thought I'd share some of my experiences developing plugins with
> Xcode.
>
> I've recently moved most of my plugins across to Xcode. This has been
> made more practical with the release of REALbasic 5.5.4, which allows
> you to load plugins from Mach-O format without having to include a CFM
> stub.
>
> I did this for a couple of reasons:
>
> a) It moves me away from the constant treadmill of upgrading
> Codewarrior, saving me money every 12 months
>
> b) It makes it easier to debug my plugins, since I've always had
> problems using Codewarrior's debugger on Mac OS X
>
> Now that I've got them moved over, I'm fairly happy. The one thing I
> have lost is the ability to compile my Win32 plugin targets from within
> the same IDE as my Mac ones. However, there are ways around that (which
> I will detail at a later date! :-)
>
> Apple have documentation which is helpful for moving Codewarrior
> projects over to Xcode. It is a decent starting point for someone who,
> like myself, has previously been developing plugins in Codewarrior.
>
> There will probably be a few stumbling blocks for people who try to
> move their plugins across to Xcode. Here are the ones I encountered,
> and how I addressed them. Hopefully this might help anyone else who is
> looking to move across to Xcode.
>
> 1) Precompiled headers
>
> I had some problems with the RB Plugin SDK being used in precompiled
> headers in Xcode. For the uninitiated, a precompiled header file is a
> file which #include's a number of headers you need for the whole of
> your project, and caches them into a form which makes it quicker to
> compile the other source files in your app.
>
> The RB Plugin SDK uses C++ namespaces to isolate QT movie types. This
> is an old constraint for dealing with Win32. However, Xcode balks at
> this at first, as it usually interprets precompiled header files as
> referencing C code.
>
> At first, I modified the RB Plugin SDK to remove the use of namespaces.
> However, this has transpired to be unnecessary.
>
> To combat this, you can set a preference for you target. Specifically,
> if you open the info window for your plugin target in Xcode, then click
> on the Build tab and select GNU C/C++ Compiler from the list, you can
> modify the Compile Sources As option. Set this to C++, and this should
> avoid this problem.
>
> 2) Bundling your plugin dylib so that REALbasic can load it
>
> To do this, I wrote a simple RB command-line project which takes the
> contents of a folder and builds it into a .rbx file (which is really
> just a REALbasic Virtual Volume.)
>
> You can integrate this tool into the Xcode build process by creating a
> Shell Script Build Phase.
>
> For a Shell Script Build Phase, you can write a bunch of shell commands
> which are executed after the main part of compiling your target has
> completed.
>
> In my Shell Script build phase, I copy the dylib file from the Xcode >
> build directory for my project, and put it into a folder hierarchy
> which is laid out as it should be inside the virtual volume. I then get
> the shell script to execute my command line RB plugin assembler app.
>
> The assembler app produces the .rbx file. Out of convenience, for my
> 'Development' build style, I get it to copy the .rbx file straight into
> the REALbasic plugins directory.
>
> 3) Debugging your plugin
>
> At first glance, there is no obvious way to set up Xcode to debug your
> plugin.
>
> To debug your plugin, you first need to add an Executable to your
> project. You don't want to add REALbasic itself as the executable.
> REALbasic is a CFM application, and as such will not be recognised by
> Xcode's debugger as a valid host executable for your plugin.
>
> Instead, you need to add a support application called LaunchCFMApp to
> your project as the executable. The path to LaunchCFMApp is:
>
> /System/Library/Frameworks/Carbon.framework/Versions/A/Support/
> LaunchCFMApp
>
> As an argument to LaunchCFMApp, you want to pass the path to REALbasic,
> which on my machine is:
>
> /Volumes/Development/Applications/REALbasic/REALbasic\ 5.5.4\
> X.app/Contents/MacOS/REALbasic\ 5.5.4\ Mac\ OS\ X
>
> With this executable added to your project, the Run Executable and
> Debug Executable options in the Debug menu will be enabled. This will
> fire up REALbasic, and you will be able to debug your plugin with
> breakpoints, etc.
>
> --
> Kind Regards,
> James Milne
>
> p.s. I'll find my frog
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>
>
>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

RE: Developing plugins with Xcode
Date: 22.11.04 18:38 (Mon, 22 Nov 2004 17:38:58 +0000)
From: James Milne

On Monday, November 22, 2004, at 05:14PM, Campbell, Jason <<email address removed>> wrote:

>James,
>
>I think it is great you have managed to spur some feedback on this topic. I've been awaiting some actual working debug-capable steps for XCode. Though I cannot seem to reproduce your solution... I don't have the setup for automatically bundling the dylib to .rbx, but I did that by hand with the sdk's plugin converter. XCode fires up RB IDE, but does not break anywhere in my plugin when the program is executed. I had two questions: 1) I assume we set RB to 'OS X Carbon Mach-O' versus the PEF option or does it matter?, and 2) not sure why/how it works being set to the IDE when all past discussion (i.e. CW debugging) has centered around pointing at a built RB project? Can you clarify these points?

For Xcode to debug your plugin, you need to configure RB to generate a Mach-O application. Xcode cannot debug CFM as far as I am aware.

On reflection, you are correct about targeting the built application. My steps don't reflect that. When I had been writing that e-mail, I was just making sure that breakpoints in the registration functions etc were hit. Those are called when you are running the IDE, but of course, the other functions won't be called unless you are running in a built application.

To debug an actual application, you will need to target the built app. It does seem that you can't debug your plugin and your REALbasic code in the same session. When you are debugging REALbasic code, the Xcode debugger has no way of attaching to the built application. The only way you can debug your plugin is to add your built Mach-O application to your Xcode project as an executable. This will get Xcode to launch your built app, with your plugin inside it. However, in this situation, you won't be able to use REALbasic to debug the REALbasic code in your built-app (even Remote Debugging can't help here.)

That is indeed a quandry.

I guess what we really need is the ability to have the Xcode debugger attach to an already running process. You could start debugging in REALbasic, which would launch the debug version of your app, allowing you to set breakpoints in your RB code. Once you had done that, you could go to code Xcode, and hypothetically, tell the Xcode debugger to attach to the debug RB app. That way, you could debug both your RB code, and your plugin, in the same session.

RE: Developing plugins with Xcode
Date: 22.11.04 20:09 (Mon, 22 Nov 2004 14:09:17 -0500)
From: Campbell, Jason
I continued on this course and can't get XCode to see my built app as a valid target executable. Not sure why. At first I thought it was because I had to point to the inner app (.../Contents/MacOS/My Application), but this didn't seem to make any difference. I tried it with and without the use of the aforementioned CFMLauncher utility, but seemed that I shouldn't need to use that when aiming at the built app (Mach-O)!? I'd like to know if your functioning test case works if you try to target your built app and set a breakpoint at some arbitrary point. Usually it isn't necessary to debug from both sides of the fence at the same time, but it certainly would be great if there were ever a way to achieve that again. Seems like this was a big hole in the designing of the new plugin structure -- I guess it was RS's way of suggesting we write bug-free plugins right from the start. :) Let us know if you can reproduce debuggability in a built app on your end. Thanks!

> ----------
> From: <email address removed> on behalf of James Milne
> Reply To: REALbasic Plugins
> Sent: Monday, November 22, 2004 12:38 PM
> To: REALbasic Plugins
> Cc: REALbasic Plugins
> Subject: RE: Developing plugins with Xcode
>
>
> On Monday, November 22, 2004, at 05:14PM, Campbell, Jason <<email address removed>> wrote:
>
> >James,
> >
> >I think it is great you have managed to spur some feedback on this topic. I've been awaiting some actual working debug-capable steps for XCode. Though I cannot seem to reproduce your solution... I don't have the setup for automatically bundling the dylib to .rbx, but I did that by hand with the sdk's plugin converter. XCode fires up RB IDE, but does not break anywhere in my plugin when the program is executed. I had two questions: 1) I assume we set RB to 'OS X Carbon Mach-O' versus the PEF option or does it matter?, and 2) not sure why/how it works being set to the IDE when all past discussion (i.e. CW debugging) has centered around pointing at a built RB project? Can you clarify these points?
>
> For Xcode to debug your plugin, you need to configure RB to generate a Mach-O application. Xcode cannot debug CFM as far as I am aware.
>
> On reflection, you are correct about targeting the built application. My steps don't reflect that. When I had been writing that e-mail, I was just making sure that breakpoints in the registration functions etc were hit. Those are called when you are running the IDE, but of course, the other functions won't be called unless you are running in a built application.
>
> To debug an actual application, you will need to target the built app. It does seem that you can't debug your plugin and your REALbasic code in the same session. When you are debugging REALbasic code, the Xcode debugger has no way of attaching to the built application. The only way you can debug your plugin is to add your built Mach-O application to your Xcode project as an executable. This will get Xcode to launch your built app, with your plugin inside it. However, in this situation, you won't be able to use REALbasic to debug the REALbasic code in your built-app (even Remote Debugging can't help here.)
>
> That is indeed a quandry.
>
> I guess what we really need is the ability to have the Xcode debugger attach to an already running process. You could start debugging in REALbasic, which would launch the debug version of your app, allowing you to set breakpoints in your RB code. Once you had done that, you could go to code Xcode, and hypothetically, tell the Xcode debugger to attach to the debug RB app. That way, you could debug both your RB code, and your plugin, in the same session.
>
> --
> James Milne
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>
>
>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Developing plugins with Xcode
Date: 22.11.04 22:46 (Mon, 22 Nov 2004 21:46:27 +0000)
From: James Milne

On 22 Nov, 2004, at 19:09, Campbell, Jason wrote:

> I continued on this course and can't get XCode to see my built app as
> a valid target executable. Not sure why. At first I thought it was
> because I had to point to the inner app (.../Contents/MacOS/My
> Application), but this didn't seem to make any difference. I tried it
> with and without the use of the aforementioned CFMLauncher utility,
> but seemed that I shouldn't need to use that when aiming at the built
> app (Mach-O)!? I'd like to know if your functioning test case works
> if you try to target your built app and set a breakpoint at some
> arbitrary point. Usually it isn't necessary to debug from both sides
> of the fence at the same time, but it certainly would be great if
> there were ever a way to achieve that again. Seems like this was a
> big hole in the designing of the new plugin structure -- I guess it
> was RS's way of suggesting we write bug-free plugins right from the
> start. :) Let us know if you can reproduce debuggability in a built
> app on your end. Thanks!

I've been having some problems with my example program, too.

I have two custom executables in my Xcode project:
a) REALbasic, which I use to debug some of the custom control drawing
code in my plugin, so that I can check the code is drawing itself
properly into the window in the IDE

b) a MiniShell application, which is the Mach-O Built Application
created by compiling a small project which does nothing more than throw
up a window containing an instance of my plugin control.

If I open up the Debugger window in Xcode (Cmd-Shift-Y), and make sure
I've added the Executable popup menu to its toolbar, I can select which
Executable I wish to debug the plugin in. If I choose REALbasic, it
succesfully starts REALbasic up and I can debug my plugin.

If I switch the debugging executable to MiniShell, GDB actually crashes
on me when it attempts to load the symbol information out of the built
application.

Here is the call stack for the part of GDB that crashed:

Thread 0 Crashed:
0 gdb-powerpc-apple-darwin 0x00140dac bfd_hash_lookup + 0x8c
1 gdb-powerpc-apple-darwin 0x001316c4 bfd_get_section_by_name + 0x1c
2 gdb-powerpc-apple-darwin 0x000b96a0 dyld_load_symfile + 0x250
3 gdb-powerpc-apple-darwin 0x000b9a10 dyld_load_symfiles + 0x19c
4 gdb-powerpc-apple-darwin 0x000baa94 dyld_update_shlibs + 0x68
5 gdb-powerpc-apple-darwin 0x00091dd4 macosx_dyld_update + 0xec
6 gdb-powerpc-apple-darwin 0x0009107c macosx_solib_add + 0x3cc
7 gdb-powerpc-apple-darwin 0x0007c054 handle_inferior_event + 0x109c
8 gdb-powerpc-apple-darwin 0x0007ac74 fetch_inferior_event + 0xfc
9 gdb-powerpc-apple-darwin 0x000b81ec fetch_inferior_event_wrapper +
0x10
10 gdb-powerpc-apple-darwin 0x0001af7c catcher + 0xd0
11 gdb-powerpc-apple-darwin 0x0001b14c catch_errors + 0x40
12 gdb-powerpc-apple-darwin 0x000b80d0 inferior_event_handler + 0xa4
13 gdb-powerpc-apple-darwin 0x00048b8c process_event + 0x58
14 gdb-powerpc-apple-darwin 0x00048bf4 gdb_do_one_event + 0x34
15 gdb-powerpc-apple-darwin 0x0001af7c catcher + 0xd0
16 gdb-powerpc-apple-darwin 0x0001b14c catch_errors + 0x40
17 gdb-powerpc-apple-darwin 0x00048c38 start_event_loop + 0x30
18 gdb-powerpc-apple-darwin 0x00002b54 captured_command_loop + 0x30
19 gdb-powerpc-apple-darwin 0x0001af7c catcher + 0xd0
20 gdb-powerpc-apple-darwin 0x0001b14c catch_errors + 0x40
21 gdb-powerpc-apple-darwin 0x00003a08 captured_main + 0xe70
22 gdb-powerpc-apple-darwin 0x0001af7c catcher + 0xd0
23 gdb-powerpc-apple-darwin 0x0001b14c catch_errors + 0x40
24 gdb-powerpc-apple-darwin 0x00003a44 gdb_main + 0x38
25 gdb-powerpc-apple-darwin 0x00002ac4 main + 0x44
26 gdb-powerpc-apple-darwin 0x000027b0 _start + 0x188
27 dyld 0x8fe1a558 _dyld_start + 0x64

I can only presume that the Mach-O linker in REALbasic is producing
Mach-O executables that GDB doesn't like. I presume there must be
crucial pieces of information missing, making the Mach-O executable
slightly defective, or at least, unusable with GDB.

I am going to try writing a little wrapper application, similar to
LaunchCFMApp, which will chain the RB Mach-O build application as a
child process. This helper app could take the path to our RB Mach-O
binary as a command line argument. Perhaps we can use GDB to start the
helper app, which in turn chains the RB app, and we might be able to
debug our plugins in a built application.

I'll keep you posted with my progress.