* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
@ 2014-11-08 17:39 ` howarth at bromo dot med.uc.edu
2014-11-08 18:15 ` howarth at bromo dot med.uc.edu
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-08 17:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #1 from howarth at bromo dot med.uc.edu ---
Note that this is the only shared library in gcc trunk that produces undefined
symbols on darwin when "-undefined dynamic_lookup" is removed to expose them.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
2014-11-08 17:39 ` [Bug libitm/63781] " howarth at bromo dot med.uc.edu
@ 2014-11-08 18:15 ` howarth at bromo dot med.uc.edu
2014-11-08 18:16 ` howarth at bromo dot med.uc.edu
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-08 18:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #3 from howarth at bromo dot med.uc.edu ---
Created attachment 33923
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33923&action=edit
bzip2 compressed eh_cpp.ii
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
2014-11-08 17:39 ` [Bug libitm/63781] " howarth at bromo dot med.uc.edu
2014-11-08 18:15 ` howarth at bromo dot med.uc.edu
@ 2014-11-08 18:16 ` howarth at bromo dot med.uc.edu
2014-11-08 18:24 ` howarth at bromo dot med.uc.edu
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-08 18:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #4 from howarth at bromo dot med.uc.edu ---
Attached bzip2 of eh_cpp.ii created using...
# /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/ -nostdinc++
-nostdinc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/testsuite/util
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-5.0-20141107/libitm
-I../../../gcc-5.0-20141107/libitm/config/x86
-I../../../gcc-5.0-20141107/libitm/config/posix
-I../../../gcc-5.0-20141107/libitm/config/generic
-I../../../gcc-5.0-20141107/libitm -mrtm -Wall -pthread -Werror -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -MT eh_cpp.lo
-MD -MP -MF .deps/eh_cpp.Tpo -c ../../../gcc-5.0-20141107/libitm/eh_cpp.cc
-fno-common -DPIC -o .libs/eh_cpp.o --save-temps
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
` (2 preceding siblings ...)
2014-11-08 18:16 ` howarth at bromo dot med.uc.edu
@ 2014-11-08 18:24 ` howarth at bromo dot med.uc.edu
2014-11-08 18:35 ` howarth at bromo dot med.uc.edu
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-08 18:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #5 from howarth at bromo dot med.uc.edu ---
The problematic code in eh_cpp.cc appears to be...
#if !defined (HAVE_ELF_STYLE_WEAKREF)
void *__cxa_allocate_exception (size_t) { return NULL; }
void __cxa_throw (void *, void *, void *) { return; }
void *__cxa_begin_catch (void *) { return NULL; }
void __cxa_end_catch (void) { return; }
void __cxa_tm_cleanup (void *, void *, unsigned int) { return; }
void _Unwind_DeleteException (_Unwind_Exception *) { return; }
#endif /* HAVE_ELF_STYLE_WEAKREF */
}
If I append
void __cxa_tm_cleanup (void *, void *, unsigned int) { return; }
after that the linkage succeeds using the xg++ compiler without unresolved
symbols
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
` (3 preceding siblings ...)
2014-11-08 18:24 ` howarth at bromo dot med.uc.edu
@ 2014-11-08 18:35 ` howarth at bromo dot med.uc.edu
2014-11-08 19:04 ` howarth at bromo dot med.uc.edu
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-08 18:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #6 from howarth at bromo dot med.uc.edu ---
Okay, I see the missing linkage on libstdc++ is intentional...
# Force link with C, not C++. For now, while we're using C++ we don't
# want or need libstdc++.
libitm_la_DEPENDENCIES = $(libitm_version_dep)
libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)
but it would be good to know what the impact of the undefined ___cxa_tm_cleanup
has on libitm and what we should do about it.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
` (4 preceding siblings ...)
2014-11-08 18:35 ` howarth at bromo dot med.uc.edu
@ 2014-11-08 19:04 ` howarth at bromo dot med.uc.edu
2014-11-08 20:20 ` fxcoudert at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-08 19:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #6)
> Okay, I see the missing linkage on libstdc++ is intentional...
>
> # Force link with C, not C++. For now, while we're using C++ we don't
> # want or need libstdc++.
> libitm_la_DEPENDENCIES = $(libitm_version_dep)
> libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
> libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)
>
On reflection, if this were true shouldn't there be no undefined symbols from
libstdc++ present in the libitm shared library?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
` (5 preceding siblings ...)
2014-11-08 19:04 ` howarth at bromo dot med.uc.edu
@ 2014-11-08 20:20 ` fxcoudert at gcc dot gnu.org
2014-11-08 20:25 ` iains at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2014-11-08 20:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org
--- Comment #8 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
As far as I understand, libitm is supposed to be used with either C or C++. As
such, it contains some C++ code which requires libstdc++, but doesn't link to
it by default. That way, if someone compiles C code with libitm, it doesn't use
need the C++ libitm code, and doesn't pull libstdc++. And when one compiles C++
code, libstdc++ is linked in anyway, so it's no problem.
In short, I'm afraid I don't understand what you think the problem is :)
Do you have a "real" testcase that fails to link?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
` (6 preceding siblings ...)
2014-11-08 20:20 ` fxcoudert at gcc dot gnu.org
@ 2014-11-08 20:25 ` iains at gcc dot gnu.org
2014-11-08 20:29 ` howarth at bromo dot med.uc.edu
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: iains at gcc dot gnu.org @ 2014-11-08 20:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #8)
> As far as I understand, libitm is supposed to be used with either C or C++.
> As such, it contains some C++ code which requires libstdc++, but doesn't
> link to it by default. That way, if someone compiles C code with libitm, it
> doesn't use need the C++ libitm code, and doesn't pull libstdc++. And when
> one compiles C++ code, libstdc++ is linked in anyway, so it's no problem.
>
> In short, I'm afraid I don't understand what you think the problem is :)
> Do you have a "real" testcase that fails to link?
This is quite correct, as I pointed out to Jack before he opened the issue.
libitm weak links to the relevant symbols and uses them as required by the
final program.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
` (7 preceding siblings ...)
2014-11-08 20:25 ` iains at gcc dot gnu.org
@ 2014-11-08 20:29 ` howarth at bromo dot med.uc.edu
2014-11-08 20:33 ` fxcoudert at gcc dot gnu.org
2014-11-08 20:41 ` fxcoudert at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-08 20:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #10 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Francois-Xavier Coudert from comment #8)
> > As far as I understand, libitm is supposed to be used with either C or C++.
> > As such, it contains some C++ code which requires libstdc++, but doesn't
> > link to it by default. That way, if someone compiles C code with libitm, it
> > doesn't use need the C++ libitm code, and doesn't pull libstdc++. And when
> > one compiles C++ code, libstdc++ is linked in anyway, so it's no problem.
> >
> > In short, I'm afraid I don't understand what you think the problem is :)
> > Do you have a "real" testcase that fails to link?
>
> This is quite correct, as I pointed out to Jack before he opened the issue.
> libitm weak links to the relevant symbols and uses them as required by the
> final program.
So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined symbol
in libitm?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
` (8 preceding siblings ...)
2014-11-08 20:29 ` howarth at bromo dot med.uc.edu
@ 2014-11-08 20:33 ` fxcoudert at gcc dot gnu.org
2014-11-08 20:41 ` fxcoudert at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2014-11-08 20:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
--- Comment #11 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to howarth from comment #10)
> So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined
> symbol in libitm?
No, that symbol is in libstdc++
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug libitm/63781] potential linkage issue with libitm.1.dylib
2014-11-08 17:33 [Bug libitm/63781] New: potential linkage issue with libitm.1.dylib howarth at bromo dot med.uc.edu
` (9 preceding siblings ...)
2014-11-08 20:33 ` fxcoudert at gcc dot gnu.org
@ 2014-11-08 20:41 ` fxcoudert at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2014-11-08 20:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63781
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #12 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to howarth from comment #10)
> So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined
> symbol in libitm?
Maybe I should be more explicit: ___cxa_tm_cleanup comes from libstdc++. It is
not an undefined reference, but a weak one.
1. If you compile/link C code with libitm, ___cxa_tm_cleanup is guaranteed not
to be called. Because it's a weak reference, it doesn't matter that it wouldn't
be found. No problem.
2. If you compile/link C++ code with libitm, the g++ driver will link in
libstdc++. So, when ___cxa_tm_cleanup gets called from libitm, the weak
reference will correctly call the symbol from libstdc++. No problem.
Given that Iain validates my analysis, let's close this one.
^ permalink raw reply [flat|nested] 12+ messages in thread