Re: [Qemu-devel] [PULL v2 00/30] QAPI patches for 2018-03-01

[Eric Blake]

On 03/02/2018 08:34 AM, Peter Maydell wrote:
> On 2 March 2018 at 14:05, Eric Blake <address@hidden> 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:
> > >     AR      libqemuutil.a
> > >
> > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
> > > 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 
before:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/binary-io.c?id=c5d07ce91a8ad51591154450442fa4376441fdfa
https://lists.gnu.org/archive/html/bug-gnulib/2015-10/msg00019.html
https://lists.gnu.org/archive/html/bug-gnulib/2004-07/msg00029.html

> > +    def _bottom(self, fname):
> > +        return mcgen('''
> > +/* Dummy typedef to prevent empty .o file */
> > +typedef int %(name)s;
> > +''',
> > +                     name=c_name(fname))
> > +
> >
> >   class QAPIGenH(QAPIGenC):
>
> 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