初日

いくつかのエラーが発生し、いくつかの競合があり、ビルドが失敗しました。だから私は接続の過程で致命的なエラーを引き起こす.oファイルを作成することは不可能だと思います。誰でも段階的なトラブルシューティングのヒントを得ることができますか？

Red Hat 6を新しくインストールしてこれを正常に実行したので、誰かがカーネルを更新しましたが、カーネルライブラリは更新していないようです。どこで確認する必要があるかについてのヒントが必要です

入って rpm -qaみると2つのコアがあることがわかりました。以前のコアで起動してLiSをコンパイルしようとしましたが、役に立ちませんでした。

私は次のように私の問題を分析します。

1. カーネルライブラリとカーネルのバージョンが一致するかどうかを確認するには？
   アイデア：dlevel、カーネル、gcc、glib、glibc...
2. ビルドの問題を解決するためのチェックリストなどの一般的な手順はありますか？だから一つずつ確認してください。 LiSのインストールは、複数のライブラリの最小レベルの要件を提供するため、すべての要件を満たしていると確信しており、パッチを通過したようです。
3. ファイルのバージョンを下げることはできますか？それでは、各ライブラリが要件を満たすようにすることができますか？そして100％互換性があります。

2日目進行

@schaibaのいくつかのヒントに従って、コンパイル中にロギングを実行する方法を見てきました。

そして、ビルドパッケージを入力し、2番目のフォルダでビルドstrconfを追跡し、ccコンパイルに--verboseを追加した後、次のメッセージを受け取りました。
競合するライブラリを無視します /usr/lib64/libc.so。小さなファイルなのでviで開こうとしました。したがって、同様の文が含まれているテキストファイルであることがわかりましたOUTPUT FORMAT (elf32-i386)。 lib64はx86_64でなければならないので、これは明らかに間違っています。
その後、私はlibc.soがどこから来るのかを確認することにしました。

rpm -qf libc.so  

それがglibc-devel-....にあることがわかりました。私はRed Hat 6.4リポジトリを持っていて、今やっています。

yum update glibc-devel

これにより、いたずらlibc.soはOUTPUT FORMAT(elf64-x86-64)strconfモジュールのコンパイルになります。ビルドが完了しました。

しかし、もう別の質問がありました。まだクラッシュするlibc.so警告は無視されており、私が構築したLiSは実際に他のアプリケーションで使用されていますが、そのアプリケーションにはいくつかの問題があるようです。

どんな提案がありますか？

インターネットに関する別の調査によると、LiSパッケージは32ビットの基本であるため、32ビットでコンパイルする必要があるコード部分がある可能性があるため、2つの新しい質問が発生します。

1. 同じライブラリの両方のバージョンを使用できるようにビルドファイルをどのように変更しますか？

2. Linuxシステムで2つのバージョンの開発を共存させる方法はありますか？より正確には、/usr/lib64/libc.soの2つのバージョンです。