specs file question

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

I am attempting to rework a patch I recently submitted for libjava
which enables threading support for another port.  The rework is to
help remove some entropy instead of adding to it.

Here is the issue:

Currently, libjava uses spec renaming to redefine %(lib) while using
its contents.  Here is a portion of the wrapper spec file used by
libgcj before being processed by the standard autoconf/automake process:

%rename lib liborig
*lib: -lgcj -lm @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) %(liborig)

All currently supported libjava ports which support threads assume
that THREADSPEC is a standard library specification (i.e. -lpthread)
not a switch which must be interpreted by the original %(lib) spec for
proper operation.

In order to make this a real example, here is what libgcj.spec looks
like after pre-processing and after the original %(lib) is inserted
into it:

*lib: -lgcj -lm -lgcjgc -pthread -lzgcj %(libgcc) \
%{!shared:%{!pg:%{!pthread:-lc}%{pthread:-lc_r}} \
	   %{pg:%{!pthread:-lc_p}%{pthread:-lc_r_p}}}

By my reading of the documentation for spec files, review of the spec
handling code in gcc.c and some trial-and-error; it appears that
switches which are normally provided on the command line
(i.e. -pthread in this case) are not interpreted if provided in
THREADSPEC and there appears to be no way to force such
interpretation.

If my study is correct, I see a few ways around it:

(1) This is an outline of how my current patch
    [http://gcc.gnu.org/ml/java-patches/2001-q2/msg00202.html] works:
    (a) Setup a level of indirection to only add %(liborig) for those
    ports which may add a library to the link line to support
    threading. (b) Set THREADSPEC to the low-level library that
    provides threading.

    This is a bad direction (for all existing supported platforms and
    future ones added) since more special knowledge is being copied
    from gcc/config to libjava/*.

(2) Enhance the spec language to allow something to be placed in the
    new %(lib) spec at @THREADSPEC@ such that it can be treated just
    as a command-line option which will then affect the parsing of
    %(liborig).  Other plausible enhancements to the spec language are
    available.

    Downside: Extending the spec language is not my idea of a fun
    time.  Upside: If @THREADSPEC@ could be written in terms of things
    defined in gcc/config/*.h, then we win.

Having just looked closely at the threading model used over in
libobjc, I can also think of at least one off-the-wall improvement
that would fix the situation well enough for my port (and might also
be considered a general improvement of the state of things):

(3) (For platforms that support it:) libjava could be modified to
    declare the threading interface to be weak entry points as libgcc
    does, and thus libobjc does as well.  That way it would build and
    run with or without the threading library being provided.  It
    would be up to the user to provide -lpthread, -pthread, -pthreads,
    -threads or whatever when they actually want the thread interface
    to be active.  In this case, I would just unset THREADSPEC for
    this port (and all ports where the thread library could be safely
    optionally-provided) and let the invoker of gcj decide when to
    link against the thread library.

Since neither Bryce nor I is a specs expert, any input would be
greatly appreciated so I don't have to commit my complexity-enhancing
patch.

Regards,
Loren