uint32_tはタイプに名前をつけません

Question

私は私に与えられたコードを共有していますが、これは1つのLinuxシステムでコンパイルされますが、新しいシステムではコンパイルされません。エラーは、uint32_tはタイプの名前ではありません。これは多くの場合、<cstdint>またはstdint.hを含めることで修正されています。ソースコードにはこれらのものは含まれていません。私は制御できない内部的なビジネスプラクティスのために変更を必要としないオプションを求めようとしています。 1つのマシン上にあるようにコンパイルするので、ソースコードを変更する必要はありません。

古いシステムではgcc 4.1が使用され、新しいシステムではgcc 4.4が使用されているかどうかはわかりません。必要に応じて別のバージョンのgccをインストールすることもできますし、ライブラリ/インクルードファイルを新しいマシンに追加/インストールすることもできます。

ソースを変更せずにマシン上でこのコードをコンパイルしようとする私の選択肢は何ですか？必要に応じて他の詳細を提供することができます。

Answer 1

本当に愚かですが、ファイルを修正したくない場合は、それをラップすることができます。

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

そしてsrc1.c.をコンパイルします。それはsrc.c新しいファイルsrc1.cを作成すると呼ばれていたと

Answer 2

私はそれが重要なのかどうかわからないのですが、新規の方は

のgcc 4.4

を使用しながら、古いシステムはGCC 4.1を使用してGCCは、いくつかの時間前 <stdint.h>含めて停止しました。あなたは今、私はこれはしばしば <cstdint>または stdint.h含めることによって固定されていることを実感

...それを得るために何かを含める必要があります。ソースコードには含まれていないものがあり、私が制御できない内部的なビジネスプラクティスのために変更を必要としないオプションを探しています...

私は分割しないでください。 ..ソースファイルを変更できない場合は、ビルドシステムファイルまたは設定ファイルを変更することができますか？または環境ですか？その場合は、ファイルincludeを挿入するためにforceインクルードを使用できます。 Include header files using command line option?

Makefileを強制的に変更して、stdint.hを含めることができます。ビルドシステムがCFLAGSまたはCXXFLAGSの場合、強制的にフラグに含めることができます。最後の選択は、おそらくexport CC="gcc -include stdint.h"のようなものを行うことです。

私が髪を分ける理由は、OpenSSLとFIPSです。 FIPSオブジェクトモジュール用のOpenSSLソースファイルは隔離されており、変更することはできません。私たちは、サポートスクリプトや環境を変更して、期待どおりに動作するようにする必要があります。

Answer 3

残念ながら、あなたのコードを変更せずに新しいコンパイラで動作させることはできません。

ビルドスクリプトを変更してプロジェクトにソースファイルを追加することができれば、別のソースファイルをプロジェクトに追加することができます。プロジェクトには、影響を受けるファイルと実際に必要なヘッダーが含まれます。影響を受けるソースファイルをビルドから削除し、新しいソースファイルを追加して再構築します。

共有ソースがマクロマジックを使用している場合（例：#include SOME_MACRO、SOME_MACROをコマンドラインで定義することができます）、ビルドオプションの変更（各ファイルのコンパイルごとにそのマクロを定義する）を手放すことができます。ビルドプロセスの変更に頼ることとは別に、プロジェクト内のマクロの使用頻度は通常より少なくても可能です。

コンパイラ/ライブラリのインストールで標準ヘッダーを変更することができます。これには、十分なアクセス権（管理）があることが前提です。この問題は、コンパイラ/ライブラリへの更新/パッチがインストールされるたびに問題がほぼ確実に再現されることです。時間の経過とともに、このアプローチは、コンパイラのバグ修正、標準の進化などの恩恵を受けることができない古いコンパイラ/ライブラリに依存するようにコードをロックします。これにより、コードを共有する能力が大幅に制限され、コードを受け取った人は誰でもコンパイラ/ライブラリのインストールを変更する必要があります。

ただし、共有コードは非標準的な動作を示す特定の実装（コンパイラ/ライブラリ）に依存しています。したがって、その実装を更新することで失敗しました。これは非標準的な出来事を取り除きました。他の実装（将来、別のコンパイラへの移植など）で失敗する可能性があります。実際の技術的な解決策は、ソースを変更することであり、#includeは必要なヘッダーが正しくあります。実際のビジネスの解決策は、移植の必要があるときに共有コードを維持するために必要なコストと労力の点で、時間の経過とともに非効率性が増大するという非効率性を挙げて、こうした変更の必要性を正当化するビジネスケースを作ることです。コンパイラが更新されます。