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
General problems and notes applying to all releases:
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.
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.
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.
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.
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.
Problems and notes specific to release 5.1.0:
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
Problems and notes specific to release 5.1.1:
Problems and notes specific to release 5.1.8:
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.
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.).
/usr/local/cm3/pkg/m3core/TARGET/.M3EXPORTS /usr/local/cm3/pkg/libm3/TARGET/.M3EXPORTSand 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)
cd WORK/cm3/scripts ./do-pkg buildship m3core ./do-pkg buildship libm3This will put the correct paths in the .M3EXPORTS files.
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.
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:
OMIT_GCC=yes ./do-cm3-core.sh buildshipand 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.
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.
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.
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.
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).
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.
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.
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.
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.