err.no Git - sope/blob - libFoundation/README.sparc

   1 GNU Objective-C/libFoundation on SPARC README
   2 =============================================
   3
   4 Intro
   5 =====
   6
   7     Some people may have problems with libFoundation together with
   8     SPARC machines and/or with GNU Objective-C on SPARC in
   9     general. Here are collected some known issues.
  10
  11 Dates
  12 =====
  13
  14     There may be a problem with incorrect dates, but I couldn't
  15     reproduce it on our SPARC/Solaris 2.6. If you want to ensure that
  16     it works on your system, try this:
  17
  18       if (time(NULL) != (time_t)([[NSDate date] timeIntervalSince1970]))
  19         NSLog(@"timezone correction error");
  20
  21     If this shows the error, something is probably wrong.
  22
  23 ObjC-Runtime
  24 ============
  25
  26     Sometimes the Objective-C runtime of gcc/egcs is configured incorrectly.
  27     In this case configure won't be able to run some libFoundation tests,
  28     eg the check for the Objective-C runtime and the check whether nested
  29     functions work in cc1obj.
  30
  31     The output of configure looks like this:
  32
  33         checking for the Objective-C runtime...
  34         Cannot determine the Objective-C runtime! Probably you have to specify
  35         some additional libraries needed to link an ObjC program, so please take
  36         a look in the config.log file to see the reason and try again.
  37
  38         ... and ...
  39
  40         checking if the Objective-C compiler crashes with nested functions... yes
  41
  42     Usually this happens if the runtime was configured to be threaded, in this
  43     case a combination of -lthread, -lposix or -lposix4 may be necessary or if
  44     no threading is required, egcs should be recompiled with the configure option
  45     --with-threads=single.
  46
  47 Multithreading
  48 ==============
  49
  50     If you want to use the NSThread class in libFoundation you have to
  51     do several things, it applies to Solaris in general:
  52
  53        - Compile the GNU Objective-C runtime with either
  54          --enable-threads=solaris or --enable-threads=posix (I would
  55          recommend 'solaris', Posix is just a layer on top of it).
  56          Watch out that the runtime files are compiled with
  57          -D_REENTRANT, otherwise something is wrong.
  58
  59        - Compile _all_ your files (including libraries) with the
  60          -D_REENTRANT preprocessor flag. This makes the Solaris system
  61          libraries thread-safe (like stdio.h or stdlib.h). In the future
  62          the gstep-make package should do this automatically, but watch
  63          out that the compilation is actually done this way !  - Do
  64          never forget to link against 'thread' and if you selected
  65          'posix' for the runtime against 'posix' (use the LDFLAGS
  66          -lthread). There won't be any linking error if you don't, the
  67          program just won't be able to fork new threads. Thread creation
  68          errors are not catched by some versions of the runtime and/or
  69          library.
  70
  71     If you watch out for these things Solaris will be one of the best
  72     MT environments because of it's M-M threading approach.  For more
  73     Solaris threading info take a look on:
  74
  75         http://www.sun.com/workshop/threads/index.html
  76
  77     It contains some of the information mentioned above and much more.
  78
  79 Dynamic Invocations (forward::, forwardInvocation:)
  80 ===================================================
  81
  82     There are problems related to SPARC with the Objective-C runtime
  83     and there may be problems with NSMethodSignature and/or
  84     NSInvocation.
  85
  86     First the runtime probably won't work correctly (to be exact, the
  87     objc_msg_sendv function). According to Richard Henderson from
  88     Cygnus this is because:
  89
  90         "__builtin_apply will not work on any machine that doesn't simply push
  91          arguments on the stack."
  92
  93     Since objc_msg_sendv relies on __builtin_apply it won't work too. There is
  94     a patch for gcc-2.8.0 on
  95
  96         ftp://alpha.gnu.org/pub/gnu/gnustep/contrib/gcc-2.8.0-sparc.diff
  97
  98     which apparently fixed the problem for me. The patch works with
  99     egcs-1.0.3 as well and for egcs>1.1 with small modifications. It
 100     works on the machine description file (gcc/config/sparc/sparc.md)
 101     for SPARC.  Regarding this patch Richard Henderson said:
 102
 103         "The extention is an abomination and should be removed."
 104
 105     and
 106       ---snip---
 107         I should have mentioned that the proper way to do something
 108         like what objc is trying to do with __builtin_apply is to use
 109         a library like libffi.
 110
 111            ftp://ftp.cygnus.com/pub/home/green/libffi-1.20.tar.gz
 112       ---snap---
 113
 114     So apparently there is a much bigger problem with it in general. I
 115     found the homepage of libffi on this URL:
 116
 117         http://www.cygnus.com/~green/libffi.html
 118
 119     Maybe one should take a look whether this library can be
 120     integrated with the runtime.
 121
 122     Addition: After some discussion with Ovidiu it seems that
 123     __builtin_apply is really broken. Libffi is a library which is
 124     somewhat like NSMethodSignature and NSInvocation, it's nice, but
 125     not 'what objc is trying to do'. Forwarding just saves/restores
 126     all args and doesn't attempt to process them, as libffi
 127     does. Libffi might be used to implement NSInvocation on system for
 128     which no port exists.
 129
 130 ---
 131 1999-05-25
 132 Helge Hess (hh@mdlink.de)
 133 MDlink online service center
 134
 135 ! Local variables:
 136 ! mode: indented-text
 137 ! End: