Description of problem: fltk-config --cflags (and --cxxflags) exports the flags that fltk was built with. Version-Release number of selected component (if applicable): 1.3.3-6 How reproducible: 100% Steps to Reproduce: 1. run "fltk-config --cxxflags" 2. 3. Actual results: -I/usr/include/freetype2 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT Expected results: -I/usr/include/freetype2 Additional info: This is a longstanding bug with fltk (see bug #199656). Also see e.g.: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828081 Dmitri. --
OK, we can omit duplicated items from OPTIM, but I think we may have to keep @LARGEFILE@ and @PTHREAD_FLAGS@
Well, I'm *pretty* sure @LARGEFILE@ needs to stay at least, less sure about @PTHREAD_FLAGS@, but I'm keeping both to be on the safe side for now.
fltk-1.3.3-7.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-62255dcdf8
fltk-config --cxxflags should tell the end user of fltk library which flags he has to use to compile his program that uses fltk library. Not the flags that one needs to compile fltk itself. So it is up to the user to decide if he wants to use e.g. @LARGEFILE@ Dmitri.
It is my understanding you cannot mix apps/libraries that use largefile flags with those that do not. I *think* the same can be said for threading-related ones, but I'm less certain there.
That said, if you have contrary experience or evidence that means @LARGEFILE@ and/or @PTHREAD_FLAGS@ can be safely removed, I'd happy to do so.
My understanding is the contrary, that the _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE options only affect individual compilation units. According to the glibc user manual (https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html), the macros _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE, _REENTRANT, and _THREAD_SAFE only serve to make certain function prototypes available. If the macro is not defined, the prototypes are simply not visible to the source in question. The option that is bad to mix is _FILE_OFFSET_BITS=64, because this option actually changes the sizes of structure members and shadows function names and so on. But even that can be done if you are careful not to expose C I/O library types over the interface between projects. AFAIK the macros _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE, _THREAD_SAFE, and _REENTRANT do not actually change the interface of anything, they only define additional non-conflicting functions and types.
OK, thanks for looking more into it. I will remove those too then.
fltk-1.3.3-7.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-62255dcdf8
fltk-1.3.3-8.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-62255dcdf8
fltk-1.3.3-8.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-62255dcdf8
fltk-1.3.3-8.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.