Re: PATCH: Objective-C testsuite on Solaris 2.8

[Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>]

Kaveh R. Ghazi writes:

> I think we need a more general solution than what you installed.
> Though I haven't yet had any luck getting the patch Rainer proposed to
> work.  (I may be doing something wrong though.)

I haven't worked on implementing/testing my last proposed patch recently
either, both due to lack of time and frustration about many of my patches
not being reviewed for more than two months.

Nonetheless, I've thought a bit more about the problem and came to the
following diagnosis:

* By default, libobjc is built non-shared only (due to AC_DISABLE_SHARED in
  libobjc/configure.in) and installed in $(libsubdir).  This is fine until
  libobjc depends on additional library for it's implementation (like the
  -lrt/-lposix4 stuff on Solaris 2.6 and up or Tru64 UNIX V4/5).  In that
  case, anyone user linking an Objective C program needs to know to invoke
  gcc (the only driver that knows about objc) like this:

	gcc -o prog prog.m -lobjc -lrt

  Even linking with libtool doesn't help in this situation since
  -L$(libsubdir) which is needed to find libobjc.a (and libobjc.la) is only
  passed internally by gcc, so libtool wouldn't find libobjc.la and know to
  link the dependent libraries either.

* If I configure gcc with --enable-shared (like I did), a shared libobjc.so
  is built and installed in $(libsubdir) as well.  With my patch mentioned
  by Kaveh to detect the need for -lrt/-lposix4, this dependency is
  recorded in libobjc.so, so the dependency is fulfilled at runtime and the
  testsuite works on Solaris 8 and Tru64 UNIX V5.1 as reported earlier,
  thanks to libobjc.exp setting LD_LIBRARY_PATH appropriately so libobjc.so
  can be found at runtime.

  Unfortunately, this doesn't really help either: consider a user linking
  an objc program now:

	gcc -o prog prog.m -lobjc

  will link, but this cannot run: libobjc.so is installed in $(libsubdir)
  and the runtime linker won't know how to find it.  While it is currently
  considered appropriate for C++ users to know to link with

	g++ -R$(libdir) -o prog prog.cc

  to get a working C++ program (where ld.so finds libstdc++ at runtime),
  for Objective C the user would need to use

	gcc -R$(libsubdir) -o prog prog.m -lobjc

  where libsubdir isn't easily available, but is something like

	/vol/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.0

  He could get at it e.g. using

	dirname `gcc -print-file-name=libobjc.so`,

  but I consider something like this completely unacceptable.  In fact, the
  whole mess of gcc/g++ not specifying runpaths necessary to create
  executable binaries by default is the problem causing the most questions
  about g++ here and needs to be urgently resolved to make the compilers
  usable for non-expert users.

  Another problem with this location of a shared libobjc.so is as follows:
  consider installing gcc 3.1 which comes with libobjc.so.2.0.0 instead of
  the current libobjc.so.1.0.0.  In general, after upgrading to a new
  version of the compiler, I can easily remove the old one and just leave
  old shared libraries in $(libdir) in place so old binaries continue to
  run.  In this case, I either need to keep just this old libobjc.so
  around, or even the whole gcc 3.0 installation.

  In short, since it's now possible to build and install a shared libobjc,
  it belongs into $(libdir), not $(libsubdir).  The decision to disable
  building a shared libobjc by default needs to be reconsidered: I have no
  idea why this was done and unless there are strong technical reasons to
  keep it this way, it should use the platform default like
  e.g. libstdc++.so.3 does.

Considering all this, here's what I think needs to be done: for platforms
that don't support shared libraries (or when they have been disabled by the
installer), there needs to be a way to link Objective C programs without
the programmer needing to be aware of libraries used by the libobjc
implementation (and even the need to link with -lobjc).  Since this list is
platform dependent, I think the obvious approach is to provide a gobjc (or
whatever it is called) along the lines of the g++ and gcj drivers which are
aware of the need to e.g. link additional libraries.  libjava may already
depend on -lrt/-lposix4 to provide sched_yield, so I think its best to
follow the gcj lead where this information is encoded in a libjava.spec
which has the appropriate runtime libraries substitute at configure time.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University

Email: ro@TechFak.Uni-Bielefeld.DE