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 <josh.el...@gmail.com> 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 <vi...@apache.org> 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 <ctubb...@apache.org> >>> 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 >>>> <billie.rina...@gmail.com> wrote: >>>>> >>>>> On Sun, May 12, 2013 at 8:45 PM, Christopher <ctubb...@apache.org> >>>> >>>> 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 >>>>>> to produce ruby and python bindings, >>>>>> 3) these may or may not be helpful to any particular end user (though >>>>>> it's probably safe to assume ruby and python will be the most common), >>>>>> 4) we're not including the proxy.thrift file, which is perhaps the >>>>>> most important file for the proxy, and including it should be >>>>>> sufficient. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Christopher L Tubbs II >>>>>> http://gravatar.com/ctubbsii >>>>>> >>>>>> >>>>>> On Sun, May 12, 2013 at 11:22 PM, David Medinets >>>>>> <david.medin...@gmail.com> wrote: >>>>>>> >>>>>>> I ran this command: >>>>>>> >>>>>>> git clone --branch 1.5 https://github.com/apache/accumulo.git >>>>>>> >>>>>>> then compiled to get a binary-release.tar.gz file. That gz file does >>>> >>>> not >>>>>>> >>>>>>> seem to contain the C++ files to build the native libraries. Should >>>> >>>> they >>>>>> >>>>>> be >>>>>>> >>>>>>> there? I don't recall hearing about removing them. >>>>>> >>>>>> >>>> >
