Apple's gcc can't handle deprecated attribute

Jeremy Huddleston Sequoia jeremyhu at macports.org
Fri Oct 5 02:37:54 PDT 2012


On Oct 5, 2012, at 2:02 AM, mk-macports at techno.ms wrote:

> On Oct 5, 2012, at 10:54 AM, Jeremy Huddleston Sequoia wrote:
>> Looks like you made a copy/paste-o for one of them:
>> 
>> -void result_free(result_t *r) __attribute__ ((weak, alias ("csvdb_free_result")));
>> -+void result_free(result_t *r);
>> ++void result_free(result_t *r) __attribute__ ((deprecated));
> 
> Ooops, what's wrong with marking this one here also as deprecated?

It's redundant.  The purpose of the line you are removing is to provide backwards compatibility such that anyone linking against the library using result_free() would get csvdb_free_result() instead.  On darwin, you would need to provide this symbol as:

void result_free(result_t *r) {
  csvdb_free_result(r);
}

But since this is a new project in MacPorts and you don't care about backwards binary compatibility, that's not needed, so I just removed the line and fixed the header to use a weakref in addition to the deprecation.

> Was it already sufficient to do that in the 1st patch file? Should I have stayed with just removing the alias or should I modify it differently?

Your changes would present a message of deprecation at compile time if someone used result_free, but the resulting executable would fail to link.  I fixed such that it the call to result_free() would be rewritten to csvdb_free_result at compile time.

> (At least it does build fine for me here, as well as for the buildbot.)

Yeah, the project builds fine, but a client of the project using the deprecated result_free() would fail. Hopefully my 3am explanation above is not too incoherent.

--Jeremy



More information about the macports-dev mailing list