Re: Newbie Q: Merge .rez results into a resource fork?
Re: Newbie Q: Merge .rez results into a resource fork?
- Subject: Re: Newbie Q: Merge .rez results into a resource fork?
- From: "Dan Smith" <email@hidden>
- Date: Tue, 26 Jul 2005 08:31:06 -0400
Chris Espinosa <email@hidden> writes:
>
>I am having so many problems that I am not quite sure what questions to ask...
>but three of them are:
>
>a) If I start with a "dynamic Carbon library" template and a "bundle" library
>style, it builds with the ld tool... but it will not accept the -bundle option
>because "powerpc-apple-darwin8-gcc-4.0.0: -bundle not allowed with
>-dynamiclib". However, if I use a "static Carbon library" template it uses
>libtool and ranlib instead of ld, and will not accept the -bundle option for
>other reasons.
>
>Not knowing what the Harlequin RIP really expects, I don't know how I can help
>you here. Perhaps you could dump an outline of what a functional "plugin
>device driver" looks like, so we can figure out what category it fits into?
(Pre-script: an honor to email you... I remember your name on so many page
headings of the circa-1983 Qume-daisywheel-printed version of "Inside Mac.")
I _think_ it is a "shared library" in a "Mach-O bundle" library style, plus Mac
resources in the resource fork. Of course I don't really know what any of that
means except for the "resource" part... Not quite sure what you mean by a
"dump," i.e. is there a tool you want me to use to do this?
The Harlequin RIP is a multiplatform product that has been on market since 68K
Mac days. A "plugin" is written by a Harlequin OEM, namely us, and is
_functionally_ nothing more than a runtime-linked library with a single entry
point. (That single function uses the usual tricks of an integer "selector" and
a void pointer that gets cast to a variety of random things depending on the
selector...) Some features of the design are motivated by the need to deal with
the 68K "A5 world." In Windows a plugin is a DLL, on 68K Mac it is a code
resource, on OS 9 PPC it is a CFM fragment. On UNIX platforms "plugins must be
built as shared libraries (or relocatable object files on SGI machines) which
the RIP will explicitly load."
The manual says (note: they do not currently support 10.4 yet, and the plugin
manual is often a little out of date anyway--I often need to tweak their build
directions and examples a bit). The manual is dated 2005 but I don't think the
actual compiler and linker options shown below are quite right.
RIP plugins on Mac OS X must be Mach-O binaries (not CFM) and must have a file
name of the form:
<plugin-name>.bundle
where <plugin-name> is the name of the plugin, for example, opeg3.bundle.
In "how to compile and link a plugin for use on Mac OS X" it says (in part):
First compile the source, for example:
set PKITDIR=$HOME/PluginKit
cc -c -o example.o example.c -Wno-precomp -g -DMACINTOSH=1 -Dmacintosh
-DBUILDING_FOR_OS_X -I.
-I${PKITDIR}/outputs/hh
Now link the bundle, for example:
cc -shared -bundle -framework Carbon -o example.bundle example.o
${PKITDIR}/Outputs/oo/pluglib
You can now use Rez to add any additional resources, including HqoD or HqiD,
for example:
Rez -o example.bundle -d MACINTOSH=1 -d macintosh -i . -i ${PKITDIR}/outputs/hh
You can now set the files creator and type:
Setfile -c HqGS -t HqDP -a Bi example.bundle
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden