Description of problem: While debugging an issue on a program of mine I came across what it appears like a packaging issue with gcc (though the issue could be in another package). As the trace further below shows, it is looking for file atomicity.h in directory 4.4.3 while I have installed version 4.4.4 of gcc. I _do_ have that particular file in 4.4.4. Version-Release number of selected component (if applicable): 4.4.4 How reproducible: Always (that is, until I fix the bug in my program!). Steps to Reproduce: 1. gdb my_program_name 2. run 3. make my program crash (by closing main program window, as there is a bug in my program) Actual results: It cannot find atomicity in directory 4.4.3. Expected results: It should not be looking for the file in that directory as I have 4.4.4. Additional info: Trace I got that shows issue: Program received signal SIGSEGV, Segmentation fault. 0x03c9ef06 in __exchange_and_add (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/ext/atomicity.h:46 46 /usr/include/c++/4.4.3/ext/atomicity.h: No such file or directory. in /usr/include/c++/4.4.3/ext/atomicity.h Missing separate debuginfos, use: debuginfo-install freetype-freeworld-2.3.11-2.fc13.i686 (gdb) backtrace #0 0x03c9ef06 in __exchange_and_add (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/ext/atomicity.h:46 #1 __exchange_and_add_dispatch (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/ext/atomicity.h:79 #2 _M_dispose (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/bits/basic_string.h:234 #3 ~basic_string (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/bits/basic_string.h:503 #4 Glib::ustring::~ustring (this=0x80592e0, __in_chrg=<value optimized out>) at ustring.cc:351 #5 0x0804abcc in ~Object (argc=1, argv=0xbffff414) at object.hpp:27 #6 _Destroy<Object> (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_construct.h:83 #7 __destroy<Object*> (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_construct.h:93 #8 _Destroy<Object*> (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_construct.h:116 #9 _Destroy<Object*, Object> (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_construct.h:142 #10 ~vector (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_vector.h:313 #11 main (argc=1, argv=0xbffff414) at main.cpp:239
Likely some object files were compiled with an older gcc.
Jakub, you were right. I downloaded, rebuilt and installed glibmm24-2.24.1-1.fc13.src.rpm and the warning about atomicity.h not being found disappeared. So the issue is really with the glibmm24-2.24.1-1.fc13.src.rpm package (not gcc). I think this is a very minor bug, but I am reassigning the package to glibmm and will let the glibmm maintainer decide about it.
Thanks for the report, but it's certainly not a glibmm package bug. GCC in stable Fedora releases is often updated to new bug fix releases and we're not going to rebuild most of the packages in an already-released distro just because of that.
It makes sense. Thanks.