On 03/02/2018 08:34 AM, Peter Maydell wrote:
On 2 March 2018 at 14:05, Eric Blake <ebl...@redhat.com> wrote:
On 03/02/2018 06:38 AM, Peter Maydell wrote:
This produces a huge pile of warnings from my OSX toolchain.
When running ar on libqemuutil.a:
file: libqemuutil.a(qapi-types.o) has no symbols
Part of this change was moving the location of the generated ./qapi-types.c
to qapi/qapi-types.c. Could it be that you are doing an incremental build,
rather than a clean build, and the compiler is picking up the stale version
of the file rather than its new location?
I am doing an incremental build, yes. That needs to work, not break...
And since it was warnings and you picked up qapi/qapi-events.c, it looks
like it does work; phew.
I had a look at the autogenerated .c files on my Linux build, and they
seem to consist only of a bunch of #includes. Why are we not generating
any code here?
But I just checked, and at least for qapi/qapi-types.c, the generated file
IS just a list of includes; and in fact, it looks like all of the mentioned
files are in that boat (for example, qapi/transaction.json has no events, so
qapi/qapi-events-transaction.c being empty makes sense).
I know that some compilers are picky about that.
Yes, I think this is what is causing the problem.
Okay, we've narrowed in on root cause, and it's now just a matter of
finding the magic formula to shut up the toolchain.
Is a typedef enough to
cause the compiler to have something to compile without warnings?
Given that the warnings are coming from nm and ranlib, anything that
doesn't actually cause a symbol to be put into the .o file isn't going
to be enough I suspect.
As I mentioned on IRC, gnulib has used typedefs to prevent empty files
+ def _bottom(self, fname):
+ return mcgen('''
+/* Dummy typedef to prevent empty .o file */
+typedef int %(name)s;
I just tested this, and it isn't sufficient.
Oh well, we'll have to burn actual storage, then. My next try is:
static char dummy_%(name)s;
perhaps with an __attribute__((unused)); if that gets by without
warnings on the toolchains I have available, it should hopefully be
stronger than just the typedef and therefore enough for your toolchain.
I'll submit v3 shortly.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org