[Bug modula2/107612] New: plugin/m2rte doesn't build on Mac OS X 10.7

[Bug modula2/107612] New: plugin/m2rte doesn't build on Mac OS X 10.7

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

            Bug ID: 107612
           Summary: plugin/m2rte doesn't build on Mac OS X 10.7
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: modula2
          Assignee: gaius at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-apple-darwin11.4.2
            Target: x86_64-apple-darwin11.4.2
             Build: x86_64-apple-darwin11.4.2

Building the current devel/modula-2 branch on Mac OS X 10.7 fails building
the m2rte plugin:

* First, compilation fails

In file included from
/vol/gcc/src/hg/master/modula-2/gcc/m2/plugin/m2rte.cc:31:
/vol/gcc/src/hg/master/modula-2/gcc/intl.h:30:10: fatal error: libintl.h: No
such file or directory
   30 | #include <libintl.h>
      |          ^~~~~~~~~~~

  There's no system libintl, but the compile command lacks $(INCINTL).

  To fix this, gcc/Makefile.in needs

  INCINTL = @INCINTL@

  so $(INCINTL) can be used in gcc/m2/Make-lang.in.  Then, the current
  instances of @INCINTL@ in gcc/Makefile.in can also be replaced by $(INCINTL).

* This (done manually for now) lets the compilation succeed, but the link still
  fails:

Undefined symbols for architecture x86_64:
  "__Z13integer_zeropPK9tree_node", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "__Z13rtegraph_initv", referenced from:
      _plugin_init in m2rte.o
  "__Z15rtegraph_finishv", referenced from:
      __ZN12_GLOBAL__N_113analyse_graphEPvS0_ in m2rte.o
  "__Z15rtegraph_lookupP6gimpleP9tree_nodeb", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "__Z17rtegraph_discoverv", referenced from:
      __ZN12_GLOBAL__N_113analyse_graphEPvS0_ in m2rte.o
  "__Z17rtegraph_get_funcP7rtenode", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "__Z17tree_check_failedPK9tree_nodePKciS3_z", referenced from:
     
__ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function.cold in
m2rte.o
  "__Z23tree_class_check_failedPK9tree_node15tree_code_classPKciS4_",
referenced from:
     
__ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function.cold in
m2rte.o
  "__Z24rtegraph_externs_includeP7rtenode", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "__Z24rtegraph_include_rtscallP7rtenode", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "__Z25tree_operand_check_failediPK9tree_nodePKciS3_", referenced from:
     
__ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function.cold in
m2rte.o
  "__Z27rtegraph_candidates_includeP7rtenode", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "__Z29rtegraph_constructors_includeP7rtenode", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "__Z29rtegraph_set_current_functionP7rtenode", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "__Z29tree_int_cst_elt_check_failediiPKciS0_", referenced from:
     
__ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function.cold in
m2rte.o
  "__Z30rtegraph_include_function_callP7rtenode", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
 
"__Z33tree_contains_struct_check_failedPK9tree_node24tree_node_structure_enumPKciS4_",
referenced from:
     
__ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function.cold in
m2rte.o
  "__ZN8opt_pass14set_pass_paramEjb", referenced from:
      __ZTVN12_GLOBAL__N_130pass_warn_exception_inevitableE in m2rte.o
  "__ZN8opt_pass4gateEP8function", referenced from:
      __ZTVN12_GLOBAL__N_130pass_warn_exception_inevitableE in m2rte.o
  "__ZN8opt_pass5cloneEv", referenced from:
      __ZTVN12_GLOBAL__N_130pass_warn_exception_inevitableE in m2rte.o
  "__ZN8opt_passC2ERK9pass_dataPN3gcc7contextE", referenced from:
      _plugin_init in m2rte.o
  "_g", referenced from:
      _plugin_init in m2rte.o
  "_plugin_default_version_check", referenced from:
      _plugin_init in m2rte.o
  "_register_callback", referenced from:
      _plugin_init in m2rte.o
  "_tree_code_length", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "_tree_code_type", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
  "_tree_contains_struct", referenced from:
      __ZN12_GLOBAL__N_130pass_warn_exception_inevitable7executeEP8function in
m2rte.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [plugin/m2rte.so] Error 1

  For one, the plugin may need to be linked with $(LIBINTL) (or not, don't
  know for certain).  Besides, according to
gcc/testsuite/lib/plugin-support.exp,
  the link needs to add -undefined dynamic_lookup

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
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 m2rte: No such file or directory
compilation terminated.

There's code in gcc/jit/Make-lang.in handling the same situation.

To get further along, I've just manually added a symlink for now.

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 53902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53902&action=edit
Initial patch

The attached patch allowed the plugin to build on macOS.

I'm not really happy about it for a couple of reasons:

* It duplicates code that would better be imported from config/gcc-plugin.m4
  (or moved there, like soext).  libcc1/configure.ac and Makefile.am have yet
  another instance, conditional on DARWIN_DYNAMIC_LOOKUP.  This permanent
  (partial) duplication is one primary problem of some areas of the GCC
  code base.

* config/gcc-plugin.m4 should use config/picflag.m4 both to avoid duplicating
  PICFLAG and messing around with CFLAGS/CXXFLAGS to remove -mdynamic-pic with
  sed.  Instead, it would adding -mno-cynamic-no-pic for free (and only in one
  place), and could easily export something like PLUGINCFLAGS/PLUGiNCXXFLAGS
  and add PLUGINLDFLAGS, preferable AC_SUBST'ing those itself instead of having
  the callers do it.

I've now idea if such a patch would be acceptable in stage 3, though.
  PICLDFLAGS

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |iains at gcc dot gnu.org
   Last reconfirmed|                            |2022-12-15
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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
> /var/gcc/modula-2/10.7-gcc/./gcc/plugin/m2rte.dylib expanded from short
> plugin name m2rte: No such file or directory
> compilation terminated.
> 
> There's code in gcc/jit/Make-lang.in handling the same situation.
> 
> To get further along, I've just manually added a symlink for now.


Hi Rainer, you are ahead of me in testing this (I got bogged down in fixing
libffi for i686 rust use)

Just to note that the values used in gcc/jit/Make-lang.in are still not
completely correct (and that causes problems with cross-compilers where the
target and host linkers are different)

 * because LD_VERSION_SCRIPT_OPTION and LD_SONAME_OPTION are for $target, not
$host.
 * (maybe not relevant to gm2) the .map file is not in a format usable by
Darwin's linker and unfortunately the existing conversion scripts in the tree
do not handle that specific map.

So much of the content is useful for Darwin and mingw but those points need to
be taken into account (rather than copying verbatim).

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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
> /var/gcc/modula-2/10.7-gcc/./gcc/plugin/m2rte.dylib expanded from short
> plugin name m2rte: No such file or directory
> compilation terminated.
> 
> There's code in gcc/jit/Make-lang.in handling the same situation.
> 
> To get further along, I've just manually added a symlink for now.


Hi Rainer, you are ahead of me in testing this (I got bogged down in fixing
libffi for i686 rust use)

Just to note that the values used in gcc/jit/Make-lang.in are still not
completely correct (and that causes problems with cross-compilers where the
target and host linkers are different)

 * because LD_VERSION_SCRIPT_OPTION and LD_SONAME_OPTION are for $target, not
$host.
 * (maybe not relevant to gm2) the .map file is not in a format usable by
Darwin's linker and unfortunately the existing conversion scripts in the tree
do not handle that specific map.

So much of the content is useful for Darwin and mingw but those points need to
be taken into account (rather than copying verbatim).

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
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 specific DSO at link
time).

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
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 is not yet installed).

so if I then install libstdc++ and resume the build.

.. then the target library build fails with a lot of missing symbols.

(I am also trying on rosetta-2 x86_64 on macOS12).

A weird thing that I can't explain (and could be unrelated, it just happens to
appear at the same time) is that when I try to restart a parallel build (after
fixing things up) I end up with a make instance spinning at 100% .. yet if I
resume the build as a single process... it proceeds.

unfortunately, I have no time for analysis - I have some CPU cycles, but no
spare engineering ones...

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
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 end up with something like
plugin\m2rte.exe.dll
on Windows?

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
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 libc.  Slightly worrying is that
find/grep seems to suggest that they might be provided from files named
"glibc.xxx".

Does m2 only work with glibc?
(in which case there's a lot of work to do for Darwin, Windows etc)

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
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 it's deprecated.. (as is dynamic exports).  

... so what we need is the library dependency order and then we can build in
reverse order and link the dependency DSOs ...

=====

NOTE: I think we should link the plugin against the stdc++ symbols in gm2,
since that statically links libstdc++ .. 

.. if we dynamically link it from the plugin then when the plugin is loaded
there would be two versions of each libstdc++ symbol in the same process (one
from gm2 and one from the libstdc++.dylib).

fun...

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
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 installed.

 * it's not right to link it anyway - the plugin needs to resolve its symbols
from cc1gm2

Adding -nodefaultlibs fixes this + I adjusted the install name.
Actually, I do not think the rpaths are needed - because the plugin is
explicitly loaded - it does not need to find any dependent libs.

---- 

diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in
index 0ea73e766d1..8d86c1371f3 100644
--- a/gcc/m2/Make-lang.in
+++ b/gcc/m2/Make-lang.in
@@ -36,7 +36,10 @@ ifeq (,$(findstring darwin,$(host)))
   soext=.so
 else
   soext=.dylib
-  PLUGINLDFLAGS=-Wl,-undefined,dynamic_lookup
+  PLUGINLDFLAGS = -Wl,-undefined,dynamic_lookup
+  PLUGINLDFLAGS += -Wl,-install_name,m2rte$(soext)
+  PLUGINLDFLAGS += -Wl,-rpath,@loader_path,-rpath,@loader_path/..
+  PLUGINLDFLAGS += -nodefaultlibs
 endif

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:ebc41f9a817dbae01c7450cd33c1968318ce8df0

commit r13-4939-gebc41f9a817dbae01c7450cd33c1968318ce8df0
Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Date:   Thu Dec 15 10:43:37 2022 +0000

    modula-2: Fix building the plugin for Darwin [PR107612].

     * Makes the configured value for INCINTL available as a variable so that
    it can be used in language makefile fragements.  It is then used in the m2
    fragment to make the include path available to the plugin compile.

     * Updates the DSO suffix  to use .dylib for Darwin.

     * Adds '-Wl,-undefined,dynamic_lookup' to the link flags so that symbols
can
       be resolved at runtime.

     * Removes the extraneous $(exeext) from the DSO names.

    Since the linking is driven by CXX, we also need to supress the addition of
    default libraries otherwise:
     (1) we will get a reference to an uninstalled libstdc++
     (2) the process opening the plugin would have two instances 0f libstdc++ -
         one statically linked into gm2 and one dynamically linked into the
plugin.

            PR modula2/107612

    gcc/ChangeLog:

            * Makefile.in: Make the configured libintl includes avaiable in
INCINTL.
            (BUILD_CPPFLAGS): Use INCINTL.

    gcc/m2/ChangeLog:

            * Make-lang.in (soext): Use .dylib for Darwin.
            (PLUGINLDFLAGS): Use dynmic lookup, set the plugin name, and append
            -nodefaultlibs to suppress the linking of libstdc++.
            Use INCINTL in compile lines for the plugin.

    Co-Authored-By: Iain Sandoe <iain@sandoe.co.uk>

[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed.