Scott-
Sorry I was so slow to respond... was rather busy this week...
Anyway, I helped a friend do more-or-less this a little while back.
I've attached a makefile template I wrote which builds frameworks from
libtool-built libraries. It's kind of rough... but it definitely gets
the job done. Should probably eventually hack libtool to generate a
"framework" target on OS X. That would be COOL. ;-)
After you've built the Framework with this makefile, all you have to do
is drop the things in PB/XC (as a linked framework) and build! Make
sure you have PB/XC copy the framework into the right place in your
app. For this template, that's "myapp.app/Contents/Frameworks/
I've built apps linked against as many as 8 of these included libtool
built frameworks before... pretty easy to build after you get used to
it.
A few notes:
0. You have to actually edit the template for it to do anything
useful... it's very self explanatory.
1. to use the framework, you want to put this in the directory where
the final library would be generated, for many projects that is inside:
project/src or project/lib
2. after you drop it in the directory and then add the line:
-include Makefile.framework
to the end of the main Makefile, or Makefile.in
then "make; make framework" will do all you need.
3. The template I have attached is for building the somewhat complex
"tunepimp" library (http://www.musicbrainz.org/) which depends on
several other libraries... I have cleaner templates, but I figured this
one would be most helpful since iconv depends on glib, etc.
4. Each library you build will require one of these makefiles...
customized to the library.
5. Not that I need to say this, but make sure you build the frameworks
in order... i.e. build glib.framework move it into the right place for
linking... then build iconv.framework.
That's all. If you have any questions, drop me a line. I should at
least get to email by this weekend... ;-)
-eric
----------------------------
Eric Seidel
email@hidden
BSD Technologies
Apple Computer
[demime 0.98b removed an attachment of type application/octet-stream which had a name of Makefile]
On Nov 4, 2003, at 10:27 AM, Scott Lamb wrote:
> I'm trying to link a glib-based library (the-still-in-development
> libgaim) into a Cocoa application (Adium), and include it within the
> application bundle for ease of installation. There are three problems
> I'm not sure how to solve:
>
> 1) iconv. glib requires gettext, which requires iconv. Jaguar did not
> include this library; Panther does. I develop on Panther, and want to
> produce binaries that will run on either system. Right now, I can't
> even link without warnings. It says something like this:
>
> ld: warning multiple definitions of symbol _locale_charset
> /usr/lib/libiconv.dylib(localcharset.o) definition of _locale_charset
> /usr/local/lib/libintl.dylib(localcharset.o) definition of
> _locale_charset
>
> (where /usr/lib/libiconv.dylib is the Panther-provided GNU iconv, and
> /usr/local/lib/libintl.dylib I just created.)
>
> I've tried a couple different settings:
>
> $ ./configure --with-iconv-prefix=/usr/lib
> I'd hoped this would use the system-provided iconv with no duplicate
> symbols, but no go.
>
> $ ./configure --without-libiconv-prefix
> I'd hoped this would completely ignore /usr/lib/libiconv and produce
> its own, so I could have binaries suitable for Jaguar. Same result,
> though.
>
> 2) install_name. I haven't even tried to tackle this, but some other
> Adium developers have. To actually include the dependent libraries in
> the bundle, they apparently need an install_name of
> @executable_path/../Frameworks/LIBRARY_NAME.dylib (or something like
> that). And this has to be done at the link time of the library. (Which
> seems weird to me; normally a library shouldn't have to know how it
> will be used when it is linked.) They actually got this to work, but
> they did it by tweaking the link lines manually, which is too much
> work to do whenever libgaim changes.
>
> So I guess my question is, is there an easy way to link these
> libraries (which are all autoconf/automake/libtool monstrosities) with
> those flags? Just running configure with LDFLAGS="-install_name BLAH"
> defined won't work because each package builds a few different dylibs,
> and the library name is part of the argument.
>
> 3) dynamically loading libraries. libgaim builds its prpls (protocol
> plugins) to load dynamically via gmodule (which does a dlopen() and
> similar, I assume). I can't get them to load; it always says it can't
> find the protocol plugin.
>
> Currently it's building them as libBLAH.so. I'm not quite sure what
> that is. I know that under Linux, .so = shared object; I'd use it
> where I'd use a .dylib under OS X. So I suspect that these should
> actually be named .dylib. But file tells me they are different than
> dylibs somehow:
>
> $ file liboscar.so
> liboscar.so: Mach-O bundle ppc
> $ file libgaim.0.0.0.dylib
> libgaim.0.0.0.dylib: Mach-O dynamically linked shared library ppc
> $ file librsync.a
> librsync.a: current ar archive
>
> And Under Linux, a .so is
> $ file libc-2.3.2.so
> libc-2.3.2.so: ELF 32-bit LSB shared object, Intel 80386, version 1
> (SYSV), stripped
>
> I'm also going to ask about this on the gaim list (since there seem to
> be a lot of project-specific configure options about this) but the
> .so/.dylib question is likely to come up, and I don't think there are
> any OS X people on that list.
>
>
> Any help with these problems would be much appreciated. I skimmed over
> a lot of information here; if there's more you need, I'd be quite
> happy to dig it up.
>
> Thanks,
> Scott Lamb
> _______________________________________________
> unix-porting mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/unix-porting
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
unix-porting mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/unix-porting
Do not post admin requests to the list. They will be ignored.
