This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Next configuration patch for *-*-freebsd


Hi Bryce,

Thank you for commenting on my first attempt at a patch.
Unfortunately, I can provide some more information than I did when I
first posted the patch.  I am sorry I forgot to include some knowledge
I had gained while developing this approach many months ago.  Before
posting this information, I have now verified that nothing I
understood to be true back then has changed.

In article <3AF8C266.33197EA6@waitaki.otago.ac.nz>,
Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

> I dont think this (messing with liborig) part is correct.

OK, I could agree with you (especially since we are now distributing
port configuration information to points all over the gcc tree and
rarely keeping all in sync) and would be happy to do it another way...

> It seems to me from looking at gcc/config/freebsd.h that the
> compiler should already be using -lc_r in the -pthread case, so

[Yup, it surely does when -pthread was provided on the *command* line.
 But libjava is now hacking the lib spec behind the back of a port.
 It is unclear that this usage was ever considered when spec files
 were first designed.]

> wouldn't we be better off figuring out why -lc is being used rather
> than working around it in libgcj.spec?

[Based on this question, you are assuming that %{`S':[...]} constructs
 in specs are suppose to consider -S being found earlier in the spec
 line instead of only on command lines.  Based on my current
 understanding, only -S found on the command line is so considered.
 Do you know who the final authority is on that matter?]

...but, are you aware that when a (e.g.) lib spec contains

[...] %{!pthread:-lc} %{pthread:-lc_r}

-pthread is only processed within those spec constructions when given
as a command line argument not when found in [...]?

I know because I tried to write my libjava configuration patch in this
obviously manner before going down the path of my posted patch... ;-)

My entire understanding was gained by reading ``Spec Files::Specifying
subprocesses and the switches to pass to them'' and hacking around
with a live spec file.

If, after reading this reply, you still feel that the best way to
support this platform requirement is to change the way spec lines are
parsed, then will you support my attempt to change that part of the
compiler front-end?  When I say ``support'', I only mean help me
convince the gcc driver maintainer why this feature should be added
there instead of in a libjava configuration patch not write that patch
for me.

> Maybe the "!shared" in freebsd.h's LIB_SPEC has something to do with it?

I am no spec expert, but I don't think so.  Here is the exact usage in
freebsd.h:

#define LIB_SPEC "                                                      \
  %{!shared:                                                            \
    %{!pg:                                                              \
      %{!pthread:-lc}                                                   \
      %{pthread:-lc_r}}                                                 \
    %{pg:                                                               \
      %{!pthread:-lc_p}                                                 \
      %{pthread:-lc_r_p}}                                               \
  }"

All that outer construction says is that if -shared was provided on
the command line then do not provide a reference to any C library.
This ensure that no dependencies are placed on newly constructed
shared libraries.  [BTW, to anyone that reads this, I have already
read RTH's eloquent words on why all ELF ports should consider
switching to the model used on Linux (when USE_GNULIBC_1 is not
defined) but we have not done that yet.  Making that particular change
is not my department... although I have lobbied for it.]

Regards,
Loren


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]