Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - Native libraries on Mac


Copy link to this message
-
Re: Native libraries on Mac
Hong Tang 2010-03-11, 19:43
Right, this is similar to the instructions on hadoop-gpl-compression FAQ
page: http://code.google.com/p/hadoop-gpl-compression/wiki/FAQ (the last
question).
On 3/11/10 10:23 AM, "Arun C Murthy" <[EMAIL PROTECTED]> wrote:

> Of course, please open a jira and attach the patch. Thanks!
>
> On Mar 11, 2010, at 10:11 AM, Christopher Tubbs wrote:
>
>> Well, I finally figured it out.
>>
>> Apparently, the library being generated WAS i386 and not x86_64.
>> So, you have to set CFLAGS="-arch x86_64" prior to running "ant
>> compile-native"
>>
>> Think we can get patches into 0.20.3 to fix building on a Mac?
>>
>> Also, it would be nice if ivy could be preconfigured for grabbing
>> dependencies from the lib directory of the tarball, instead of
>> requiring them to be redownloaded.
>>
>> Please and thanks.
>>
>> On Tue, Mar 9, 2010 at 11:45 PM, Christopher Tubbs
>> <[EMAIL PROTECTED]> wrote:
>>> I'm trying to build the native libraries for hadoop on Mac OS X
>>> Leopard (10.5.8) for Hadoop 0.20.1
>>>
>>> I tried the "ant compile-native" method, but I don't have access to
>>> the internet. I do have a local repository though with all the
>>> dependencies (not to mention they are in the $HADOOP_HOME/lib). I was
>>> able to edit the build.xml file to point the repository to my local
>>> one so I could download ivy, but now ivy can't find the dependencies,
>>> and I can't figure out how to point ivy to my maven repository.
>>>
>>> Since the first method didn't work, I tried applying the patch in
>>> HADOOP-3659 (has that been included in 0.20.2?), and got things
>>> working with a little messing with aclocal and friends, but when I
>>> run
>>> make, I get a ZLibCompressor.lo, missing argument for "-m" error in
>>> the build output before it quits.
>>>
>>> Any help on building the native libs by either method would be
>>> greatly
>>> appreciated (preferably the second method, as ivy seems way too
>>> complicated and frustrating to deal with just for this little
>>> issue...
>>> unless it's something simple).
>>>
>>> Christopher
>>>
>