Problem compiling C++ program on Humax

[af123]

Apologies - it doesn't work when compiled on my dev system either. I was running the wrong binary : oops
Works better when cross compiled though...

 

[Black Hole]

What's so special about programming in C++? What's wrong with just plain C?

C is procedural and C++ is object-oriented. The latter means it is much easier to write black-boxes which you can test and debug in isolation and then plug together with other black-boxes, assuming you've got the interface design right between them.

I think I have just had a light-bulb moment.

I was thinking about the general principles of how multiple disparate developers could contribute code modules to FreeCAD - as a child of the procedural code age, where you write loops to scan for input and then invoke routines to handle the input and then do something as a result of it, the likes of FreeCAD where the primary input is a mouse click is simply mind boggling, and one could not just add some more code to it willy-nilly. Every mod would have to be woven into the rest.

Take for example adding a tool to the tool bar which enables the creation of a b-spline curve in a sketch. First you need an icon added it the tool bar and an equivalent item on the edit menu. Then you need to interpret the mouse movement and clicks so that when the tool is active visual feedback is provided to the user, and then the parameters for the created curve need to be stored in the design file and presented on screen (pre-mod, the software doesn't know how to interpret a b-spline in the design file). When the sketch is then rendered into a solid by extrusion or revolution, the existing mesh generator needs to be told how to calculate the coordinates of the mesh nodes for those elements that are controlled by the b-spline (and it doesn't know how to do that).

Correct me if I'm wrong, but I think the business of reacting to mouse movement and clicks etc is handled by using a "visual" language so that everything is event-driven, and the management of events is off-loaded to the operating system.

Object orientation comes in with the black boxes prpr mentioned. The language provides a standard interface so that, for example, the mesh generator doesn't need to know how to calculate b-splines - all it needs to know is the steps required to calculate the mesh, and the language's supervisory system passes the specific calculations required to render a b-spline to the b-spline module. Therefore, in order to add a b-spline function to the sketch editor, all that is needed is a list of procedure calls from the other modules that will need to be supported. I believe these are called "methods".

It strikes me that the language compiler must therefore be adding a huge amount of additional code to the executable that is not explicitly written by the programmer, but needs to exist as another level of "operating system" to support and manage the code that has been explicitly written. Hopefully the compiler is intelligent enough not to put in support for functions which are not required in any particular case!

Have I got that about right?

 

[prpr]

Broadly you seem to be on the right track. For language read application. Somebody has to code this stuff in the first place, although there are vast libraries of stuff pre-written that you can tap into.
Method is just a fancy name for function. Encapsulation, abstraction, inheritance and polymorphism are 4 words you will see all over anything to do with C++ (or any other OO language, seeing as the principles are the same). These concepts allow you to black-box things and provide a standard interface so the outer calling layer doesn't need to know any of the implementation details. Don't have time to go into it further and it's all out there anyway, written better than I can explain it...

 

[MymsMan]

Comparing the configuration details on the on-box compiler and the cross-compiler there are a number of differences;

Cross compiler:
Using built-in specs.
Target: mipsel-linux-uclibc
Configured with: ../gcc-4.2.0-20070124/configure --prefix=/opt/toolchains/crosstools_hf-linux-2.6.18.0_gcc-4.2-11ts_uclibc-nptl-0.9.29-20070423_20090508/ --build=mipsel-linux --host=mipsel-linux --target=mipsel-linux-uclibc --with-build-sysroot=/usr/src/redhat/BUILD/build_uClibc --enable-languages=c,c++ --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --with-float=hard --enable-threads --infodir=/opt/toolchains/crosstools_hf-linux-2.6.18.0_gcc-4.2-11ts_uclibc-nptl-0.9.29-20070423_20090508/info --mandir=/opt/toolchains/crosstools_hf-linux-2.6.18.0_gcc-4.2-11ts_uclibc-nptl-0.9.29-20070423_20090508/man --with-arch=mips32 --disable-libmudflap --disable-nls --with-gnu-plts
Thread model: posix
gcc version 4.2.0 20070124 (prerelease) - BRCM 11ts-20090508

Humax# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/mnt/hd2/mod/bin/../libexec/gcc/mipsel-unknown-linux-uclibc/4.5.2/lto-wrapper
Target: mipsel-unknown-linux-uclibc
Configured with: ./configure --prefix=/mod --build=i686-pc-linux-gnu --host=mipsel-unknown-linux-uclibc --target=mipsel-unknown-linux-uclibc --with-float=soft --with-abi=32 --with-tune=mips32 --enable-languages=c,c++ --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-libssp --disable-multilib --disable-tls --enable-shared --disable-nls --enable-threads --disable-decimal-float
Thread model: posix
gcc version 4.5.2 (GCC)

The most significant and relevant would appear to be the --with-float=hard on the working cross compiler, and --with-float=soft on the Humax box compiler

Whilst the software floating point should work it would be better to use builtin hardware floating point when available

Using the compiler option -mhard-float appears to work but generates warning message

Humax# c++ -o /mod/webif/plugin/detectads/silence  -Wall -std=c++0x -g  -lsndfile  /mod/webif/plugin/detectads/silence.cpp -mhard-float
/mnt/hd2/mod/bin/../lib/gcc/mipsel-unknown-linux-uclibc/4.5.2/../../../../mipsel-unknown-linux-uclibc/bin/ld: Warning: /tmp/ccBfpwbQ.o uses hard float, /mod/webif/plugin/detectads/silence uses soft float

I haven't investigated what other options it would take to remove the warning messages or change the compiler configuration

 

[prpr]

Does the "-mhard-float" need to go before the .cpp file?
I think you would do better trying this on your test case before anything else.

 

[kev7378]

The "problem" with functions like rint() and lrint() is that their behaviour is dependant on the current rounding mode of the floating point library. I think I would conclude from what I see above (yes; I did also compile and run it on several platforms) that the compiler/run-times defaults on the Humax (embedded) are different from those on its bigger Intel based desktop/server cousins. It could also be an implementation issue (something not implemented in software/hardware).

Unfortunately I also just discovered that the functions we would expect to use to easily find out what the current mode is appear to be missing in the Humax environment. See here: http://www.gnu.org/software/libc/manual/html_node/Rounding.html

Sorry: I haven't got time at the moment to look into this any further; but I hope the above observation is correct and helpful. One fudged-fix might be to #define DIY replacements, assuming you get to include that in the code you are compiling. For example: "#define rint(X) something" will normally replace further use of rint() as a function within a source module with "something"; where, in this case, the "something" will need to be code that implements the behaviour of rint() that you desire.