Known Problems with CM3

Contents:

1 General Problems
   1.1 Linkage failure: cannot find -lXaw
   1.2 Filenames with spaces
   1.3 Linker trouble with latest Microsoft VC++ compilers on WIN32 platform
   1.4 Assembler problem on LINUXLIBC6 (filds instrcution)
   1.5 Version stamp mismatch during upgrading

2 Release 5.1.0
   2.1 Installation on NT386 fails because of missing cygwin.dll

3 Release 5.1.1

4 Release 5.1.2-5.1.8
   4.1 Linkage failure: missing -L before library paths (installer bug)
   4.2 [Release 5.1.8] Linkage failure on POSIX platforms due to wrong paths (/pub/lang/m3/cm3-dist) in binary installation archives

5 Release 5.2.X
   5.1 Problems building the core distribution with Apple's gcc
   5.2 Compilation of m3gc-enhanced fails on PPC_DARWIN
   5.3 Problems with efficient exception handling (`stack walkers') and gcc 3.2.1
   5.4 Installation program fails with unhandled OSError exception on SOLgnu platform
   5.5 Segmentation fault errors on Fedora 3 and Gentoo Linux

6 Release 5.4.X
   6.1 Segmentation violations on Linux, compile fails with PklFonts core dumping
   6.2 Unresolved X11 libraries on NetBSD
   6.3 Issues with /usr/bin/ld on Solaris
   6.4 asm/ipc.h not found on Linux

1 General Problems

General problems and notes applying to all releases:

1.1 Linkage failure: cannot find -lXaw

Platforms: mostly LINUXLIBC6, LINUXELF

Description: Problems of this kind will arise if the linker cannot find the static standard libraries of the X systems. This will mostly be a problem on Linux systems, as almost all newer distributions tend to not install static libraries by default. A typical failure situation looks like this:

> === package /home/i8fs1/VERIF/usr/old/stow/cm3/current/m3-ui/formsedit ===
>  +++ cm3 -build -override -DROOT=/home/i8fs1/VERIF/usr/old/stow/cm3/current  +++
> --- building in LINUXLIBC6 ---
> /home/i8fs1/VERIF/usr/old/stow/cm3/tmp/bin/m3bundle -name formseditBundle -F/tmp/qk
> new source -> compiling FormsEditVBT.i3
> new source -> compiling formseditBundle.i3
> new source -> compiling FormsEditVBT.m3
> new source -> compiling FormsEdit.m3
> new source -> compiling formseditBundle.m3
>  -> linking formsedit
> /home/i8fs1/VERIF/usr/old/bin/ld: cannot find -lXaw
> collect2: ld returned 1 exit status
    

Solution: Usually it is possible to install the missing libraries without much effort.

1.2 Filenames with spaces

Platforms: all, especially WIN32

Description: CM3 currently cannot handle filenames containing spaces very well. This will probably not be an issue on POSIX platforms, but it is very annoying on WIN32, as many standard installation path names contain spaces there.

The problem cannot be easily resolved. This is due to the broken process creation interface on WIN32 platforms, which does not allow transparent passing of parameters, and some standard quake functions, which have to be replaced by more general equivalents, like exec, arglist (probably more).

Solution: There is no easy solution to this problem. As a temporary work-around, the installer has been modified to replace pathnames with spaces by their 8.3 style equivalent on WIN32. If you cannot avoid using spaces in your CM3 projects, the 8.3 style short form should be a possible though ugly work-around for that, too. Voluntary contributions in this area are more than welcome. This work-around is incorporated in all installation programs since release 5.1.1.

1.3 Linker trouble with latest Microsoft VC++ compilers on WIN32 platform

Platforms: WIN32/NT386, reproduced with Microsoft 32-Bit C/C++-Compiler, Version 12.00.8804, non-issue with 32-bit C/C++ Standard Compiler Version 10.00.6002 for 80x86

Description: Building of dynamic libraries (DLLs) (e.g. for m3core) fails with unresolvable ambiguous symbols __real@8@... It turns out that during the compilation of C sources the compiler defines an 8 bytes data section for every floating point constant (which is fine) and marks it as exported (which is certainly unexpected). The library archiver mklib shortens these symbols after the first @ character and leaves the linker with lots of equally named constants. It is still unclear to me why the compiler behaves in this way.

Note: There has been one report where more linker errors have been encountered (in libm3), though the work-around mentioned below had been applied. So it may well be that there are still undiscovered problems and unknown incompatibilities with particular releases of the Microsoft tools.

Solution: No real solution is known, as I haven't found a way to make the compiler not export the floating point constants. Older compilers (see above) do not exhibit this behaviour. Unfortunately, it is neither possible (as has been suggested) to (a) not to shorten the symbols after the @ character, and (b) ignore the export of all symbols beginning with two underscores while writing the linker .def file (this even fails for libm3). In CM3 5.1.3 a work-around has been implemented, which cures the problem for all tested m3 packages; this is still no general solution, though, as it may break other existing code. The mklib program has been extended by a switch to ignore certain exported symbols: -ign:XXX instructs the archiver to ignore all symbols beginning with XXX. The option -ign:__real has been added to the templates for the global configuration file cm3.cfg.

1.4 Assembler problem on LINUXLIBC6 (filds instrcution)

Platforms: reported for LINUXLIBC6, possibly other POSIX platforms, too

Description: The assembler reports errors due to an unknown i386 instruction like this:

  new source -> compiling RealFloatExtras.m3
  RealFloatExtras.ms: Assembler messages:
  RealFloatExtras.ms:69: Error: no such 386 instruction: `filds'
  RealFloatExtras.ms:153: Error: no such 386 instruction: `filds'
  RealFloatExtras.ms:209: Error: no such 386 instruction: `filds'
  new source -> compiling LongFloatExtras.i3
  new source -> compiling LongFloatExtras.m3
  LongFloatExtras.ms: Assembler messages:
  LongFloatExtras.ms:69: Error: no such 386 instruction: `filds'
  LongFloatExtras.ms:154: Error: no such 386 instruction: `filds'
  LongFloatExtras.ms:211: Error: no such 386 instruction: `filds'
      

The above was observed on a RedHat 6.1 Linux system with libc6 and gcc 2.91.66 (egcs-1.1.2).

Solution: I've currently no information about the excat version of GNU tools that cause the problem, which obviously seems to be a compiler/assembler version mismatch. I would expect that upgrading the assembler to a more recent version should solve the problem, but haven't asserted this yet, nor do can I name the version that is needed. More information from people working on (RedHat) Linux systems would be welcome.

1.5 Version stamp mismatch during upgrading

Platforms: all

Description: The compiler reports version stamp mismatches in libm3 like this:

 new source -> compiling ProcessPosix.m3
 new source -> compiling SocketPosix.m3

 Fatal Error: bad version stamps: SocketPosix.m3 
 
 version stamp mismatch: Compiler.Platform 
   <00df7acd080d2be7> => SocketPosix.m3 
    => Compiler.i3 
 version stamp mismatch: Compiler.ThisPlatform 
   <4d31a453f94cbb46> => SocketPosix.m3 
    => Compiler.i3 
  *** execution of  failed ***

Solution: This only occurs on rare occasions when new target platforms have been added to the compiler. The solution is to first build a compiler who knows about the news platforms with the existing m3core and libm3 packages, and then build everything again. For a detailed description, see Upgrading CM3.

2 Release 5.1.0

Problems and notes specific to release 5.1.0:

2.1 Installation on NT386 fails because of missing cygwin.dll

Platforms: NT386

Description: The installation program cannot unpack the system and other archives because cygwin.dll, which is needed by the bundled tar.exe, is missing in the installation archive.

Solution: Either

3 Release 5.1.1

Problems and notes specific to release 5.1.1:

4 Release 5.1.2 - 5.1.8

Problems and notes specific to release 5.1.8:

4.1 Linkage failure: missing -L before library paths (installer bug)

Platforms: all

Description: The compiler complains about non-existant library files when trying to link with libraries that were not present at installation time but have been installed later. This is due to a bug in the installation program cminstall which forgets to prepend the string "-L" to all library paths for libraries that haven't actually been found by it. Thus the system library definitions in the configuration file cm3.cfg used by the system linker are sometimes incorrect.

Solution: Add the missing -L to all system library definitions in cm3.cfg where it is missing. For example, the corresponding section in a FreeBSD4 configuration file (located at /usr/local/cm3/bin/cm3.cfg by default) might look like this (with all library path options added):

SYSTEM_LIBS = {
  "LIBC"       : [ "-lm" ],
  "LEX-YACC"   : [ "-L/usr/lib", "-ll" ],
% "FLEX-BISON" : [ "-L/usr/lib", "-lfl" ],
  "POSTGRES95" : [ "-L/usr/local/pgsql/lib", "-lpq" ],
  "OPENGL"     : [ "-L/usr/X11R6/lib", "-lGLU", "-lGL", "-lXext" ],
  "MOTIF"      : [ "-L/usr/X11R6/lib", "-lXm" ],
  "X11"        : [ "-L/usr/X11R6/lib", "-lXaw", "-lXmu", "-lXext",
                   "-lXt", "-lSM", "-lICE", "-lX11" ],
  "TCP"        : [ ],
  "ODBC"       : [ "-L/usr/local/lib", "-lodbc" ]
}
    

The problem has been corrected shortly after the release of CM3 5.1.8.

4.2 [Release 5.1.8] Linkage failure on POSIX platforms due to wrong paths (/pub/lang/m3/cm3-dist) in binary installation archives

Platforms: all POSIX platforms

Description: The isolation of the garbage collection support from m3core has lead to one unexpected problem in the preparation of the minimal binary installation archives. On all POSIX platforms, m3core now depends on either m3gc-simple or m3gc-enhanced. As m3core cannot import another Modula-3 library (due to subtleties of the runtime implementation), these libraries only contain some C source code files and are shipped explicitly to the installation root (INSTALL_ROOT in cm3.cfg). The used declaration for this export (LibdExport(libname)) creates an import directive like the following one in all .M3EXPORTS files of packages depending on it:

  _import_otherlib("m3gcdefs", "/pub/lang/m3/cm3-dist/cm3/lib", IMPORTED)
    

This directive contains the absolute path (LIB_INSTALL) of the library in question. As the binary installation archives are always produced in an empty staging area (for example /pub/lang/m3/cm3-dist/cm3), this path is unlikely to be correct for the actual installation (where it should be /usr/local/cm3/lib by default).

Solution: There are several possible solutions for this problem. We assume that INSTALL_ROOT is /usr/local/cm3 and TARGET is the POSIX platform in use (FreeBSD4, LINUXLIBC6, etc.).

  1. After the installation of the minimal binary cm3 5.1.8 distribution, edit the files
    /usr/local/cm3/pkg/m3core/TARGET/.M3EXPORTS /usr/local/cm3/pkg/libm3/TARGET/.M3EXPORTS
    and replace the line
    _import_otherlib("m3gcdefs", "/pub/lang/m3/cm3-dist/cm3/lib", IMPORTED)
    by either
    _import_otherlib("m3gcdefs", "/usr/local/cm3/lib", IMPORTED)
    or
    _import_otherlib("m3gcdefs", LIB_USE, IMPORTED)
  2. After the installation of the minimal binary cm3 5.1.8 distribution, build and ship the packages m3core and libm3 from one of the source distribution archives (e.g. cm3-src-std-5.1.8.tgz). You can do this with the following commands (WORK identifying your working area where you unpacked the sources):
      cd WORK/cm3/scripts
      ./do-pkg buildship m3core
      ./do-pkg buildship libm3
            
    This will put the correct paths in the .M3EXPORTS files.
  3. Use sed or perl to perform the needed substitutions as described in (1).

Future distributions (release > 5.1.8) will avoid this problem by either modifying the export/import-mechanism for m3gc-simple and m3gc-enhanced, adjust the absolute paths during the construction of the binary distribution archive, or automatically adjust the abolsute paths after installation.

5 Release 5.2.X

5.1 Problems building the core distribution with Apple's gcc

Platforms: PPC_DARWIN

Description: The first problem is that Apple's gcc will produce the two non-relocatable symbols saveSP and restFP when compiling setjmp/longjmp calls; this will make the building of a dynamic library for m3core fail. The work-around is to use an assembler source RTThredC.s instead of RTThreadC.c that does not refer to these routines and explicitly saves and restores the floating point registers.

For the explanation of the second problem I just append the mail I've to interested parties:

--- start of quote ---
After your failure reports for compilation of the cm3/m3-sys/m3cc package (the gcc 3.2.1 based code generator) I made some tests myself and found that I had obviously again used my own gcc to build this package.

I've made two or three attempts to get the package compile with Apple's native gcc (3.1 prerelease), but failed too. If nobody else finds a smart configuration hack I'm afraid that one will need a bootstrapped gcc 3.2.1 C compiler to compile the cm3cg code generator. This is annoying as it adds another big dependency for cm3 on Darwin; but it is not as big a problem as it might seem for two reasons:

  1. It was relatively easy for me to bootstrap gcc 3.2.1 on Darwin 6.3 using the standard procedure; I only had to manually change the order of some definitions in one `fixed' include file. So everybody who really wants to compile the cm3 code generator for her/himself should be able to do so.
  2. You don't need to recompile the code generator at all if you use the binary installation package; if you want to rebuild all the core packages, just specify
                OMIT_GCC=yes ./do-cm3-core.sh buildship
    and it will leave the m3cc package out.

I've added a warning that is issued when building m3cc on PPC_DARWIN; the patched m3cc package is tagged devel_m3cc_d3_1_5.

If anybody finds a way to avoid this bootstrap dependency and use Apple's native compiler to build m3cc, I'd be very interested.
--- end of quote ---

As noted above, the 5.2.0 sources do not contain these changes; to get them, please use either anonymous CVS, CVSup, or the selective package download with appropriate arguments. You'll find all these on the M3 download page at https://modula3.elegosoft.com/ .

Solution: The correct fix seems to be to add -lcc_dynamic when linking dynamic libraries. Thank you to Ben Hines for this hint. I've changed the configuration files for PPC_DARWIN in packages cm3 and cminstall and created new versions devel_cm3_d2_0_4 and devel_cminstall_d0_7_2. These fixes are included in CM3 5.2.4.

5.2 Compilation of m3gc-enhanced fails on PPC_DARWIN

Platforms: PPC_DARWIN

Description: The compilation of package m3gc-enhanced fails on PPC_DARWIN with the following errors:

      new source -> compiling RTHeapDepC.c
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:88:21: sys/msg.h: No such file or directory
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:141: error: parse error before "__unused"
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:141: warning: initialization makes integer from pointer without a cast
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:141: warning: data definition has no type or storage class
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `adjtime':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:176: error: argument `delta' doesn't match prototype
      /usr/include/sys/time.h:180: error: prototype declaration
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `getdomainname':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:447: error: `SYS_getdomainname' undeclared (first use in this function)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:447: error: (Each undeclared identifier is reported only once
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:447: error: for each function it appears in.)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `gethostname':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:473: error: `SYS_gethostname' undeclared (first use in this function)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `mount':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:737: error: argument `type' doesn't match prototype
      /usr/include/sys/mount.h:384: error: prototype declaration
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:745: error: `MOUNT_UFS' undeclared (first use in this function)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:747: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:747: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:748: error: `MOUNT_MFS' undeclared (first use in this function)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:753: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:753: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:755: error: `MOUNT_NFS' undeclared (first use in this function)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:757: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:757: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:758: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:758: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:759: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:759: error: dereferencing pointer to incomplete type
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `quotactl':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:846: error: argument `path' doesn't match prototype
      /usr/include/sys/quota.h:218: error: prototype declaration
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `setdomainname':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:1035: error: `SYS_setdomainname' undeclared (first use in this function)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `sethostname':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:1071: error: `SYS_sethostname' undeclared (first use in this function)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `setitimer':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:1085: error: argument `value' doesn't match prototype
      /usr/include/sys/time.h:184: error: prototype declaration
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `settimeofday':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:1159: error: argument `tp' doesn't match prototype
      /usr/include/sys/time.h:185: error: prototype declaration
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:1159: error: argument `tzp' doesn't match prototype
      /usr/include/sys/time.h:185: error: prototype declaration
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `uname':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:1264: error: `SYS_uname' undeclared (first use in this function)
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c: In function `utimes':
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:1302: error: argument `file' doesn't match prototype
      /usr/include/sys/time.h:186: error: prototype declaration
      ../src/runtime/PPC_DARWIN/RTHeapDepC.c:1302: error: argument `tvp' doesn't match prototype
      /usr/include/sys/time.h:186: error: prototype declaration
      compilation failed => not building library "libm3gcdefs.a"
      Fatal Error: package build failed

Solution: Do not compile m3gc-enhanced on PPC_DARWIN. It won't work as the virtual memory system and several system interfaces are too different from FreeBSD, from which the code was initially copied. m3gc-enhanced and some m3core modules would need a certain amount of work to become useful and allow generational and incremental garbage collection on PPC_DARWIN.

There is a switch -- M3GC_SIMPLE=yes -- which forces compilation of m3gc-simple only and omitting m3gc-enhanced. You use it like this:

      M3GC_SIMPLES=yes ./scripts/do-cm3-core.sh buildlocal

Unfortunately, due to an oversight this switch has not been activated by default for PPC_DARWIN in release 5.2.4, but shortly after. So if you get a version of the scripts dated after the 5.2.4 release, you won't need to specify M3GC_SIMPLES=yes in your environment.

5.3 Problems with efficient exception handling (`stack walkers') and gcc 3.2.1

Platforms: all (principally), SOLgnu

Description: Due to massive changes in gcc, since the upgrade of the code generator backend cm3cg to gcc 3.2.1, the implementation of stack walkers used for efficient exception handling on some platforms (in CM3 currently only SOLgnu, more are concerned in PM3) is broken. Here is an excerpt from an email by John Polstra concerned with this problem:

I have been looking at this today, and the news is not so good. I believe that the current M3 stack walking implementation _cannot_ work with modern GCCs. The M3 implementation builds its own PC range tables. It emits a label marking the start of a code region; then emits the code for the region; and then emits a label marking the end of the region. And it relies on exactly that code remaining between the two labels. But GCC now performs extensive flow analysis and code motion. It will happily move code into or out of the region if it thinks that's a good idea. There is not even a guarantee that the start label will appear before the end label in the generated code.
The SET_LABEL operation in M3's intermediate language has a boolean "barrier" parameter which can be set to TRUE if code motion past the label must not take place, and the front end uses that to try to anchor these kinds of labels in place. But that no longer works with modern GCC. In fact, in my experiments the back end deleted the labels entirely.
As far as I can tell, the only way to accomplish the above is to use GCC's built-in exception support. There is a nice complete API for it -- see "gcc/except.h". I think we would need to change the front end and the intermediate language to pass the higher-level language constructs (TRY...EXCEPT, TRY...FINALLY, etc.) all the way through to the back end. Then GCC would generate the range tables and the code to use them itself. It actually doesn't look very hard to do this, and I'm sure the resulting code would be better than it is now. But I'm not volunteering at the moment. :-)

Solution: None at the moment. If you want to use the gcc 3.2.1-based backend for SOLgnu and other platforms with stack walkers, turn off this feature in cm3/m3-sys/m3middle/src/Target.m3. This will produce less efficient code for exception handling, but perhaps improve code performance in other aspects (untested).

Hint: We are still looking for volunteers to adapt the m3 frontend to the new gcc exception interface :-)

Fix:The stack handler tables have been functional for some time now (since 2003/10/10) on targets that support it (SOLgnu/SOLsun, ALPHA_OSF). As such, stack walkers have been turned on for these targets in their cm3 configuration files. We still should look into adapting the m3 frontend use the gcc exception framework.

5.4 Installation program fails with unhandled OSError exception on SOLgnu platform

Platforms: SOLgnu

Description:cminstall fails with the following message:

***
*** runtime error:
***    Unhandled exception: OSError.E
***    file \"../src/os/POSIX/OSErrorPosix.m3\", line 50
***

Abort

Solution: Use the cm3-min-POSIX-SOLgnu-d5.2.7.tgz instead. The installation program in the 5.2.6 archive is broken. There is no work-around.

5.5 Segmentation fault errors on Fedora 3 and Gentoo Linux

Platforms: Linux

Description: On some Linux Distribution (for example Fedora 3) you get a segmentation fault error message running cm3

Solution: Use the cm3-min-POSIX-LINUXLIBC6-d5.2.7-2005-03-31.tgz release. Previous versions of the cm3 compiler for Linux will not work on these distributions. Changes were made in m3core (tag >= devel_m3core_d2_1_13) and m3gc-enhanced (tag >= devel_m3gc-enhanced_d1_0_6).

6 Release 5.4.X

6.1 Segmentation violations on Linux, compile fails with PklFonts core dumping

Platforms: Fedora Core Linux, Ubuntu and possibly other distributions

Description: All Modula3 programs (including cm3 itself) exit with a segmentation violation. The bootstrap process aborts with:

      cd ../pkl-fonts/LINUXLIBC6 && ./PklFonts > FontData.pkl
      Segmentation fault (core dumped)
    

Solution: Set the LD_POINTER_GUARD environment variable to 0 before running Modula3 programs, using a command like "export LD_POINTER_GUARD=0" or equivalent.

6.2 Unresolved X11 libraries on NetBSD

Platforms: NetBSD

Description: Running Modula3 programs, and hence building cm3, fails due to unresolved symbols to X11 libraries. Example error message: Shared object "libXaw.so.7" not found

Solution: Add the /usr/X11R6/lib directory to /etc/ld.so.conf.

6.3 Issues with /usr/bin/ld on Solaris

Platforms: Solaris

Description: On Solaris, the 5.4 release likely needs to use the GNU ld linker. The GNU linker is expected to be installed as /usr/local/bin/ld. This was done because there were issues with a configure script in the gcc sources of the cm3 compiler backend. It fails to detect linkers properly passed arguments in GNU linker conventions to the native Solaris linker, causing the compile to fail. The installation program lets you decide which linker to use for CM3 package builds, but you may run into problems if you do not use the GNU linker.

Solution: Make sure that /usr/local/bin/ld is GNU ld.

6.4 asm/ipc.h not found on Linux

Platforms: Ubuntu 6.10 (edgy), possibly other distributions.

Description: The compiler complains about a missing asm/ipc.h like this:

 new source -> compiling RTVM.c
 new source -> compiling sysdeps.c
 ../src/runtime/LINUXLIBC6/sysdeps.c:20:21: error: asm/ipc.h: No such
 file or directory
 compilation failed => not building library "libm3gcdefs.a"
 Fatal Error: package build failed
 *** execution of  failed ***

Solution: Frankly, asm/ipc.h is not needed to compile. It is sufficient to delete or comment the lines 19-21 in file m3-libs/m3gc-simple/src/runtime/LINUXLIBC6/sysdeps.c like this:

 // #if __GLIBC__ >= 2 && __GLIBC_MINOR__ >= 1
 // #include <asm/ipc.h>
 // #endif
      

This change has been committed to the repository, but it was too late to be included in the 5.4.0 release.


m3-support{at}elego.de