>>> # ./config -mx32 >>> Operating system: x86_64-whatever-linux2 >>> Configuring for linux-x86_64 >>> >>> Perhaps the second case should fail at configure just like the first >>> case. Upon failure, it would be nice to tell the user what to do: >>> "Please configure with ./Configure linux-x32" >> >> Well, there is a trade-off. Special cases are too numerous to cover them >> all, so question would be if this would be common and grave enough to >> guard against. For example you can actually run ./Configure >> tru64-alpha-cc on your Linux computer. Running make would fail >> miserably, but would it give you right to say "you're not allowed to >> break the compile"? > > Kinda agree. I image there could be many cases like you describe.
One word in the context, cross-compile. > In this case, there's not "too many" or "too numerous". There's only > one item of interest: -mx32. And it might be one too many :-) > When Configure ignores it, But it doesn't, it does pass it down as additional flag to compiler... > it results in a failed compile. Well, Configure is deliberately liberal to allow all kinds of local adaptations. Yes, you can screw things up [easily], but you've got to appreciate the flexibility it provides. Suggestion seems to be to classify flags as generic adaptations and ones that might affect choice of platform. I'd say "no" to that. What one can discuss is to have ./config (not ./Configure) detect x32 environment and pass alternative config line to ./Configure. That's how it worked so far and I see no reason to change it by moving platform detection logic to ./Configure. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4583 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev