問題タブ [libstdc++]

OS X ボックスに gcc 4.6.1 を正常にビルドしてインストールしましたが、fat/universal libstdc++ ライブラリを作成するようにはできません。どうすればそれを行うことができますか？

デフォルトの /usr/lib/libstdc++.6.dylib は、次のアーキテクチャをサポートしています。

gcc に同じアーキテクチャ用の /usr/local/lib/libstdc++.6.dylib を提供してもらいたいのですが、 or を使用する試みconfigureは--enable-multilib明らか--with-multilib-list=i386,ppc,x86_64に--enable-targets=all見当違いでした。どちらconfigureもmakeエラーを生成しませんが、生成されるのはこれだけです:

「sudo yum update」でシステムを更新しようとすると、次のエラーが発生します。

どのようにしてこの状態になったのかはわかりませんが、私が行ったことはすべて yum を介して行われたことは確かです。

そのライブラリに対して「yum list」が提供するものは次のとおりです。

i386 バージョンが .x86_64 バージョンとどのように異なるかに注目してください。それは本当に奇妙です。

CentOS 5.6 64 ビットを実行しています。

私は何をすべきか？

Free Pascal /C++プロジェクトが混在しています。i386、FPC2.4.4上のDebian 5.0（ "Lenny"）。プログラムを実行すると、最初のcout<<呼び出しでクラッシュします。おかしなことに、それはしばらくの間機能していました。いくつかのOSアップデートはおそらくそれを壊しました。分離された問題は次のとおりです。

p.pas：

c.cpp：

Makefile：

作成、実行、セグメンテーション違反。まったく新しいDebianVMを試してみました-同じ結果です。

クラッシュはbasic_fstream::セントリー::sentry（）内で発生します。cout彼らは、このクラッシュの場所は、初期化されていないグローバルオブジェクトと一致していると主張しています。これは奇妙なinitcことです。Pascal側から使用すると、グローバルC++変数が確実に初期化されると思いました。

何かアイデアはありますか？どういうわけか、リンクしているlibstdc ++のバージョン（libstdc ++。so.6.0.10）でしょうか？

編集：それはますます奇妙になります。pCentOS 5.3ボックスで同じバイナリ（）を実行します-宣伝どおりに機能します。おそらくそれは共有ライブラリバージョンに関するものです...私はさまざまなLinucesに関するいくつかの統計を収集しに行きます。

EDIT2：私が気づいたことの1つ：ldd pDebianボックスで行うと、次のようになります。

そして、それが機能するCentOSボックスで同じことをすると：

i686/cmovしたがって、すべてのCライブラリ（C ++ライブラリだけでなく）はディレクトリから取得されます。Debianマシンにもがあり/lib/libc.so.6、のマシンとは異なりcmovます。cmovそのディレクトリとの取引は何ですか？そして、なぜ同じ名前のlibcの2つの異なるコピーがあるのでしょうか。

編集：CentOSでも、グローバルコンストラクターは呼び出されません-アドホックグローバルオブジェクトでテストされただけです。何らかの理由でsentry（）でクラッシュすることはありません。結局、これはFPCの問題のようです。この動作に関するバグレポートがFPCにあります。

私が間違っていない限り、次の方法で std:array を作成できるはずです。

それでも、GCC 4.6.1 を使用すると、これらのいずれも動作させることができません。コンパイラは単に次のように言っています。

それでも、初期化リストは std::vector で問題なく機能します。それで、それはどれですか？std::array が初期化リストを受け入れる必要があると思うのは間違っていますか、それとも GNU 標準 C++ ライブラリ チームは間抜けですか?

std::thread新しい c++11インターフェイスを使用する際に問題が発生しました。スレッドが実行する関数へ
の参照を渡す方法がわかりません。std::ostream

整数を渡す例を次に示します (コンパイルして、gcc 4.6 で期待どおりに動作します)。

しかし、ostream を渡そうとすると、コンパイルされません:

それを行う方法はありますか、それともまったく不可能ですか??

注意：コンパイルエラーから、削除されたコンストラクターから来ているようです...

JProfiler には libstdc++ と libexpat がライブラリ フォルダーに含まれていることがわかります。また、agent(libjprofilerti) が後で読み込まれるため、標準ロケーション ライブラリが最初に読み込まれます。

ldd -v は、パッケージ化されているライブラリに依存していると述べています。

これらのライブラリが含まれているのはなぜですか?

std::vector<uint_32> a, b;同じサイズであることがわかっている 2 つのベクトルがあるとします。

とbitwise-ANDのすべてのメンバー間で実行し、結果を に入れるための C++11 パラダイムはありますか?abstd::vector<uint_32> c;

Fedora のデフォルトの C++ 標準ライブラリ (4.6.2) で clang を使用して小さな C++ プログラムをコンパイルしようとしています。Clang自体は問題なくコンパイルされ、テストプログラムのみを使用してコンパイルおよび実行されます。

私の他のプログラムは、clang が不平を言うロープを使用しています。

/usr/lib/gcc/x86_64-redhat-linux/4.6.2/../../../../include/c++/4.6.2/ext/ropeimpl.h:433:2: エラー: 使用未宣言の識別子 '_Data_allocate' _Data_allocate(_S_rounded_up_size(__old_len + __len));

このエラー メッセージについては、clang に対してバグが報告されており、clang は正しく、ライブラリ コードが無効であるという解決策がとられました。

Clangはここで正しいです。_Data_allocate の呼び出しには型依存の引数がないため、テンプレートの定義時に名前の検索が失敗します。

失敗したコードのコンテキスト:

私の質問は、このコードが有効でない場合、簡単な回避策はありますか? g++ はこれを正常にコンパイルします。

Java Native Interface (JNI) は C++ ABI の互換性の問題の影響を受けますか?

私はJavaアプリケーションを開発しています。Java Native Interface (JNI) を使用して C++ ライブラリの関数を呼び出したいと考えています。C++ ライブラリのコードにアクセスできるので、必要に応じて再構築できます。(たとえば、C++ ランタイムを静的にリンクできます。)

ユーザーに JRE 6 以上を要求することはできますが、特定の C++ ランタイムを要求することはできません。

同僚がこのブログ記事を指摘してくれました: http://www.trilithium.com/johan/2005/06/static-libstdc/動的にロードされた C++ コードを使用しないようにアドバイスしています。

別の同僚がこのバグ レポートを指摘してくれました: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590には、これらの問題が Java 1.4.2 でどのように対処されたかが詳しく説明されています。

問題の要点は、私が理解しているように、libstdc++ のバイナリ インターフェイスが頻繁に変更されることです。C++ アプリケーションが別のコンパイラでビルドされた C++ 共有ライブラリをロードすると、互換性のない 2 つの libstdc++ ライブラリが同時にメモリにロードされます。

バグ レポートでは、Java 1.4.2 の解決策について説明しています。ネイティブ コードが C++ ランタイムを呼び出す必要がある場合、呼び出しは適切な libstdc++.so で解決されます。まだ 2 つの libstdc++.so が同時にロードされていますが、問題はありません。"

これについていくつか質問があります。

まず、OpenJDK はこのアプローチを採用し続けますか?

[編集: OpenJDK の build-dev メーリング リストでこの質問をしました。答えはイエスです。HotSpot は依然として libstdc++ を静的にリンクしていますが、明らかに「ほとんどの Linux ディストリビューションはこれにパッチを当てています」。別の開発者は、これにはパッチさえ必要ないと指摘しています:「STATIC_CXX=false を設定するだけで十分です (デフォルトは true)。」]

次に、この場合でも、互換性のない 2 つの libstdc++.so を同時にロードすることは本当に問題ないのでしょうか?

第三に、このアプローチ (JDK でシンボルを非表示にする) は、すべての互換性の問題に対処していますか?

上記のブログ記事では、「異なる ABI に対してコンパイルされたコードは、バイナリ互換性がない」と警告しています。そしてその後、「言語ランタイムのサポートは通常、共有されているデータに依存しています。たとえば、ある種のロックまたはグローバルデータ構造にアクセスするためです (C プログラムが共有 errno を必要とする方法と同様です)。」

これは、問題を解決できないように聞こえます。

もう一度言いますが、ABI の非互換性はもはや問題ではありません。ブログ記事は6年以上前のものです。別のスタックオーバーフローの質問 ( GCC ABI 互換性) に対する 1 つの回答は、「gcc-3.4.0 以降、ABI は前方互換性がある」と主張しています。それは成功しましたか？

これらの問題に関するガイダンスをいただければ幸いです。（そしてねえ、これをすべて読んでくれてありがとう！）

編集

私の質問はかなり長くなったので、すべての詳細を述べませんでした。ウィルのコメントに対処するには：

1. extern "C" 関数を呼び出すだけです。(たとえば、javah を使用して C ヘッダー ファイルを生成します。)
2. JVM で C++ ランタイムを操作する必要はありません。(基本的には、文字列を C++ ライブラリに送信する必要があるだけです。)

次の (おもちゃの) プログラムは、libstdc++ と libc++ に対してリンクすると、異なるものを返します。これは libc++ のバグですか、それとも istream eof() の仕組みがわかりませんか? -std=c++0x の有無にかかわらず、Linux および mac os x で g++ を使用し、mac os x で clang を使用して実行しようとしました。(get() などによる) 読み取りの試行が実際に失敗するまで、eof() は true を返さないというのが私の印象でした。これは libstdc++ の動作ですが、libc++ の動作ではありません。