fails to build without -fpermissive

[hasufell]

see https://galileo.mailstation.de/jenkins/job/pyro/107/artifact/107_build.log

snip:

[ 25%] Linking CXX shared library ../../lib/libosgTerrain.so
cd /var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/build/src/osgTerrain && /usr/x86_64-pc-linux-gnu/bin/cmake -E cmake_link_script CMakeFiles/osgTerrain.dir/link.txt --verbose=1
/usr/bin/x86_64-pc-linux-gnu-c++  -fPIC -pipe -O2 -march=x86-64 -mtune=generic -Wall -Wparentheses -Wno-long-long -Wno-import -pedantic -Wreturn-type -Wmissing-braces -Wunknown-pragmas -Wunused  -Wl,--as-needed -shared -Wl,-soname,libosgTerrain.so.130 -o ../../lib/libosgTerrain.so.3.4.0 CMakeFiles/osgTerrain.dir/DisplacementMappingTechnique.o CMakeFiles/osgTerrain.dir/Layer.o CMakeFiles/osgTerrain.dir/Locator.o CMakeFiles/osgTerrain.dir/TerrainTile.o CMakeFiles/osgTerrain.dir/TerrainTechnique.o CMakeFiles/osgTerrain.dir/Terrain.o CMakeFiles/osgTerrain.dir/GeometryTechnique.o CMakeFiles/osgTerrain.dir/GeometryPool.o CMakeFiles/osgTerrain.dir/Version.o ../../lib/libosgDB.so.3.4.0 -lGL ../../lib/libosgUtil.so.3.4.0 ../../lib/libosg.so.3.4.0 -lm -lrt ../../lib/libOpenThreads.so.3.3.0 -lpthread -ldl -lz -lGL -Wl,-rpath,/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/build/lib: 
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp: In function 'void osgDBJPEG::jpeg_istream_src(j_decompress_ptr, std::istream*)':
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:252:32: error: invalid conversion from 'osgDBJPEG::boolean (*)(j_decompress_ptr) {aka int (*)(jpeg_decompress_struct*)}' to 'boolean (*)(j_decompress_ptr) {aka boolean (*)(jpeg_decompress_struct*)}' [-fpermissive]
     src->pub.fill_input_buffer = fill_input_buffer;
                                ^
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp: In function 'void osgDBJPEG::jpeg_stream_dest(j_compress_ptr, std::ostream*)':
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:381:35: error: invalid conversion from 'osgDBJPEG::boolean (*)(j_compress_ptr) {aka int (*)(jpeg_compress_struct*)}' to 'boolean (*)(j_compress_ptr) {aka boolean (*)(jpeg_compress_struct*)}' [-fpermissive]
     dest->pub.empty_output_buffer = empty_output_buffer;
                                   ^
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp: In function 'unsigned char* osgDBJPEG::simage_jpeg_load(std::istream&, int*, int*, int*, unsigned int*)':
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:539:41: error: invalid conversion from 'int' to 'boolean' [-fpermissive]
     (void) jpeg_read_header(&cinfo, TRUE);
                                         ^
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp: In member function 'osgDB::ReaderWriter::WriteResult::WriteStatus ReaderWriterJPEG::write_JPEG_file(std::ostream&, const osg::Image&, int) const':
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:761:87: error: invalid conversion from 'int' to 'boolean' [-fpermissive]
    jpeg_set_quality(&cinfo, quality, TRUE /* limit to baseline-JPEG values */);
                                                                              ^
/var/tmp/paludis/build/dev-games-OpenSceneGraph-3.4.0/work/OpenSceneGraph-3.4.0/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp:768:45: error: invalid conversion from 'int' to 'boolean' [-fpermissive]
             jpeg_start_compress(&cinfo, TRUE);

[openscenegraph]

The OSG has been building fine for most users without -fpermissive, no such problems have been reported by the community in any releases. There must be something specific about your system/dependencies that is different from most users. You don't provide any information on this so can not comment. The best place to discuss this is on the osg-users mailing list/forum as others in the community will be able to chip in.

I am closing this issue as it's not a problem with the OSG itself, and with your specific system you can simply add --permissive and get things to build.

[hasufell]

I am closing this issue as it's not a problem with the OSG itself

That's a bit vague. Are you saying no one gets this warning or that this warning is simply not fatal with your compiler?

[openscenegraph]

You are the only person I've come across to report this issue. The issue looks to be specific to your system, my best guess would be something about your 3rd party dependencies.

Personally, I develop with gcc+linux for over a decade and have never seen this issue with any version of the OSG, or the various versions of compilers, OS's and dependencies. When I make release I do extensive calls for testing. If there was a general issue we'd have seen it long ago.

There isn't a general problem, there is specific problem on your particular system that you can easily get around.

If you want to discuss further the right place is on the osg-users mailing list/forum as this way may other eye balls can spot the discussion and add their own insights. It might be that there is something we can tweak to the OSG to fix the issue on your system. Addressing this is something for general discussion though.

[hasufell]

You don't seem to be interested in investigating this issue. Most of your "arguments" are non-technical or just guessing. As someone who has developed with gcc+linux over a decade, you should know that these kind of things can heavily depend on the compiler and compiler version and can go unnoticed for well... a whole decade.

But thanks anyway.

[hasufell]

So I looked at it and it is indeed a bug in OpenSceneGraph.

Look at https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp#L73 which does

/* Some versions of jmorecfg.h define boolean, some don't...
   Those that do also define HAVE_BOOLEAN, so we can guard using that. */
#ifndef HAVE_BOOLEAN
  typedef int boolean;
  #define FALSE 0
  #define TRUE 1
#endif

Now, the unpatched jpeg9b does this in jmorecfg.h

/*
 * On a few systems, type boolean and/or its values FALSE, TRUE may appear
 * in standard header files.  Or you may have conflicts with application-
 * specific header files that you want to include together with these files.
 * Defining HAVE_BOOLEAN before including jpeglib.h should make it work.
 */

#ifndef HAVE_BOOLEAN
#if defined FALSE || defined TRUE || defined QGLOBAL_H
/* Qt3 defines FALSE and TRUE as "const" variables in qglobal.h */
typedef int boolean;
#ifndef FALSE           /* in case these macros already exist */
#define FALSE   0       /* values of boolean */
#endif
#ifndef TRUE
#define TRUE    1
#endif
#else
typedef enum { FALSE = 0, TRUE = 1 } boolean;
#endif
#endif

...without defining HAVE_BOOLEAN, so the assumption made in https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgPlugins/jpeg/ReaderWriterJPEG.cpp#L74 is wrong (that only happens for _WIN32).

Also see this mail from jpeg developer Guido Vollbeding who says:

In version 9 we changed to a more reliable definition of the 'boolean' type (in file jmorecfg.h). This may cause conflicts with applications which do not comply with the specified application programming interface

It seems OpenSceneGraph either relies on jpeg-turbo (which doesn't have this problem) or hacked header files (which some distributions do).

However, it's a fact that your software does not compile with the latest unpatched jpeg9b in case boolean ends up being the enum above. It's pretty simple to reproduce.

[hasufell]

Is this how you treat contributors? I even did all the work for you, figuring out why exactly it fails.

[damiandixon]

Having just attempted to build with the latest ijpeg on CentOS 7 I bumped into this problem. The fix was to comment out the HAVE_BOOLEAN and associated code. Ideally the fix should be to check the actual version of ijpeg and deal with the change in behaviour of ijpeg.

[steva44]

I have the same problem as well... though it only happens when compiling on OSX (I'm using XCODE w/clang). On my windows machine it compiles fine. I solved it like damiandixon did by commenting out everything below in readerwriterjpeg.cpp:

ifndef HAVE_BOOLEAN

typedef int boolean;

define FALSE 0

define TRUE 1

endif

[hasufell]

Ideally the fix should be to check the actual version of ijpeg and deal with the change in behaviour of ijpeg.

Well, as you can see from the backlog, upstream irrationally doesn't believe this is a bug in OpenSceneGraph code, although there is hard evidence for it. So we'll have to patch it downstream.

[SwishSwushPow]

I had the same problem and steva44s workaround helped me to get it running on macOS. Thanks hasufell for opening this issue and bringing attention to it! (macOS El Capitan, ogs 3.4.0)

[kunlin596]

@hasufell Thank you for pointing out the error, I ran into this problem too. I imported the source into my ide and the intellisense told me that the function pointer type did not matched.

#ifndef HAVE_BOOLEAN
    typedef int boolean;
    #define FALSE 0
    #define TRUE 1
#endif

mixed bool and int, which made the function pointer type do not match.

I simply commented all the part and the compiler stopped compiling. On macOS Sierra.

[mkae]

Same for me in El Capitan when building the MacPorts-based OSG.

[openscenegraph]

Guys, I closed this Issue because the evidence originally pointed to a build or 3rd party dependency specific issue and asked to move discussions to the osg-users mailing list/forum for further discussion. I know from 15 years experience of managing an open source project this is by far the best way to resolve platform specific issues as getting as many eye balls on the issues increases the chances of patterns and final resolution of these issues. This advice was ignored by the original poster, One shouldn't be surprised that I ignore a closed issue, as well it's CLOSED and the poster told to raise the issue in the public forum.

Another generally note, a build issue due to a change in a 3rd party dependency is not a bug. It's just something that happens from time to time when software is successful enough to have a long lifetime. The OSG has over a hundred plugins and dozen dependencies for these plugins. Not being fully compatible with future versions of 3rd party dependencies is an inevitable fact of software engineers life, it's just silly to equate this as a bug, as we'd have to classify almost all software as buggy, just something it depends upon in the future might change in an incompatible way.

A bug is an error in the code that leads to undesired runtime behaviour.

As a code fix for the lack of compatibility between the OSG's plugin and recent jpeg headers it's not clear what the ideal solution is a the whole boolearn handling jpeg has been a mess and still is a mess, keeping code compiling against a full range of jpeg versions that OSG users might compile the OSG against will require some version specific hacks. The best workaround I could see is to adda #if JPEG_LIB_VERSION < 90. I have committed this workaround to OSG master the 3.4 branch.

[hasufell]

Guys, I closed this Issue because the evidence originally pointed to a build or 3rd party dependency specific issue and asked to move discussions to the osg-users mailing list/forum for further discussion.

And then you ignored the evidence that it is a bug in OSG due to incorrect use of API (see the quote from jpeg developer) for more than a year.

I know from 15 years experience

Your experience is not a techical argument.

This advice was ignored by the original poster, One shouldn't be surprised that I ignore a closed issue, as well it's CLOSED and the poster told to raise the issue in the public forum.

Code bugs belong to the issue tracker. Not just me, but several other people are surprised that you ignore valid bug reports.

As a code fix for the lack of compatibility between the OSG's plugin and recent jpeg headers it's not clear what the ideal solution is a the whole boolearn handling jpeg has been a mess and still is a mess

Guess what. I could probably have provided a proper fix, not just another hack. But I don't want to contribute to your project, for obvious reasons. Maybe you should think about that, no?

[hongkai-dai]

I run in to the same problem on Ubuntu 16.04, with openscenegraph SHA ed9c28b. The compilation problem is fixed by following @damiandixon 's solution.

[openscenegraph]

Long lived software has to put up with lots of issues, be it with users that can't see that issues are wider than their own perspective or how best to tackle them, or actual engineering issues because hardware, operating systems, build tools and 3rd party APIs change.

Retaining backwards compatibility with older versions of 3rd party dependencies isn't incorrect use of API, not being compatibility with changes in 3rd party dependencies that happen after software is release isn't a bug in that software, we aren't time travellers, we are engineers do what is best at any point in time. Software evolves.

@hongkai-dai, I have Kubuntu 16.04 as my main dev system and it's working just fine with both master and OpenSceneGraph-3,4 branch. It worked fine before even I mad fixes to the jpeg plugin. If you are having a problem then you need to post a proper report to osg-users mailing list/forum so we can explore what is going on.

As I said earlier in this thread, the best way to sort out issues like this is not on an annexe of the issue tracker that very few users will see, but on the osg-users mailing list/forum. Testing against a wide range of 3rd party dependencies requires as wide range of testers as you can get. The github issue tracker is very poor for this, which is why I keep trying to push discussion over to the best medium for resolving these issues - the osg-users mailng list/forum.

[a17r]

This is still an issue and the fix explained above unbreaks build.

FTR, the version of libjpeg (the JPEG reference) this fails to build against is jpeg-9c and it was released in 2018-01-14.

Correction: Need to test commit 34b4e7001522c1b47b4211dac34d2d6a6b994a6f from 3.5.9.

Confirmed fixed! Thanks.