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
on 29.10.2007 16:11
on 29.10.2007 17:07
Wincent Colaiuta 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.10.2007 19:26
On 29 Oct, 15:08, Wincent Colaiuta <w...@wincent.com> 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 Duran) 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 29.10.2007 21:45
On Oct 29, 6:27 pm, has <has.te...@virgin.net> 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 29.10.2007 21:47
On Oct 29, 5:07 pm, Tim Hunter <rmag...@gmail.com> wrote: > Wincent Colaiuta 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.10.2007 22:11
On 29 Oct, 20:41, Wincent Colaiuta <w...@wincent.com> wrote: > On Oct 29, 6:27 pm, has <has.te...@virgin.net> 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 29.10.2007 22:16
On Oct 29, 2007 4:10 PM, Wincent Colaiuta <win@wincent.com> 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 30.10.2007 02:10
On Oct 29, 10:13 pm, "Laurent Sansonetti" <laurent.sansone...@gmail.com> 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