Open CendioOssman opened 2 years ago
What do you mean by handled correctly?
LIBRARY_PATH is used by gcc in native configurations, which is backwards from what you're describing and also requires no special handling on the part of perl-cross. The correct handling is to leave it in the environment, unchanged.
I've never heard of HOSTLIBRARY_PATH and neither has Google apparently.
I'm talking about this section here, where special HOST*
versions of some compiler variables are used:
$LIBRARY_PATH
would be slightly different in that it is picked up by the compiler rather than the configure script, but the principle is similar from a user point of view.
Ok, and what should configure do about these variables in your opinion?
To clarify, I have a rough idea of what you're trying to do, but I don't understand what exactly you want changed in perl-cross specifically and why doing that would be a good idea.
My idea is basically this:
When you do normal builds, you set CFLAGS
and LDFLAGS
to get the proper settings you need. perl-cross is nice enough to magically handle these so that they still apply to the output binaries, even though you are now doing both native builds and cross builds.
In the same line of reasoning, for a normal build you could be using LIBRARY_PATH
instead of using LDFLAGS
to get the proper settings. This is where the magic in perl-cross currently no longer works as those settings are applied to the native binaries instead of the output ones.
So in order to have perl-cross continue along the principle of "just do what you do for a native build and perl-cross will sort everything out for a cross build", I think the following needs to be added:
LIBRARY_PATH
, and change HOSTLIBRARY_PATH
to LIBRARY_PATH
(if it exists)LIBRARY_PATH
.There might be more to it though, I haven't dug that deep in to perl-cross. These variables need to have the above behaviour as ld
is run, not just during the configure stage.
In our build system we sometimes use
$LIBRARY_PATH
rather than$LDFLAGS
to control where the compiler searches for libraries. It would be a nice future feature if that variable could also be handled correctly, i.e. a separate$LIBRARY_PATH
and$HOSTLIBRARY_PATH
.