5

I have shared code given to me that compiles on one linux system but not a newer system. The error is uint32_t does not name a type. I realize that this is often fixed by including the <cstdint> or stdint.h. The source code has neither of these includes and I am trying to seek an option that doesn't require modifying due to internal business practices that I can't control. Since it compiles as is on one machine they don't want changes to the source code.

I am not sure if it matters but the older system uses gcc 4.1 while the newer one uses gcc 4.4. I could install different versions of gcc if needed, or add/install library/include files on the newer machine, I have full control of what is on that machine.

What are my options for trying to compile this code on my machine without modifying the source? I can provide other details if needed.

Pete Becker
  • 74,985
  • 8
  • 76
  • 165
Michael
  • 1,321
  • 1
  • 13
  • 27
  • 4
    So they, in fact, don't want the code to be correct? Quite stupid IMHO. – alain Nov 17 '16 at 20:01
  • 1
    They don't want to fix the code so it will compile with a newer compiler? Then they should stick to using the setup they know to work (assuming anyone knows it well enough to reproduce it). – UnholySheep Nov 17 '16 at 20:02
  • Alain, I know and agree. I doubt this is the first time a company makes a stupid decision but I have to work around it. – Michael Nov 17 '16 at 20:02
  • Definitely not the first time... Maybe you can add an include as a command line option: [-include file](https://gcc.gnu.org/onlinedocs/gcc-3.0/gcc_3.html#SEC14) – alain Nov 17 '16 at 20:04
  • 4
    I looked for the [porting guide for GCC 4.4](https://gcc.gnu.org/gcc-4.4/porting_to.html): *[...] used `uint32_t` without including will no longer compile.* (Section **C++ language issues - Header dependency changes**) – UnholySheep Nov 17 '16 at 20:05
  • UnholySHeep, that porting guide helps a lot, I can use 4.3. It also gives solid documentation on the need to update the code. Thanks. – Michael Nov 17 '16 at 20:09
  • 2
    The code is **broken**. The fact that is *used* to compile is irrelevant to that fact. – Andrew Henle Nov 17 '16 at 20:10

4 Answers4

4

I am not sure if it matters but the older system uses gcc 4.1 while the newer one uses gcc 4.4

GCC stopped including <stdint.h> some time ago. You now have to include something to get it...

I realize that this is often fixed by including the <cstdint> or stdint.h. The source code has neither of these includes and I am trying to seek an option that doesn't require modifying due to internal business practices that I can't control...

I hope I am not splitting hairs... If you can't modify the source files, then are you allowed to modify the build system or configuration files; or the environment? If so, you can use a force include to insert the file. See Include header files using command line option?

You can modify Makefile to force include stdint.h. If the build system honors CFLAGS or CXXFLAGS, then you can force include it in the flags. You last choice is probably to do something like export CC="gcc -include stdint.h".

The reason I am splitting hairs is OpenSSL and FIPS. The OpenSSL source files for the FIPS Object Module are sequestered and cannot be modified. We have to fallback to modifying supporting scripts and the environment to get some things working as expected.

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885
2

If you really don't want to amend the file you could wrap it. Suppose it's called src.c create a new file src1.c:

#include <stdint.h>
#include "src.c"

And then compile src1.c.

PS: The problem may arise because compilers include other headers in their header files. This can mean some symbols 'officially' defined in other headers are quietly defined when you include a header that isn't specified as including it.

It's an error to write a program relying on a symbol for which the appropriate header hasn't been included - but it's easy to do and difficult to spot.

A changing compiler or version sometimes reveals these quiet issues.

Persixty
  • 8,165
  • 2
  • 13
  • 35
0

Unfortunately, you can't force your code to work on a newer compiler without modifying something.

If you are allowed to modify the build script and add source files to the project, you might be able to add another source file to the project which, in turn, includes your affected file and headers it really needs. Remove the affected source files from the build, add the new ones, and rebuild.

If your shared source is using macro magic (e.g. an #include SOME_MACRO, where SOME_MACRO can be defined on the command line), you might be able to get away with modifying build options (to define that macro for every compilation of each file). Apart from relying on modifying the build process, it also relies on a possible-but-less-than-usual usage of macros in your project.

It may be possible to modify the standard headers in your compiler/library installation - assuming you have sufficient access (administrative) to do so. The problem with this is that the problem will almost certainly re-emerge whenever an update/patch to the compiler/library is installed. Over time, this approach will lock the code into relying on an older and older compiler/library that has been superseded - no ability to benefit from compiler bug fixes, evolution of standards, etc. This also severely limits your ability to share the code, and ability of others to use it - anyone who receives the code needs to modify their compiler/library installation.

The basic fact, however, is that your shared code relies on a particular implementation (compiler/library) that exhibits non-standard behaviour. Hence it has failed with an update of that implementation - which removed those non-standard occurrences - it is likely to fail with other implementations (porting to different compilers in future, etc). The real technical solution is to modify the source, and #include needed headers correctly. The real business solution is to make a business case justifying the need for such modifications, citing inefficiency - which will grow over time - in terms of cost and effort needed to maintain the shared code whenever it needs to be ported, or whenever a compiler is updated.

Peter
  • 35,646
  • 4
  • 32
  • 74
-2

look at the second last line of code above your error, you'll find everything above that terminates with a , and only use a ; on the last entery

barry
  • 1