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)
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
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 workaround, 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 workaround for that, too. Voluntary contributions in this area are more than welcome. This workaround 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 workaround 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.
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.