> There are several issues with your patch.
>
> You should not use $(...) in configure scripts or GNU makefiles.
> It is not portable. Use `...` instead, and know the quoting issues.
I will keep that in mind.
> You have not stated what problems you had with the old setting of
> OSKIT_LIBDIR, so I am dubious about your complex changes to how that is
> done, and your change of the meaning of the variable.
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.
# gcc -print-file-name=oskit
oskit
# gcc -L/usr/local/lib -print-file-name=oskit
oskit
# LIBRARY_PATH=/usr/local/lib gcc -print-file-name=oskit
/usr/local/lib/oskit
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 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 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?
Thanks,
-Neal
--
Neal H Walfield
University of Massachusetts at Lowell
[EMAIL PROTECTED] or [EMAIL PROTECTED]
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
