> 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.
.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
