Mkmf problems on Mac OS X Leopard

Here’s an excerpt from a simple extconf.rb:

have_header('antlr3.h')
have_library('antlr3c', 'antlr3ParserNew')

The “have_library” line worked fine on the previous version of Mac OS
X (Tiger), but under Leopard it can’t find the library. Output is:

checking for antlr3ParserNew() in -lantlr3c... no

The library is definitely present at “/usr/local/lib/libantlr3c.a” and
inspection using the “nm” tool reveals that the “antlr3ParserNew”
symbol is definitely present in the library.

I’ve also tried using “find_library” with an explicit path to the
directory containing the library, and I’ve also tried making a dynamic
version of the library available instead of the static one, but mkmf
simply can’t find the library.

Is there anyway I can get mkmf to be more verbose so that I can
diagnose what’s happening here?

Best wishes,
Wincent

Wincent C. wrote:

Is there anyway I can get mkmf to be more verbose so that I can
diagnose what’s happening here?

Have you looked at mkmf.log?

On 29 Oct, 15:08, Wincent C. [email protected] wrote:

The library is definitely present at “/usr/local/lib/libantlr3c.a” and
inspection using the “nm” tool reveals that the “antlr3ParserNew”
symbol is definitely present in the library.

Note: it may help to indicate which Ruby installation you’re using -
Apple’s or something else?

Anyway… something that may or may not be directly related to your
problem, but in trying to create a universal build of Ruby 1.8.6 I’ve
found that when a build done on my main i386 box is moved to my old
PPC machine for testing, mkmf’s have_func() method works correctly on
the former but always returns false on the latter. (I’ve not tried
building on PPC and testing the result on PPC+i386 yet, so don’t know
what happens there.)

Unfortunately I’ve not had much time to work on the problem myself
(and don’t expect to for at least the next fortnight) and haven’t yet
managed to contact the RubyOSX project maintainer (Matthias
Tarasiewicz, whose original build instructions I’ve been adapting to
suit) or the author of the UB patch I’m currently using (Eloy D.)
to see if they’ve any ideas.

I’m also wondering if Apple’s own patches have already appeared or
will appear in the main Ruby trunk now that Leopard’s out - again,
I’ve not had time to investigate myself. Anyone know more about this?

In the meantime, if anyone wants a copy of what I’ve got so far
(Eloy’s UB+thread patches updated for Ruby 1.8.6 p111 and an update to
RubyOSX’s build instructions) I’ll be happy to pass it on.

HTH

has

On Oct 29, 6:27 pm, has [email protected] wrote:

Note: it may help to indicate which Ruby installation you’re using -
Apple’s or something else?

At the moment, totally stock standard; this is a clean install using
Apple’s Ruby (ruby 1.8.6 (2007-06-07 patchlevel 36) [universal-
darwin9.0]). Will continue to investigate.

Cheers,
Wincent

On Oct 29, 5:07 pm, Tim H. [email protected] wrote:

Wincent C. wrote:

Is there anyway I can get mkmf to be more verbose so that I can
diagnose what’s happening here?

Have you looked at mkmf.log?

Bingo! Couldn’t see the wood for the trees. That will certainly help
me to figure out what’s happening (was just about to try running
extconf.rb under the debugger!).

Cheers,
Wincent

On 29 Oct, 20:41, Wincent C. [email protected] wrote:

On Oct 29, 6:27 pm, has [email protected] wrote:

Note: it may help to indicate which Ruby installation you’re using -
Apple’s or something else?

At the moment, totally stock standard; this is a clean install using
Apple’s Ruby (ruby 1.8.6 (2007-06-07 patchlevel 36) [universal-
darwin9.0]). Will continue to investigate.

Try the following:

require ‘mkmf’
$LDFLAGS << ’ -framework Cocoa’
have_func(‘NSApp’) # should put ‘checking for NSApp()… yes’

If it outputs ‘checking for NSApp()… no’, that would suggest it’s
related to the problem I described. (BTW, I assume you’re running the
exconf.rb script via /usr/bin/ruby, yes? What sort of hardware are you
on; PPC or i386?)

HTH

has

On Oct 29, 2007 4:10 PM, Wincent C. [email protected] wrote:

The library is definitely present at “/usr/local/lib/libantlr3c.a” and
inspection using the “nm” tool reveals that the “antlr3ParserNew”
symbol is definitely present in the library.

Maybe this is because Leopard’s Ruby builds its extensions universal
(for both i386 and ppc architectures), and that
“/usr/local/lib/libantlr3c.a” isn’t universal.

You can verify this using:

$ file /usr/local/lib/libantlr3c.a

If the library is only compiled for your arch, the solution is to
appropriately set the ARCHFLAGS environment variable.

The following page has some information regarding ARCHFLAGS:

http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard#Ruby

Laurent

On Oct 29, 10:13 pm, “Laurent S.”
[email protected] wrote:

appropriately set the ARCHFLAGS environment variable.

The following page has some information regarding ARCHFLAGS:

http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard#Ruby

Many thanks, Laurent; that was it. Running mkmf as follows allows it
to find the function:

ARCHFLAGS="-arch i386" ruby extconf.rb

Good to know that this workaround works. As a longer term solution
I’ll try building a universal binary version of the ANTLR runtime.

Cheers,
Wincent