This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Objective-C testsuite on Solaris 2.8
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: PATCH: Objective-C testsuite on Solaris 2.8
- From: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- Date: Sat, 12 May 2001 00:32:19 +0200 (MEST)
- Cc: mark at codesourcery dot com, gcc-patches at gcc dot gnu dot org
- References: <200105112156.RAA28334@caip.rutgers.edu>
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