[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #3 from Pierre Ossman --- And another odd case; gcc 5 complains about this: > const char *a; > a = NULL; but not: > const char *a = NULL; gcc 13 complains about neither, and clang about both.
[Bug c++/114573] -Wzero-as-null-pointer-constant complains on enum with explicit cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114573 --- Comment #2 from Pierre Ossman --- Indeed. It is part of an effort to have a more modern C++ style in TigerVNC. One item was preferring nullptr over NULL, and this issue became an obstacle there. Right now, we did a #pragma, but if there is a better workaround, then we are all ears.
[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #2 from Pierre Ossman --- Found another case that neither gcc 5, gcc 13, nor clang complain about for some odd reason: > assert(thing == NULL); All three complain about: > assert(thing == 0); Not sure what's going on here.
[Bug c++/114573] New: -Wzero-as-null-pointer-constant complains on enum with explicit cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114573
Bug ID: 114573
Summary: -Wzero-as-null-pointer-constant complains on enum with
explicit cast
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
g++ complains about the following code when -Wzero-as-null-pointer-constant is
given:
> enum { ZERO, ONE, TWO };
>
> extern int func(const char *a);
>
> void zeroenum()
> {
> func((const char*)ZERO);
> }
Oddly enough, it also gives the wrong location for the issue:
> nulls.cxx: In function ‘void zeroenum()’:
> nulls.cxx:8:1: warning: zero as null pointer constant
> [-Wzero-as-null-pointer-constant]
> 8 | }
> | ^
clang does not complain about this, neither does older versions of gcc (tested
with 5.5.0). So it's some form of regression.
The above example is a bit contrived, but this pattern is moderately common in
that an argument can be either a pointer or an integer. E.g. CopyFromParent in
libX11, or FLTK menus.
[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 --- Comment #1 from Pierre Ossman --- Hmm.. I found bug 77513, and r9-873. So I guess this is intentional? This makes the warning somewhat pointless. We want to make sure developers standardise on nullptr, both for style and since the behaviour of NULL is compiler dependent (if I'm understanding the C++ standard correctly). It's also annoying if there is not a consensus between clang and gcc here.
[Bug c++/114571] New: -Wzero-as-null-pointer-constant does not complain about NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114571 Bug ID: 114571 Summary: -Wzero-as-null-pointer-constant does not complain about NULL Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se Target Milestone: --- Created attachment 57857 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57857=edit Test case We are looking at bringing up the TigerVNC project to a more modern C++ style, and one thing was using nullptr instead of NULL. We were very glad when we found -Wzero-as-null-pointer-constant to help out with this. Unfortunately, it doesn't seem to do much for NULL in modern¹ gcc. It spots usage of "0", but not any "NULL". clang has no trouble finding both. I've attached a test case with some comments on the cases we've seen. ¹ gcc 5 spots some, but not all NULL
[Bug objc/108743] -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 --- Comment #5 from Pierre Ossman --- Could you consider adding -fconstant-cfstrings as an alias? It would make life easier for making build systems compiler agnostic.
[Bug objc/108743] -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 --- Comment #4 from Pierre Ossman --- I am indeed trying to compile for macOS. Specifically Qt5, which is designed with just Xcode in mind.
[Bug objc/108743] -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 --- Comment #2 from Pierre Ossman --- Great news. And that is the same thing as clang's -fconstant-cfstrings? Unfortunately, I couldn't see -mconstant-cfstrings in gcc's documentation, but I may be looking in the wrong place.
[Bug objc/108743] New: -fconstant-cfstrings not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743 Bug ID: 108743 Summary: -fconstant-cfstrings not supported Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se Target Milestone: --- Some programs designed for clang want this flag. I'm unsure exactly how important it is. The description sounds like it's just some optimization. To make things worse, it is mentioned in gcc's documentation even though it isn't supported.
[Bug target/52991] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Pierre Ossman ossman at cendio dot se changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #19 from Pierre Ossman ossman at cendio dot se --- This bug report is now over three years old. Any progress? I'm still seeing it in 5.1.0. Should the summary also be updated to reflect that this is a regression? And should the default be reverted until the code can be fixed?
[Bug middle-end/66587] New: -no_compact_unwind is dropped for -nodefaultlibs/-nostdlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587 Bug ID: 66587 Summary: -no_compact_unwind is dropped for -nodefaultlibs/-nostdlib Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se Target Milestone: --- As the summary states, you will get bitten by bug 41260 if you happen to specify -nodefaultlibs or -nostdlib as -no_compact_unwind is pulled in via %(link_gcc_c_sequence), which in turn is conditional on those first to flags. The comment in the code states that -no_compact_unwind is needed because of problems with libSystem. In that case it would make sense to tie it to where libSystem gets pulled in. However, reading bug 41260 and related links, I interpret things as being a problem in Apple's ld. Hence the flag should always be used as that linker is always assumed. I'm not sure what the best approach is to do that. I'm planning on trying to move it from LINK_GCC_C_SEQUENCE_SPEC to LINK_SPEC. (The same thing might affect the -no_pie magic, but I haven't found the justification for that code)
[Bug middle-end/66587] -no_compact_unwind is dropped for -nodefaultlibs/-nostdlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587 --- Comment #2 from Pierre Ossman ossman at cendio dot se --- Note that darwin12.h also exists on trunk that needs to be modified as well.
[Bug middle-end/66587] -no_compact_unwind is dropped for -nodefaultlibs/-nostdlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66587 --- Comment #1 from Pierre Ossman ossman at cendio dot se --- Created attachment 35802 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35802action=edit possible patch
[Bug plugins/66300] New: GCC_ENABLE_PLUGINS references undefined variables, breaking configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66300 Bug ID: 66300 Summary: GCC_ENABLE_PLUGINS references undefined variables, breaking configure Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se Target Milestone: --- The GCC_ENABLE_PLUGINS macro references the variables gcc_cv_nm and gcc_cv_objdump which will not be set outside of gcc/configure. This means that e.g. libcc1 doesn't configure properly when those variables are needed. I'm assuming this is because it was moved out of gcc/configure.ac, so I assume the fix is to move more stuff out of there. The error you get is: checking for exported symbols... /home/tltest/cenbuild/repo/rpmbuild/BUILD/gcc-5.1.0/libcc1/configure: line 14531: -T: command not found yes checking for -rdynamic... /home/tltest/cenbuild/repo/rpmbuild/BUILD/gcc-5.1.0/libcc1/configure: line 14541: -T: command not found
[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 --- Comment #9 from Pierre Ossman ossman at cendio dot se --- (In reply to Andreas Schwab from comment #5) linux/aio_abi.h was added in 2.5.32. https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/ ?id=ea5097be4e814a2a9457e60653052306295941e8 How can it be missing on RHEL 4 with 2.6.9 in that case?
[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955
Pierre Ossman ossman at cendio dot se changed:
What|Removed |Added
CC||ossman at cendio dot se
--- Comment #4 from Pierre Ossman ossman at cendio dot se ---
Unfortunately the git history doesn't go further back than 2.6.12 so I don't
know when aio_abi.h got added. But the code only needs the enum, so something
like this should work:
#include linux/version.h
/* aio_abi.h was added in 2.6.10 (FIXME: check this) */
#if LINUX_VERSION_CODE 132624
enum {
IOCB_CMD_PREAD = 0,
IOCB_CMD_PWRITE = 1,
IOCB_CMD_FSYNC = 2,
IOCB_CMD_FDSYNC = 3,
IOCB_CMD_NOOP = 6,
};
#else
#include_next linux/aio_abi.h
#endif
/* IOCB_CMD_PREADV/PWRITEV has been added in 2.6.19 */
#if LINUX_VERSION_CODE 132627
#define IOCB_CMD_PREADV 7
#define IOCB_CMD_PWRITEV 8
#endif
[Bug sanitizer/61955] libsanitizer fails to compile on RHEL4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61955 --- Comment #11 from Pierre Ossman ossman at cendio dot se --- Not really. :) I stumbled upon this trying to use 2.4 headers, so I honestly haven't tried 2.6.9, RHEL variant or otherwise.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #32 from Pierre Ossman ossman at cendio dot se --- (In reply to Jack Howarth from comment #31) You might check out the original posting on this issue... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html I believe that was one of the posts we found and what made us look at which unwind implementation was used. IMHO, the static linkage of -lgcc_eh is evil as it potentially breaks the requirement that only a single unwinder (always the system one) be used. I can understand that. But in that case why keep the gcc unwinder on OS X? If it doesn't work then including it is just an accident waiting to happen. I would suggest something along the lines of the attached patch.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #33 from Pierre Ossman ossman at cendio dot se --- Created attachment 35198 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35198action=edit Remove unwinder on OS X
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 --- Comment #30 from Pierre Ossman ossman at cendio dot se --- (In reply to Dominique d'Humieres from comment #29) I can reopen the PR, but I don't see the point: (1) I can reproduce the problem only on x86_64-apple-darwin10 with gcc version 4.4.7 (I get 'CAUGHT' for all the other revisions I have tested on powerpc-apple-darwin9, x86_64-apple-darwin10, and x86_64-apple-darwin14. I'm not sure what we're doing differently in that case. Are you sure you are using libgcc_s from your gcc and not getting the routines from libSystem? What if you statically link libstdc++ and libgcc_eh like we do? (2) You should be able to build 4.9 and 5.0 without any patch for x86_64-apple-darwin* and a few for powerpc-apple-darwin9 and 5.0. Sorry, my bad. It was other issues preventing us from moving our development platform to 4.9. We should be able to do a test build. Do you think anything has changed since 4.8.4 though? (3) Why are you not using a more recent version of OS X? We need to produce binaries that most people can run, and 10.6 seemed like a good cut-off for now. We did however see the same crashes running the binary on 10.10. We have not tested using a newer target for the gcc build though.
[Bug target/42159] unwinding issues on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159 Pierre Ossman ossman at cendio dot se changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #28 from Pierre Ossman ossman at cendio dot se --- I'd like to reopen this issue as we are still seeing this with as new gcc as 4.8.4 (we've been unable to build anything newer). Unfortunately I do not seem to have the access rights to reopen the bug. Help? We've primarily been using 4.6.4 but we also did a test build with 4.8.4 to see if a newer gcc solved the issue. Unfortunately the problem is the same, with the same stack trace. We have however found that the problem seems to be an incompatibility between OS X's unwinder and gcc's (something we found various other gcc bugs and mailing lists discussions on). Or normal way of doing things is to statically link libstdc++ and libgcc_eh. This results in crashing programs. If we inject libSystem before libgcc_eh however, we get the system unwind routines and the program works fine. This is not quite the same as the previous cases mentioned on this bug, but the dumps show that a custom libgcc_s is being used so it should be equivalent. Not sure what the proper fix is but our plan is to bastardise gcc a bit and remove the unwinding routines to make sure the system ones are always used.
[Bug libobjc/64051] New: broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 Bug ID: 64051 Summary: broken exception model detection in libobjc's configure Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se The configure script for libobjc tries to determine if the compiler is using setjmp/longjmp (SJLJ) for exception handling. But it does this by checking the output of the system compiler. Since libobjc will be executing on the target system it should check the behaviour of the gcc that's in the process of being built, not the host's compiler. It also cannot rely on that gcc being able to execute (it might be a cross compile) so it really needs to look at variables from other parts of the build. This is the error message I get: checking for thread model used by GCC... posix checking for exception model to use... configure: error: unable to detect exception model make[1]: *** [configure-target-libobjc] Error 1 make[1]: *** Waiting for unfinished jobs And in config.log: configure:11223: checking for thread model used by GCC configure:11226: result: posix configure:11236: checking for exception model to use configure:11267: i686-pc-linux-gnu-gcc --sysroot=/opt/cendio-build/arch/osx32 -c -x objective-c -fgnu-runtime -fobjc-exceptions -S conftest.c 5 i686-pc-linux-gnu-gcc: language objective-c not recognized i686-pc-linux-gnu-gcc: language objective-c not recognized i686-pc-linux-gnu-gcc: conftest.c: linker input file unused because linking not done configure:11270: $? = 0 configure:11290: error: unable to detect exception model i686-pc-linux-gnu-gcc is a compiler from the system that cross compiles from x86_64 to i686. Fortunately it also doesn't support ObjC which made me spot this error. Otherwise the test would have gone through, but with a result from the wrong compiler.
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 --- Comment #3 from Pierre Ossman ossman at cendio dot se --- libstdc++ compiles fine though, but the previous stage did indeed include a C++ compiler. But even with that requirement, it still seems a bit dangerous. What if the previous compiler uses a different exception model? Or changes some other of all the myriad of options that affect compiler behaviour? First compiler (from RHEL 7): $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) Second compiler: $ i686-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/opt/cendio-build/arch/armhf/usr/bootstrap/bin/i686-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/opt/cendio-build/arch/armhf/usr/bootstrap/libexec/gcc/i686-pc-linux-gnu/4.5.4/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/opt/cendio-build/arch/armhf/usr/bootstrap --with-gmp=/opt/cendio-build/arch/armhf/usr/bootstrap --with-mpfr=/opt/cendio-build/arch/armhf/usr/bootstrap --with-mpc=/opt/cendio-build/arch/armhf/usr/bootstrap --target=i686-pc-linux-gnu --with-sysroot=/opt/cendio-build/arch/armhf --with-system-zlib --with-gnu-as --with-gnu-ld --disable-nls --disable-multilib --disable-libmudflap --enable-shared --enable-threads=posix --enable-languages=c,c++ Thread model: posix gcc version 4.5.4 (GCC) Third compiler: ../configure --host=i686-pc-linux-gnu --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --build=cross-unknown-linux-gnu --with-build-sysroot=/opt/cendio-build/arch/osx32 --target=i686-pc-linux-gnu --with-sysroot=/ --with-system-zlib --with-gnu-as --with-gnu-ld --disable-nls --disable-multilib --disable-libmudflap --enable-shared --enable-threads=posix --enable-languages=c,c++,objc
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 --- Comment #4 from Pierre Ossman ossman at cendio dot se --- I assumed that this would be what happened: Given --build=B --host=H and --target=T: 1. A gcc would be configured with --build=B --host=H --target=T and put in the installation directory. 2. A second gcc would be configured with --build=B --host=B --target=T and used to build all the libraries that execute on the target system (libgcc, libstdc++, libobjc, etc.). But I guess what you are saying is that only the first compiler is built, and if B != H then you use the system compiler to build the libraries? But how could that possibly work given that you will then produce libraries for H, not T?
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 --- Comment #6 from Pierre Ossman ossman at cendio dot se --- Just to make sure I understand you perfectly. This is not supported: ../configure --build=A --host=B --target=B Instead you have to do: ../configure --build=A --host=A --target=B Then use that to: ../configure --build=A --host=B --target=B And those two compilers better have the same settings with regard to the target or you're bound to get problems. Have I understood it correctly?
[Bug target/60428] non-exception (e.g. C) ARM Linux programs depend on libgcc_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 --- Comment #3 from Pierre Ossman ossman at cendio dot se --- Comments?
[Bug target/60428] New: non-exception (e.g. C) ARM Linux programs depend on libgcc_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 Bug ID: 60428 Summary: non-exception (e.g. C) ARM Linux programs depend on libgcc_s Product: gcc Version: 4.5.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ossman at cendio dot se When compiling a C program for ARM Linux, you can easily end up with dependencies on libgcc_s. This is very annoying as it is not how other targets behave and it means extra work to make binaries that work on a lot of system. I tried to understand the issue, and from what I gather the ARM EABI has a more advanced stack unwinding system that involves calling functions. This combined with helpers in libgcc.a for U64 division that can throw exceptions, results in a dependency on libgcc_s. First question: Why are these libgcc.a functions being built with unwind tables? The stated reason is because of CPU exceptions, but AFAIK those result in signals, not language level exceptions? Second question: Let's assume libgcc.a truly needs the unwinding, or if nothing else there will be other C code that is compiled with -fexceptions for compatibility; can we remove the hard NEEDED for libgcc_s and only use it if some C++ (or similar) code pulls it in? I think the answer to the second question is yes. We've applied the attached patch to our gcc and it seems to do the trick. C code will not have libgcc_s as NEEDED, yet you can still throw exceptions just fine, even across C code compiled with -fexceptions. I am a bit concerned about the interaction of weak symbols in a static library (libgcc.a) and versioned symbols in a proper library (libgcc_s.so). Comments?
[Bug target/60428] non-exception (e.g. C) ARM Linux programs depend on libgcc_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 --- Comment #1 from Pierre Ossman ossman at cendio dot se --- Created attachment 32266 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32266action=edit patch to weaken unwind symbols
[Bug target/60428] non-exception (e.g. C) ARM Linux programs depend on libgcc_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 --- Comment #2 from Pierre Ossman ossman at cendio dot se --- Created attachment 32267 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32267action=edit test case
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #11 from Pierre Ossman ossman at cendio dot se --- Created attachment 30419 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30419action=edit main.c We've also been hitting this, so here is a reduced test case to provoke the bug. Output in the failing case: test_spans(nspans=36) 101,100 + 1 101,0 + 1 0,100 + 0 Aborted (core dumped) And for a correct run: test_spans(nspans=36) 101,100 + 1 101,100 + 1 101,100 + 1 101,100 + 1 101,101 + 1 101,101 + 1 101,99 + 1 101,99 + 1 101,102 + 1 ...
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #12 from Pierre Ossman ossman at cendio dot se --- Created attachment 30420 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30420action=edit Makefile
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #13 from Pierre Ossman ossman at cendio dot se --- This was tested using gcc 4.7.2 and gcc 4.5.3.
[Bug libstdc++/48881] Dynamic link to libstdc++-6.dll / libgcc_s_sjlj-1.dll produces broken binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48881 Pierre Ossman ossman at cendio dot se changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #4 from Pierre Ossman ossman at cendio dot se 2011-12-19 10:11:18 UTC --- Well that was a bit rude. If this bug only appears under certain circumstances, then shouldn't we try to find those circumstances rather than just saying that if gcc works on your machine then that's good enough?
[Bug target/47608] New: libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608 Summary: libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: oss...@cendio.se The problem I'm seeing is this: /usr/lib/gcc/i686-apple-darwin9/4.4.3/../../../../i686-apple-darwin9/bin/ld: warning can't open dynamic library: /usr/i686-apple-darwin9/sys-root/libgcc_s.1.dylib referenced from: /usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) If you notice the path to libgcc_s.1.dylib, you see that it is directly in the sys-root. This is of course wrong, and we can see why by examining libstdc++.dylib: $ strings /opt/cendio-build/arch/osx32/usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.dylib | grep dylib /usr/lib/gcc/i686-apple-darwin9/4.4.3/libstdc++.6.dylib /usr/lib/libSystem.B.dylib /libgcc_s.1.dylib /usr/lib/libSystem.B.dylib __mh_dylib_header As you can see, it expects a path of / to libgcc_s. This is not however the path stored in the installed libgcc_s: strings /opt/cendio-build/arch/osx32/usr/lib/gcc/i686-apple-darwin9/4.4.3/libgcc_s.1.dylib | grep dylib /usr/lib/gcc/i686-apple-darwin9/4.4.3/libgcc_s.1.dylib /usr/lib/libSystem.B.dylib __mh_dylib_header After digging around in the gcc build system, I noticed that libgcc_s.1.dylib is built twice. Once with the proper path (the one which gets installed), and once with the broken path (the one that libstdc++.dylib seems to link against). They end up in i686-apple-darwin9/libgcc/libgcc_s.1.dylib and gcc/libgcc_s.1.dylib respectively in the build tree. Digging further I believe I found the cause, and it is two-fold: 1. The darwin specific SHLIB_LINK outputs libgcc_s.1.dylib.tmp (and eventually libgcc_s.1.dylib also gets created). But the target for libgcc_s expects libgcc_s.dylib to be created. From libgcc/Makefile.in: libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts) # @multilib_flags@ is still needed because this may use # $(GCC_FOR_TARGET) and $(LIBGCC2_CFLAGS) directly. # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. $(mkinstalldirs) $(MULTIDIR) $(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \ @multilib_dir@,$(MULTIDIR),$(subst \ @shlib_objs@,$(objects),$(subst \ @shlib_base_name@,libgcc_s,$(subst \ @shlib_map_file@,$(mapfile),$(subst \ @shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \ @shlib_slibdir@,$(shlib_slibdir),$(SHLIB_LINK 2. The rule for libgcc_s.dylib specifies $(extra-parts), which can resolve to nothing or one of two phony targets. In the latter case (which I'm hitting), make will always assume that things need to be rebuilt. Because of either of the above bugs, the recipe will be executed once more when this target hits: all: all-multi # Now that we have built all the objects, we need to copy # them back to the GCC directory. Too many things (other # in-tree libraries, and DejaGNU) know about the layout # of the build tree, for now. $(MAKE) install-leaf DESTDIR=$(gcc_objdir) \ slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR) In other words, libgcc_s.1.dylib will be recreated instead of just copied, which I assume was the purpose of the above target. And it will be recreated incorrectly as slibdir affects how the library is constructed. (Bug 28910 might also be caused by this)
[Bug target/47608] libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608 --- Comment #1 from Pierre Ossman ossman at cendio dot se 2011-02-04 18:12:26 UTC --- Created attachment 23246 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23246 Hackish workaround This is what I've done here to workaround the problem. Compiles fine, but I haven't used to compiler enough to see if I caused any new bugs.
[Bug target/47609] New: libstdc++ depends on libgcc_s.10.5 but gets linked to libgcc_s.10.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47609 Summary: libstdc++ depends on libgcc_s.10.5 but gets linked to libgcc_s.10.4 Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: oss...@cendio.se Not sure what's going on here, but I get this problem linking C++ programs: /usr/lib/gcc/i686-apple-darwin9/4.4.3/../../../../i686-apple-darwin9/bin/ld: Undefined symbols: __Unwind_GetIPInfo collect2: ld returned 1 exit status Telling g++ to be verbose, I can see that it specifies -macosx_version_min 10.4 by default. Examining the different libgcc_s libraries though, I can see that the 10.4 version doesn't include Unwind_GetIPInfo, only the 10.5 version does. I'm not sure why the inconcistency here. The darwin9 target means 10.5, so that might be why libstdc++ assumes it has access to Unwind_GetIPInfo. But then the question is why 10.4 is still the default with the corresponding gcc/g++.
[Bug driver/42955] undecorated cross-compiler gcc fails to find cc1
--- Comment #2 from ossman at cendio dot se 2010-02-09 09:35 --- Like so: /usr/sparc-sun-solaris2.10/bin/gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.4.3/configure --prefix=/usr --mandir=/usr/share/man --target=sparc-sun-solaris2.10 --with-sysroot=/usr/sparc-sun-solaris2.10/sys-root --disable-nls --without-included-gettext --with-gnu-as --with-gnu-ld --enable-version-specific-runtime-libs --enable-threads=posix --enable-languages=c,c++ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
[Bug driver/42955] undecorated cross-compiler gcc fails to find cc1
--- Comment #3 from ossman at cendio dot se 2010-02-09 09:36 --- Btw, my workaround for now is to remove the binaries in /usr/sparc-sun-solaris2.10/bin and replace them with symlinks as gcc will resolve any symlinks before trying to determine its runtime prefix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
[Bug regression/42955] New: undecorated cross-compiler gcc fails to find cc1
I upgrade from gcc 4.1.2 to 4.4.3 and discovered that the gcc in /usr/$(target_noncanonical)/bin no longer is functional. Using it results in: gcc: error trying to exec 'cc1': execvp: No such file or directory Digging around, it turns out that the internal paths are screwed up: $ /usr/sparc-sun-solaris2.10/bin/gcc -print-prog-name=cc1 cc1 $ /usr/sparc-sun-solaris2.10/bin/gcc -print-search-dirs install: /usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/ programs: =/usr/sparc-sun-solaris2.10/bin/../libexec/gcc/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../libexec/gcc/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/bin/ libraries: =/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/lib/:/usr/sparc-sun-solaris2.10/sys-root/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/sys-root/lib/:/usr/sparc-sun-solaris2.10/sys-root/usr/lib/sparc-sun-solaris2.10/4.4.3/:/usr/sparc-sun-solaris2.10/sys-root/usr/lib/ (quick summary: the required path /usr/libexec/gcc/sparc-sun-solaris2.10/4.4.3/ is not in there) The decorated compiler works just fine though: $ /usr/bin/sparc-sun-solaris2.10-gcc -print-prog-name=cc1 /usr/libexec/gcc/sparc-sun-solaris2.10/4.4.3/cc1 Further digging seems to indicate that this was caused by r118765, where the configured in paths only are added if the binary is in $(bindir). I'm hoping this is only an oversight and someone forgot about this extra bindir for cross-compilers as this regression is causing quite a bit of pain here. -- Summary: undecorated cross-compiler gcc fails to find cc1 Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ossman at cendio dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
