https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #11 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:ebc41f9a817dbae01c7450cd33c1968318ce8df0
commit r13-4939-gebc41f9a817dbae01c7450cd33c1968318ce8df0
Author: Rainer Orth
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #10 from Iain Sandoe ---
I fixed the plugin build to avoid linking libstdc++ (small additions to
Rainer's patch)
* linking libstdc++ causes the build to fail because the plugin cannot find
the libstdc++ because it is not yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #9 from Iain Sandoe ---
mystery solved.
The symbols are also undefined on Linux, but the linux linker silently allows
this.
To do this on Darwin, we have to add -Wl,-undefined,dynamic_lookup
However, this mode is looking like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #8 from Iain Sandoe ---
I did a little more poking - some of the missing symbols are in
m2/gm2-libs-boot/libgm2.a
adding that to the failing link line results in some more missing symbols,
these look mainly like wrappers around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #7 from Iain Sandoe ---
same result on x86_64 darwin21 - under rosetta 2.
BTW: this seems a bit odd to me I see the plugin specified like this:
plugin/m2rte$(exeext)$(soext) (.so without Rainer's patch).
Why $(exeext)?
Won't you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #6 from Iain Sandoe ---
hmm .. some odd things.
With Rainer's patch actually the plugin build succeeded on x86_64-darwin19
(Catalina)
so then the plugin fails to load because it is missing the libstdc++ version
needed (since that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #5 from Iain Sandoe ---
sorry about the duplicate comment - not quite sure what BZ did there.
Note: dynamic lookups might become an issue for Darwin2* (I expect that there
is a move towards requiring that symbols are resolved to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #4 from Iain Sandoe ---
(In reply to Rainer Orth from comment #1)
> Besides, the m2rte plugin is incorrectly named on Darwin, thus unusable:
>
> cc1gm2: fatal error: inaccessible plugin file
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #2 from Rainer Orth ---
Created attachment 53902
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53902=edit
Initial patch
The attached patch allowed the plugin to build on macOS.
I'm not really happy about it for a couple of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
--- Comment #1 from Rainer Orth ---
Besides, the m2rte plugin is incorrectly named on Darwin, thus unusable:
cc1gm2: fatal error: inaccessible plugin file
/var/gcc/modula-2/10.7-gcc/./gcc/plugin/m2rte.dylib expanded from short plugin
name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |13.0
13 matches
Mail list logo
