On Friday, 18 June 2010, at 21:09:24 (-0400),
Jeff Johnson wrote:
> Any idea how "portably" POSIX dlsym() is in 2010?
According to the Open Group website, dlsym() and dlopen() are at
*least* in POSIX.1 2004 if not earlier. And they came from SunOS, so
Solaris portability won't be an issue. MacO
On Jun 18, 2010, at 9:03 PM, Michael Jennings wrote:
>
> Ah, okay. I guess I was envisioning for runtime checks:
>
> void *f = dlopen(NULL, RTLD_LAZY);
> if (dlsym(f, "popt_something")) {
>...
> }
>
Any idea how "portably" POSIX dlsym() is in 2010?
There's the GNUish dlvsym() that nee
On Friday, 18 June 2010, at 20:31:28 (-0400),
Jeff Johnson wrote:
> But note run-time, where its not always possible to do the test,
> particularly if popt was built by vendors differently, or different
> versions or feature sets.
>
> What I was envisioning is merely a Bloom filter with an API li
On Jun 18, 2010, at 8:13 PM, Michael Jennings wrote:
> On Friday, 18 June 2010, at 14:01:05 (-0400),
> Jeff Johnson wrote:
>
>> Should I go to the effort of a run-time "features" acquisition API?
>
> IMHO, no. Any time you add fluff, you get further away from the meat,
> and there's room for e
On Friday, 18 June 2010, at 14:01:05 (-0400),
Jeff Johnson wrote:
> Should I go to the effort of a run-time "features" acquisition API?
IMHO, no. Any time you add fluff, you get further away from the meat,
and there's room for error. The least error-prone approach is to
check for X when you use
On Jun 18, 2010, at 1:45 PM, Michael Jennings wrote:
> On Friday, 18 June 2010, at 10:52:22 (-0400),
> Jeff Johnson wrote:
>
>> (aside)
>> Instead of a #define version, I typically us a "de facto" check
>> for POPT in compatibilities. E.g. in order to use POPT 2.0
>> in rpm-5.3.2 I'll likely do
On Friday, 18 June 2010, at 10:52:22 (-0400),
Jeff Johnson wrote:
> (aside)
> Instead of a #define version, I typically us a "de facto" check
> for POPT in compatibilities. E.g. in order to use POPT 2.0
> in rpm-5.3.2 I'll likely do
> #if defined(POPT_ARGFLAG_CALCULATOR)
> ...
More administrivia related to "incompatibilities"
There is no current means (because I've always thought versioning is a crock)
to detect what POPT API version is being used.
(aside)
Instead of versioning, I've always been ultra-careful not to
introduce any incompatibilities into POPT's API/ABI.