Re: [Bug-hurd] [pathc] oskit-mach build fix

[Roland McGrath]

> Sorry for the lack of explanation. I installed oskit into the default
> location, i.e. /usr/local.  When the configure script ran ``gcc
> -print-file-name=oskit'', it returned `oskit', ie, it never found it
> but it did not complain and fail.  When I tried using a -L in the
> check, it also failed; only using LIBRARY_PATH could I make it work.

Interesting.  Well, the check should probably be redesigned modelled after
other packages' autoconf checks for miscellaneous libraries and headers.
The only reason I took this route was to locate the explicit directory
names where oskit's oskit/*.o would be installed.  Since those files don't
match the -lfoo name patterns, they need to be explicitly specified on the
link lines.

This old check probably works if you use the x86-oskit-gcc wrapper script
that comes with oskit.  I really don't recall, but that is probably what I
tested it with (and I wrote that part of the oskit install too).

> I changed the meaning of the variable slightly as it assumes that the
> oskit install is in a place where the liboskit_*.a libraries can be found
> by default.

I don't know what you mean by "found by default".  The presumption is as
for all libraries expected to be preinstalled and used by a GNU package:
your CC/CFLAGS/LIBS settings when you run configure will provide the
environment you need.

> I have a second installation of oskit (a different version)
> in /usr/local/oskit-VERSION and I would like to compile it from time to
> time.  This would have required a lot more work on the old version.

I don't see how.  "CC=/usr/local/oskit-VERSION/bin/x86-oskit-gcc configure"
probably would work.

> > I would never suggest setting LIBRARY_PATH.  That is a bizarre
> > compatibility variable.  The setting of CC ought to be sufficient.
> > Use -L options in the CC setting if that is appropriate.
> > 
> > The -L switches you added in the linking rules should not be required.
> > If the configure check succeeds, that means the CC setting suffices.
> 
> What is the correct way to use alternative libraries?

Use -L.  The trouble here is that we need to find the special .o files too
(the startup files), and the toolchain doesn't make it so easy for things
other than libfoo.{a,so} libraries.  (We also want to have nice
dependencies on the oskit installed libraries and so forth, since that is
handy for development, but that is secondary.)  The x86-oskit-gcc wrapper
script uses gcc a specs file to handle finding those object files.
.