Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> Is C++ code still part of 1.5 release?


+
David Medinets 2013-05-13, 03:22
+
Christopher 2013-05-13, 03:45
+
Josh Elser 2013-05-13, 14:40
+
Christopher 2013-05-13, 15:08
+
David Medinets 2013-05-13, 21:29
+
Eric Newton 2013-05-14, 02:48
+
Adam Fuchs 2013-05-17, 14:26
+
Billie Rinaldi 2013-05-17, 14:49
+
Christopher 2013-05-17, 15:53
+
Adam Fuchs 2013-05-17, 18:04
+
Christopher 2013-05-17, 18:31
+
Keith Turner 2013-05-17, 18:46
+
Josh Elser 2013-05-17, 18:22
+
William Slacum 2013-05-17, 18:49
+
Adam Fuchs 2013-05-17, 19:11
+
John Vines 2013-05-17, 19:17
+
Josh Elser 2013-05-17, 19:35
+
John Vines 2013-05-17, 19:51
+
Michael Berman 2013-05-17, 20:00
+
Josh Elser 2013-05-17, 20:20
+
Adam Fuchs 2013-05-17, 21:12
+
Billie Rinaldi 2013-05-17, 21:39
+
Adam Fuchs 2013-05-18, 02:11
+
Christopher 2013-05-18, 02:39
+
Dave Marion 2013-05-17, 22:01
+
Christopher 2013-05-17, 21:53
+
Drew Pierce 2013-05-17, 21:42
+
Michael Allen 2013-05-17, 21:19
+
Christopher 2013-05-17, 21:39
+
Josh Elser 2013-05-17, 21:36
+
William Slacum 2013-05-17, 21:34
+
Billie Rinaldi 2013-05-17, 20:26
+
William Slacum 2013-05-17, 20:57
+
Corey Nolet 2013-05-17, 19:19
+
William Slacum 2013-05-17, 19:34
+
Christopher 2013-05-14, 00:43
+
Billie Rinaldi 2013-05-13, 14:21
+
Christopher 2013-05-13, 15:13
+
John Vines 2013-05-13, 15:34
+
Christopher 2013-05-13, 21:18
+
Josh Elser 2013-05-13, 23:37
Copy link to this message
-
Re: Is C++ code still part of 1.5 release?
Well, I'm building against the latest in CentOS 6, so that's glibc 2.12.

It's also relevant to ask the platform for another reason: RPMs. The
RPM I'm building is CentOS 6, and I know that's got some compatibility
issues with RHEL/CentOS 5.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, May 13, 2013 at 7:37 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
> I agree with you, Christopher. I don't think it's unreasonable to expect a
> user to download something else if the packaged .so doesn't work on a user's
> system. Write that down, etc, etc.
>
> But, that does beg the question: what version of glibc are we going to build
> against? That could influence my opinion on the subject..
>
>
> On 05/13/2013 05:18 PM, Christopher wrote:
>>
>> I question whether the following four steps should be considered a
>> "tremendous headache", simply because of the fact that one needs to
>> download a different file than the one already downloaded...
>>
>> 1. Download source tarball
>> 2. Unpack source tarball
>> 3. Navigate to server/src/main/c++
>> 4. Run "make"
>>
>> ... but I can easily add it back in if that's the consensus.
>>
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Mon, May 13, 2013 at 11:34 AM, John Vines <[EMAIL PROTECTED]> wrote:
>>>
>>> That sounds like a tremendous headache for the users where the pre-built
>>> native libraries aren't sufficient.
>>>
>>>
>>> On Mon, May 13, 2013 at 11:13 AM, Christopher <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> Yeah, you could essentially unpack the source over the binary... for
>>>> now, anyway... but some things would be slightly different. Like the
>>>> addition of the proxy/thrift directory for the generated thrift
>>>> bindings pulled out of proxy/target/. But... I really don't think it
>>>> should be a goal to make the source directory structure and the binary
>>>> directory structure overlap like this. The binary tarball should
>>>> really just a "ready to use" thing, and the source should be a "ready
>>>> to develop or re-package" thing.
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>>
>>>> On Mon, May 13, 2013 at 10:21 AM, Billie Rinaldi
>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> On Sun, May 12, 2013 at 8:45 PM, Christopher <[EMAIL PROTECTED]>
>>>>
>>>> wrote:
>>>>>
>>>>>
>>>>>> I went through all the rpms and debs and tarballs to check to see if
>>>>>> they were including the right things (ACCUMULO-1404).
>>>>>>
>>>>>> Personally, I don't think they should be in a binary-release... source
>>>>>> code that needs to be compiled sounds like something you'd get out of
>>>>>> the source tarball, so I assumed its inclusion was an oversight that I
>>>>>> was correcting. (I did make sure the *.so files were included.) If
>>>>>> there's a reason to keep source code in a binary package, then, I can
>>>>>> add it back in, but really, if you can't use it out of the box, I'm
>>>>>> not sure it should be in the binary tarball.
>>>>>>
>>>>>
>>>>> This would be a change from what we were doing with "dist" releases,
>>>>> but
>>>>
>>>> I
>>>>>
>>>>> am not necessarily against it.  I find it nice to have the source
>>>>> there,
>>>>
>>>> as
>>>>>
>>>>> I often look things up in it.  To reproduce the previous structure,
>>>>
>>>> would I
>>>>>
>>>>> be able to just unpack the source release over the binary release?
>>>>>
>>>>> Billie
>>>>>
>>>>>
>>>>>> This is related to another issue I was looking at also, so i'll
>>>>>> mention
>>>>
>>>> it
>>>>>>
>>>>>> here:
>>>>>> What do we include for proxy thrift bindings? I see that currently
>>>>>> we're dropping in the gen-rb, gen-java, and gen-py folders from the
>>>>>> proxy thrift compilation. However, I'm not so sure we should be doing
>>>>>> this... because:
>>>>>>
>>>>>> 1) we don't need to include java bindings for the proxy; compiled
>>>>>> versions are already in the proxy jar,
>>>>>> 2) not all packagers will even have installed thrift with the ability
>>
+
Christopher 2013-05-13, 03:46
+
David Medinets 2013-05-13, 12:26
+
Christopher 2013-05-13, 13:45
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB