FLTK logo

STR #2984

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]

STR #2984

Application:FLTK Library
Status:2 - Closed w/o Resolution
Priority:4 - High, e.g. key functionality not working
Scope:2 - Specific to an operating system
Subsystem:Core Library
Summary:nitems() macro breaks builds on kfreebsd
Version:1.3-current
Created By:kamalmostafa
Assigned To:greg.ercolano
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

No files


Trouble Report Comments:


Name/Time/Date Text  
 
#1 kamalmostafa
12:12 Sep 17, 2013
On GNU/kFreeBSD (Debian unstable), the kernel header /usr/include/sys/kern/param.h defines a macro "nitems()" which collides with the identically named macro in Fl_Check_Browser.H.

Real-world build failure case:
https://buildd.debian.org/status/fetch.php?pkg=fldigi&arch=kfreebsd-amd64&ver=3.21.75-1&stamp=1378244243

Simple example:

$ cat xxx.C
#include <sys/param.h>
#include <FL/Fl_Check_Browser.H>

$ g++ -c xxx.C
In file included from /usr/include/osreldate.h:1:0,
                 from /usr/include/i386-kfreebsd-gnu/bits/param.h:36,
                 from /usr/include/i386-kfreebsd-gnu/sys/param.h:31,
                 from xxx.C:1:
/usr/include/FL/Fl_Check_Browser.H:91:7: error: expected unqualified-id before 'sizeof'
   int nitems() const { return nitems_; }
       ^
/usr/include/FL/Fl_Check_Browser.H:91:7: error: expected ')' before 'sizeof'

$ uname -a
GNU/kFreeBSD fischer 9.0-2-686 #0 Fri Aug 23 18:20:33 UTC 2013 i386 i386 QEMU Virtual CPU version 1.1.2 GNU/kFreeBSD

$ apt-cache policy libfltk1.3-dev | grep Installed
  Installed: 1.3.2-3
 
 
#2 greg.ercolano
03:09 Sep 20, 2013
This really sounds like something that should be reported to the guys
who put this distro together. Sounds like a bug in the kernel file
to let a macro like that find its way into the public namespace.

Firefox didn't like the link; something about certs not checking out.

I suppose if we had to, we could put an #undef nitems in our .H file
with a comment citing this platform. Seems kooky though.

If you report to them, cite the bug report here so we can track it.
If they fix it as a bug, then we'll close this.
 
 
#3 greg.ercolano
09:12 Sep 20, 2013
BTW, please note nitems() is a public method name in our class, not a macro.

The OS's macro definition is preventing /any program from using the name
nitems() for any kind of function or class method, whether public or private.

Since the nitems() method name has been part of the FLTK public API for so many years,
we couldn't really change its name if we wanted to; it would break the API and ABI.

Best we could do I think is an #undef, but that too might get messy for apps
that define an nitems() macro for their own use. We'd have to #ifdef the #undef
for just this platform I think.

Do you find the following non-FLTK code also fails on this OS?

---
#include <stdio.h>
#include <sys/param.h>
static int nitems() {
    return(1+2);
}
int main() {
    printf("Result: %d\n", nitems());
    return(0);
}
---

If so, I'd offer this is a problem with the OS, not the application,
and the sooner the bug is reported to them the better, before they release.
(I take it this platform is still a work in progress)

AFAIK, nitems() does not fit any of the reserved name patterns for GNU C library:
http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html

..and is not a reserved word in C++:
http://en.cppreference.com/w/cpp/keyword

Would like to see if the other devs agree.
 
 
#4 AlbrechtS
10:08 Jan 03, 2014
I agree that it looks strange that such a macro is defined in a system header. Either that should be fixed, or the fldigi sources could be refactored not to use FLTK sources (headers) together with such system headers in one source file - although that might be difficult to do, since the include hierarchy seems pretty deep (copying the error message from the link above for later reference):

g++ -DHAVE_CONFIG_H -I.  -DBUILD_FLDIGI -DLOCALEDIR=\"/usr/share/locale\" -I. -I./include -I./irrxml -I./libtiniconv -I./fileselector -I./xmlrpcpp -DPKGDATADIR=\"/usr/share/fldigi\" -D_FORTIFY_SOURCE=2 -pthread    -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-kfreebsd-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm   -I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-kfreebsd-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm    -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT       -D_REENTRANT     -I/usr/include/libpng12        -pipe -Wall -fexceptions -O2 -ffast-math -finline-functions  -DNDEBUG -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c -o fldigi-xmlrpc.o `test -f 'misc/xmlrpc.cxx' || echo './'`misc/xmlrpc.cxx
In file included from /usr/include/osreldate.h:1:0,
                 from /usr/include/x86_64-kfreebsd-gnu/bits/param.h:36,
                 from /usr/include/x86_64-kfreebsd-gnu/sys/param.h:31,
                 from /usr/include/pulse/sample.h:28,
                 from /usr/include/pulse/simple.h:28,
                 from ./include/sound.h:284,
                 from ./include/modem.h:10,
                 from ./include/rtty.h:35,
                 from ./include/configuration.h:31,
                 from misc/xmlrpc.cxx:51:
/usr/include/FL/Fl_Check_Browser.H:91:7: error: expected unqualified-id before 'sizeof'
   int nitems() const { return nitems_; }
       ^
/usr/include/FL/Fl_Check_Browser.H:91:7: error: expected ')' before 'sizeof'

If I understand what's happening, the real cause is to include <pulse/simple.h> together with <FL/Fl_Check_Browser.H>, since the former pulls in <sys/param.h>.

Anyway, since (as Greg reported) FLTK doesn't use any reserved names or such, this seems like a "usual" name clash, and it should either be solved in fldigi or the system headers mentioned. IMHO.

To the OP: please report any progress within the next 14 days, otherwise we would have to close this STR w/o resolution.
 
 
#5 greg.ercolano
15:52 May 21, 2014
This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR.

This is overdue for closing.
 
 
#6 greg.ercolano
15:52 May 21, 2014
This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR.

This is overdue for closing.
 
     

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.