On 12 September 2015 at 19:08, Greg Stein <gst...@gmail.com> wrote: > > On Sep 12, 2015 11:01 AM, "Ivan Zhakov" <i...@visualsvn.com> wrote: >> >> On 12 September 2015 at 15:08, Greg Stein <gst...@gmail.com> wrote: >> > [redirected to dev@serf] >> > >> > On Mon, Apr 6, 2015 at 8:32 AM, Bert Huijben <b...@qqmail.nl> wrote: >> > >> >> > -----Original Message----- >> >> > From: serf-...@googlegroups.com [mailto:serf-...@googlegroups.com] On >> >> > Behalf Of s...@googlecode.com >> >> > Sent: maandag 6 april 2015 11:25 >> >> > To: serf-...@googlegroups.com >> >> > Subject: [serf-dev] [serf] r2489 committed - In preparation of serf >> >> 1.4.0, >> >> > remove the get_remaining function from t... >> >> > >> >> > Revision: 2489 >> >> > Author: lieven.govaerts >> >> > Date: Mon Apr 6 09:24:18 2015 UTC >> >> > Log: In preparation of serf 1.4.0, remove the get_remaining >> >> > function >> >> > from the >> >> > bucket API. >> >> > >> >> > This reverts most of r2008, r2009, r2010 and r2198. From r2008 I kept >> >> > the >> >> > read_bucket_v2 function, which is needed for set_config. >> >> >> >> If we still keep the read_bucket_v2 feature, what is the reason for >> >> just >> >> removing get_remaining? >> >> >> >> >> >> We still have to handle the linkage problems if we use the >> >> read_bucket_v2() system for versioning, but we leave out the tests that >> >> were added to find problems caused by different function pointers. >> >> >> >> >> >> The reason we see errors on this feature on several platforms is just >> >> this >> >> linkage problem, while the get_remaining code itself is pretty stable >> >> as >> >> far as I can tell. I'm guessing that the reason for removing the code >> >> is >> >> that we see this errors. >> >> >> >> >> >> Our scons scripts make us link both the static library and shared >> >> library >> >> versions of the same functions, and then a simple pointer comparison on >> >> a >> >> function pointer isn't going to work as expected. >> >> >> >> >> >> And with a shared library build, there are other possible problems: >> >> sometimes you get a pointer to a wrapping function... or the pointer >> >> value >> >> is not guaranteed because the code might be moved under some >> >> circumstances >> >> (unload+load of library) >> >> >> > >> > So you're saying that a pointer to a specific function might have *two* >> > values under Windows? Within a single executable? That A could see a >> > different value from B? >> > >> This is not Windows specific problem, the original problem report was on >> Linux: >> "Buckets v2 check doesn't work on Linux in the test suite >> (test_aggregate_buckets fails)" [1] >> >> Bert commented that serf on Windows had similiar problems, but I >> don't know details. >> [1] https://issues.apache.org/jira/browse/SERF-134 > > That JIRA indicates there are multiple copies of the function, which is > clearly wrong. I don't know details, but it seems related how linker, loader and relocation works on Linux: http://reverseengineering.stackexchange.com/questions/1992/what-is-plt-got
-- Ivan Zhakov
