https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #37 from Jürgen Reuter ---
I'm inclined to advice to close this PR. In principle, it would be good to
follow up on this and see which change around Christmas 2018 triggered this,
but I fear we don't have the personpower atm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #36 from Dominique d'Humieres ---
Any progress? Is it really a gfortran bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #34 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #33)
> (In reply to Iain Sandoe from comment #32)
> > (In reply to Jürgen Reuter from comment #31)
> > > Then I get tons of duplicate symbol lines.
> >
> > ah well,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #33 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #32)
> (In reply to Jürgen Reuter from comment #31)
> > Then I get tons of duplicate symbol lines.
>
> ah well, not so simple then,
>
> then I think the next step is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #32 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #31)
> Then I get tons of duplicate symbol lines.
ah well, not so simple then,
then I think the next step is for you to identify the last working revision of
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #31 from Jürgen Reuter ---
Then I get tons of duplicate symbol lines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #30 from Iain Sandoe ---
well, what I'm trying to achieve is that the exe (with libstdc++ linked in)
provides all the symbols.
it's -Wl,-export_dynamic with an underscore, no a hyphen
you might need to add -Wl,-all_load too (to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #29 from Jürgen Reuter ---
-rdynamic doesn't change anything, and ld doesn't understand -export-dynamic.
I am a bit confused what to do now, as we have a workaround, i.e. using -static
instead of -static-libtool-libs as libtool flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #28 from Iain Sandoe ---
I wonder what would happen if you add -rdynamic (or -Wl,-export_dynamic) to the
main exe in the static link case, perhaps that would ensure that the libstdc++
symbols get resolved from there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #27 from Iain Sandoe ---
JFTR, I did an experiment with a trivial hot/cold partitioned object and ld64
from XCode10.1.
Yes, it complains - but it still publishes the symbol as a weak extern.
I looked a bit harder at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #26 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #25)
> (In reply to Richard Biener from comment #24)
> > (In reply to Iain Sandoe from comment #23)
> > > (In reply to Jürgen Reuter from comment #22)
>
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #25 from Jürgen Reuter ---
(In reply to Richard Biener from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > (In reply to Jürgen Reuter from comment #22)
>
> Indeed - somehow you didn't get a statically linked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #24 from Richard Biener ---
(In reply to Iain Sandoe from comment #23)
> (In reply to Jürgen Reuter from comment #22)
> > This is the output from the lldb command (but this was not a debug build of
> > gcc yet):
> > $ lldb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #23 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #22)
> This is the output from the lldb command (but this was not a debug build of
> gcc yet):
> $ lldb ./static_1.exe
> (lldb) target create "./static_1.exe"
> Current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #22 from Jürgen Reuter ---
This is the output from the lldb command (but this was not a debug build of gcc
yet):
$ lldb ./static_1.exe
(lldb) target create "./static_1.exe"
Current executable set to './static_1.exe' (x86_64).
(lldb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #21 from Jürgen Reuter ---
Created attachment 45388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45388=edit
DYLD_PRINT output working example
DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./static_1.exe > working_output
2>&1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #20 from Jürgen Reuter ---
Created attachment 45387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45387=edit
DYLD_PRINT output non-working example
DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./static_1.exe >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #19 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #18)
> (In reply to Jürgen Reuter from comment #14)
>
> does the application use exceptions?
No exceptions, only a poor man's C signal catcher.
>
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #18 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #14)
does the application use exceptions?
> This one is failing:
> gfortran -g -O2 -Wl,-rpath -Wl,/usr/local/packages/OpenLoops/lib -o
> static_1.exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #17 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #16)
> Yes, after the problem occurred, I did a completely clean new build of gmp,
> mpfr, mpc, gcc (configured with ../configure --prefix=/usr/local/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #16 from Jürgen Reuter ---
Yes, after the problem occurred, I did a completely clean new build of gmp,
mpfr, mpc, gcc (configured with ../configure --prefix=/usr/local/
--with-gmp=/usr/local/ --with-mpfr=/usr/local/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #15 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #14)
> Well, it seems that r267488 from Dec 31 was still working, on the other
> hand, I saw a problem on the other MACbook definitely around at latest Dec
> 26 or so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #14 from Jürgen Reuter ---
Well, it seems that r267488 from Dec 31 was still working, on the other hand, I
saw a problem on the other MACbook definitely around at latest Dec 26 or so.
Probably before Christmas. It might be that small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #13 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #12)
> No, unfortunately a working svn # is difficult, I first observed it by doing
> svn up on another Macbook around Christmas.
hmm ... that's tricky - a busy time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #12 from Jürgen Reuter ---
No, unfortunately a working svn # is difficult, I first observed it by doing
svn up on another Macbook around Christmas. What do you mean by transcripts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #11 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #10)
> The trunk, svn 267657, all newest versions of gmp, mpfr, mpc. It seems that
> the problem is also solved when I use the libtool flag -static instead of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #10 from Jürgen Reuter ---
The trunk, svn 267657, all newest versions of gmp, mpfr, mpc. It seems that the
problem is also solved when I use the libtool flag -static instead of
-static-libtool-libs for libtool to build these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #9 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #8)
Thanks!
I've been using gmp-6.1.2, mpfr-3.1.6, mpc-1.1.0 isl-0.20 on all my recent
builds (for trunk, gcc-8 and gcc-7)
You don't (I think) mention whether the GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #8 from Jürgen Reuter ---
Yes I know:
here is the non-working library resolution:
static_1.exe:
lib/libcuttools.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/libopenloops.dylib (compatibility version 0.0.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #6 from Jürgen Reuter ---
In the linking before I do see the following warning:
ld: warning: direct access in function 'operator new[](unsigned long,
std::nothrow_t const&) [clone .cold]' from file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #5 from Jürgen Reuter ---
Indeed, things are more complicated. With a slim build of our software I don't
get the error, but only if we link the external library LCIO. This can be
downloaded from here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
35 matches
Mail list logo
