[libRETS-users] Re: Building retsLib and ezRets on Mac OS X 10.4

[Tom Wiebe]

Thanks Keith, that did it! I had to move the CPPFLAGS and LDFLAGS into
the configure statement in the port to get a successful build but, it
worked once I did that. Thanks for all your help!

Tom

On 2/2/07, Keith T. Garner <kgarner at crt.realtors.org> wrote:
> Tom Wiebe wrote:
> > Yeah, a transcription error, I'm actually building a macport (formerly
> > darwinport)
>
> I'm very familiar with ports.  I couldn't live without them.  :)
>
> > for librets and, hopefully ezrets after that. The portfile
> > entry was actually:
> >
> > build.env        CFLAGS=-I${prefix}/include LDFLAGS=-L${prefix}/lib
> >
> > I put it into a configure statement and edited the path to make it
> > clearer, deleting the -L as I went.
> >
> >>
> >>> is the configure statement I'm passing for librets and, all the
> >>> appropriate goodies are living in the locations noted above.
> >>
> >> It looks good otherwise.
> >>
> >> [snip]
> >>
> >>> and my JAVA_HOME is set to
> >>> JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home, which I
> >>> believe to be correct.
> >>
> >> I haven't had to do this on my MacBook Pro, but it probably doesn't hurt.
> >>
> >> Anyway, it doesn't effect the error you're seeing.  The test is to see if
> >> the we can link against the C++ level antlr lib.
> >
> >
> > Yeah, I don't think it's actually using any Java bits here (but am not
> > sure), it was mentioned in the readme's though so thought it best to try
> > setting it first.
>
> The runtime for antlr that does code generation is in java.  Its used after
> you type make it comes into play.  However, that code that is generated
> depends on the native runtime library.
>
> > I'm suspecting a problem with my macports build of Antlr right now. I've
> > built a new portfile to install the latest antlr (2.7.7) and am
> > installing it now. Seems to be a problem with the antlr download site at
> > the moment though, I've got 15% of it 10 minutes in so I'll have to wait
> > a bit to see if that makes a difference, it seems.
>
> I'm not using the antlr port, I have it installed by hand (but encapped, of
> course.)  I can't remember why I'm using a hand compile off the top of my head.
>
> I just did a test where I uninstalled my hand compiled antlr and used the
> ports version.  I figured out the source of your problem.  You want to use
> CPPFLAGS (since this is C++) and not CFLAGS.  Using CFLAGS, the antlr test
> fails.  Using CPPFLAGS it works fine with the antlr in ports.
>
> Actually, thanks for having me do this test.  I found a type-o in the make
> system that was causing compiles with cppunit to fail.  Must have been
> awhile since we ran unit tests.  (cppunit also coming out of ports.)
>
> Keith
>
> --
>   Keith T. Garner - Managing Director - Center for REALTOR(r) Technology
>    kgarner at realtors.org - 312-329-3294 - http://blog.realtors.org/crt
>
> _______________________________________________
> libRETS-users mailing list
> libRETS-users at crt.realtors.org
> http://mail.crt.realtors.org/mailman/listinfo/librets-users
>