47eeaf45b5
So far, we've placed all extra library related flags together, ending
up in the make variable EX_LIBS. This turns out to be problematic, as
for example, some compilers don't quite agree with something like
this:
cc -o foo foo.o -L/whatever -lsomething
They prefer this:
cc -L/whatever -o foo foo.o -lsomething
IBM's compiler on OS/390 is such a compiler that we know of, and we
have previously handled that as a previous case.
The answer here is to make a more general solution, where linking
options are divided in two parts, where one ends up in LDFLAGS and
the other in EX_LIBS (they corresponds to what is called LDFLAGS and
LDLIBS in the GNU world)
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5033)
16 lines
593 B
Text
16 lines
593 B
Text
# We can't make any commitment to support the DJGPP platform,
|
|
# and rely entirely on the OpenSSL community to help is fine
|
|
# tune and test.
|
|
|
|
my %targets = (
|
|
"DJGPP" => {
|
|
inherit_from => [ asm("x86_asm") ],
|
|
cc => "gcc",
|
|
cflags => "-I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall",
|
|
sys_id => "MSDOS",
|
|
lflags => add("-L/dev/env/WATT_ROOT/lib"),
|
|
ex_libs => add("-lwatt"),
|
|
bn_ops => "BN_LLONG",
|
|
perlasm_scheme => "a.out",
|
|
},
|
|
);
|