| Message ID | ef125528-3e7a-5009-31aa-a3a8e8fd7ca2@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2 March 2018 at 14:05, Eric Blake <eblake@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: >> 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... >> 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. > 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. > If so, > does this patch solve things? If it does, I'll squash it in the right place > within the series and submit a v3 pull request. > > diff --git i/scripts/qapi/common.py w/scripts/qapi/common.py > index 077e0fde4f4..aed32646c00 100644 > --- i/scripts/qapi/common.py > +++ w/scripts/qapi/common.py > @@ -2035,6 +2035,13 @@ class QAPIGenC(QAPIGen): > ''', > blurb=self._blurb, copyright=self._copyright) > > + 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. thanks -- PMM
On 03/02/2018 08:34 AM, Peter Maydell wrote: > On 2 March 2018 at 14:05, Eric Blake <eblake@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: >>> 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.
diff --git i/scripts/qapi/common.py w/scripts/qapi/common.py index 077e0fde4f4..aed32646c00 100644 --- i/scripts/qapi/common.py +++ w/scripts/qapi/common.py @@ -2035,6 +2035,13 @@ class QAPIGenC(QAPIGen): ''', blurb=self._blurb, copyright=self._copyright) + def _bottom(self, fname): + return mcgen(''' +/* Dummy typedef to prevent empty .o file */ +typedef int %(name)s; +''', + name=c_name(fname)) + class QAPIGenH(QAPIGenC):