$prefix was removed as part of the DESTDIR work. However, it was
still used to create the ENGINESDIR_dev and ENGINESDIR_dir variables,
so a restoration is needed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
DESTDIR can't be used on Windows the same way as on Unix, the device
part of the installation paths get in the way.
To remedy this, have INSTALLTOP, OPENSSLDIR and ENGINESDIR get
different values depending on if $(DESTDIR) is empty or not, and use
$(INSTALLTOP), $(OPENSSLDIR) and $(ENGINESDIR) alone.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This is just in case someone passed an inclusion path with the
configuration, and there are OpenSSL headers from another version
in there.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Since corresponding rule was removed from windows-makefile.tmpl out
of necessity, question popped if it's appropriate to harmonize even
unix-Makefile.tmpl. Note that as long as you work on single directory
'make lib<rary>.a' is effectively equivalent to 'make <dir/ectory>'
prior this modification.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Problem with Microsoft lib.exe is that it doesn't *update* modules
in .lib archive, but creates new one upon every invocation. As result
if a source file was updated and nmake was executed, a useless archive
with only one module was created. In other words one has to always
pass all .obj modules on command line, not only recently recompiled.
[This also creates dilemma for directory targets, e.g. crypto\aes,
that were added to simplify every-day life for developer. Since
whole idea behind those targets is to minimize the re-compile time
upon single file modification, the only sensible thing to do is to
omit intended library update.]
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
- User targets are now the same and generally do the same things
- configdata.pm depends on exactly the same files on all platforms
- VMS production of shared libraries is simplified
- VMS automatic dependency files get the extension .D rather than .MMS
Reviewed-by: Rich Salz <rsalz@openssl.org>
'DEPEND[]=file.h' becomes a special way to say that 'file.h' must be
generated before anything else is built. It's likely that a number
of source files depend on these header files, this provides a simple
way to make sure they are always generated even it the dependency data
hasn't been added to the build file yet.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The directories for the final products were never registered, it was
plain luck that intermediary files were in the same place and
registered the directory anyway.
Also, scripts are generated directly from source (binaries go through
intermadiary object files), so we need to explicitely make sure to
avoid registering the source directory unless it's an in source
build.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Previous build scheme allowed building just the stuff in one
subdirectory, like this:
make -C crypto/aes
Because the unified only has a top-level Makefile, this is not
possible with it. This change adds a replacement where each directory
we have something to build in becomes a target in its own right,
allowing building something like this:
make crypto/aes
The exception is the directory test, because we already have such a
target.
Reviewed-by: Stephen Henson <steve@openssl.org>
This applies when building out-of-source.
RT#4486
NOTE: we can't do the same for Unix, as Unix make doesn't handle this
type of issue. Also, directory specs are much less likely to have
spaces on Unix...
Reviewed-by: Matt Caswell <matt@openssl.org>
Someone wants to configure like this:
PERL="/usr/bin/env perl" ./config
The end goal is to get that in the #! line of CA.pl and a few other
scripts. That works well already, but in the Makefile, there were a
few lines looking like this:
PERL=$(PERL) $(PERL) whatever.pl ...
Those need some quoting.
RT#4311
Reviewed-by: Matt Caswell <matt@openssl.org>
Add Configure generated header files to $unified_info{generate}. This
makes sure the build files will pick them up with the rest for the
GENERATED macro, and thereby make sure they get cleaned away by 'make
clean'
Reviewed-by: Rich Salz <rsalz@openssl.org>
Some setups use links inside .git directory and make clean should not
remove them to avoid breaking git meta-information.
Signed-off-by: Cristian Stoica <cristian.stoica@nxp.com>
CLA: none; trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1078)
DJGPP is a 3rd party configuration, we rely entirely on the OpenSSL to
help us fine tune and test. Therefore, it's moved to its own config.
Reviewed-by: Andy Polyakov <appro@openssl.org>
- some Perl versions are allergic to missing ';';
- don't stop if del fails;
- omit unused environment variable;
Reviewed-by: Stephen Henson <steve@openssl.org>
With Unixly Makefiles as well as with nmake, make variables are
transferred to the shell running the commands as envinronment
variables. This principle doesn't apply with MMS, so we must
explicitely define VERBOSE as commands when it's needed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
If environment variables are not explanded early enough, expanded
strings are passed with single backslash to C compiler, e.g.
C:\Program Files, which effectively results in OpenSSL looking for
engines and certificates in C:Program Files.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Some non-Gnu compilers interpret -E -P combination differently.
some prioritize -E over -P, others -P over -E (in which case .i
file is generated and sometimes truncated because of redirection).
Reviewed-by: Richard Levitte <levitte@openssl.org>
When compiling all other C files, rely on the compiler to
automatically pick up the name translation information from the header
files __DECC_INCLUDE_{PRO,EPI}LOGUE.H.
Reviewed-by: Andy Polyakov <appro@openssl.org>
In the case of generating a file like this:
GENERATE[foo.S]=mkfoo.pl arg1 arg2
the 'mkfoo.pl' generator itself might need to include other files,
such as perl modules within our source tree. We can reuse already
existing syntax for it, like this:
INCLUDE[mkfoo.pl]=module/path
or:
DEPEND[mkfoo.pl]=modules/mymodule.pm
This change implements the support for such constructs, and for the
DEPEND statement, for any value that indicates a perl module (.pm
file), it will automatically infer an INCLUDE statement for its
directory, just like it does for C header files, so you won't have do
write this:
DEPEND[mkfoo.pl]=modules/mymodule.pm
INCLUDE[mkfoo.pl]=modules
Reviewed-by: Emilia Käsper <emilia@openssl.org>
The Unix build was the last to retain the classic build scheme. The
new unified scheme has matured enough, even though some details may
need polishing.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This also restores the possibility to have ml used with VC-WIN32 with
no-asm, which was lost during the mk1mf -> unified transition.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Because we have a directory 'test', the target 'test' may be confusing
to make. However, if we make it depend on 'tests', which doesn't
exist, make should never fail to run the actions.
Reviewed-by: Andy Polyakov <appro@openssl.org>
To begin with, the default should have been the import library, not
the DLL itself. However, we don't know what directory it's installed
in either way, so we may as well demand the full path from the user
Reviewed-by: Matt Caswell <matt@openssl.org>
no-stdio does not work with the apps. Since the tests also need the apps
it doesn't support that either. Therefore we disable building of both.
no-autoalginit is not compatible with the apps because it requires explicit
loading of the algorithms, and the apps don't do that. Therefore we disable
building the apps for this option. Similarly the tests depend on the apps
so we also disable the tests. Finally the whole point about no-autoalginit
is to avoid excessive executable sizes when doing static linking. Therefore
we disable "shared" if this option is selected.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The handling was Unix centric, already in Configure. Change that to
just collect the value and let the build file templates figure out
what to do with it.
Reviewed-by: Matt Caswell <matt@openssl.org>
Instead of absolute hard coding of the libz library name, have it use
the macro LIBZ, which is set to defaults we know in case it's
undefined.
This allows our configuration to set something that's sane on current
or older platforms, and allows the user to override it by defining
LIBZ themselves.
Reviewed-by: Matt Caswell <matt@openssl.org>
The macros ZLIB and ZLIB_SHARED weren't appropriately defined,
deviating wrongly from how they worked in earlier OpenSSL versions.
So, restore it so that ZLIB is defined if configured "enable-zlib" and
so that ZLIB and ZLIB_SHARED are defined if configured
"enable-zlib-dynamic".
Additionally, correct the interpretation of the --with-zlib-lib value
on Windows and VMS, where it's used to indicate the actual zlib
zlib library file / logical name, as that can differ depending on zlib
version and packaging on those platforms.
Finally for Windows and VMS, we also define the macro LIBZ with that
file name / logical name when configured "zlib-dynamic", so the
compression unit can pick it up and use it.
Reviewed-by: Matt Caswell <matt@openssl.org>
Since NDEBUG is defined unconditionally on command line for release
builds, we can omit *_DEBUG options in favour of effective "all-on"
in debug builds exercised though CI.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Without proper cleanup after DLL link failure second attempt to
run nmake would actually proceed and failure will be "shifted" to
run time. This is because libcrypto.lib import library is generated
even if DLL link fails.
Reviewed-by: Richard Levitte <levitte@openssl.org>
We used to symlink generate_ssl_tests.pl to the build directory.
Now that the build scripts look for sources in both directories, this
is no longer necessary (see commit
fbd361eaf8).
Reviewed-by: Richard Levitte <levitte@openssl.org>
Currently, SSL tests are configured via command-line switches to
ssltest.c. This results in a lot of duplication between ssltest.c and
apps, and a complex setup. ssltest.c is also simply old and needs
maintenance.
Instead, we already have a way to configure SSL servers and clients, so
we leverage that. SSL tests can now be configured from a configuration
file. Test servers and clients are configured using the standard
ssl_conf module. Additional test settings are configured via a test
configuration.
Moreover, since the CONF language involves unnecessary boilerplate, the
test conf itself is generated from a shorter Perl syntax.
The generated testcase files are checked in to the repo to make
it easier to verify that the intended test cases are in fact run; and to
simplify debugging failures.
To demonstrate the approach, min/max protocol tests are converted to the
new format. This change also fixes MinProtocol and MaxProtocol
handling. It was previously requested that an SSL_CTX have both the
server and client flags set for these commands; this clearly can never work.
Guide to this PR:
- test/ssl_test.c - test framework
- test/ssl_test_ctx.* - test configuration structure
- test/handshake_helper.* - new SSL test handshaking code
- test/ssl-tests/ - test configurations
- test/generate_ssl_tests.pl - script for generating CONF-style test
configurations from perl inputs
Reviewed-by: Richard Levitte <levitte@openssl.org>
Previously, we updated the static libraries (libcrypto.a on Unix,
libcrypto.lib on Windows) with all the object files, regardless of if
they were rebuilt or not. With this change, we only update them with
the object files were rebuilt.
NOTE: this does not apply on VMS, as the expansion of $? may be too
large for a command line.
Reviewed-by: Andy Polyakov <appro@openssl.org>
The logic to find out of there are any .d files newer than Makefile is
sound. Checking the result was less so.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reverts commit 087ca80ad8
Instead of battling the odd format of argv given to main() in default
P64 mode, tell the compiler to make it an array of 64-bit pointers
when compiling in P64 mode.
A note is added in NOTES.VMS regarding minimum DEC C version.
Reviewed-by: Andy Polyakov <appro@openssl.org>
- In Configure, register the perl interpreter used to run Configure,
so that's the one being used throughout instead of something else
that Configure happens to find. This is helpful for using a perl
version that's not necessarely first in $PATH:
/opt/perl/5.22.1/bin/perl ./Configure
- Make apps/tsget a generated file, just like apps/CA.pl, so the
perl interpreter registered by Configure becomes the hashbang path
instead of a hardcoded /usr/bin/perl
Reviewed-by: Andy Polyakov <appro@openssl.org>
There are rare cases when an object file will only be used when
building a shared library. To enable this, we introduce
SHARED_SOURCE:
SHARED_SOURCE[libfoo]=dllmain.c
Reviewed-by: Andy Polyakov <appro@openssl.org>
The warning MAYLOSEDATA3 is one you will always get when compiling
source that calculates the difference between two pointers with
/POINTER_SIZE=64.
The reason is quite simple, ptrdiff_t is always a 32-bit integer
regardless of pointer size, so the result of 'ptr1 - ptr2' can
potentially be larger than a 32-bit integer. The compiler simply
warns you of that possibility.
However, we only use pointer difference within objects and strings,
all of them well within 2^32 bytes in size, so that operation is
harmless with our source, and we can therefore safely turn off that
warning.
Reviewed-by: Rich Salz <rsalz@openssl.org>
On Windows and Unix, the staging directory $(DESTDIR) can simply be
prepended to the installation directory. An attempt was made to do
something similar on VMS, but that ended up being a half measure
solution. Instead of that, simply use the staging directory as a
prefix under which [.OPENSSL-INSTALL] and [.OPENSSL-COMMON] will hold
the two directory trees that should end up in the directories
indicated by --prefix and --openssldir, and finish the installation
with appropriate instructions on what to do next.
Reviewed-by: Rich Salz <rsalz@openssl.org>
- on VMS, SYS$COMMON:[SSL] is already used as installation directory
by HP SSL, so we make our default for --openssldir
SYS$COMMON:[OPENSSL-COMMON] instead.
- Updated notes on default installation dirs fir Unix and Windows
Reviewed-by: Rich Salz <rsalz@openssl.org>
Sometimes, you might end up with a rather long compile line due to
excessively long /INCLUDE directories. Compensate for it by making
a temporary logical name with them and using said logical name as
/INCLUDE argument.
A note was added to NOTES.VMS regarding these limitations.
Reviewed-by: Rich Salz <rsalz@openssl.org>
On VMS, we downcase option names, which means that config names are
downcased as well, so they need to be downcased in the target table to
be found.
Reviewed-by: Rich Salz <rsalz@openssl.org>
In constructions such as 'for x in $(MAKEVAR); do ...', there's the
possibility that $(MAKEVAR) is en empty value. Some shells don't like
that, so introduce a dummy value that gets discarded:
for x in dummy $(MAKEVAR); do
if [ "$$x" = "dummy" ]; then continue; fi
Closes RT#4459
Reviewed-by: Rich Salz <rsalz@openssl.org>
utils/mkrc.pl was added a while ago as a better generator for the
Windows DLL resource file. Finalize the change by removing the
ms/version32.rc generator from Configure and adding resource file
support using mkrc.pl in Configurations/windows-makefile.pl
Reviewed-by: Andy Polyakov <appro@openssl.org>
One of the 'generate' targets depended on $(SRCDIR)/apps/progs.h,
which depended on... nothing. This meant it never got regenerated
once it existed, regardless of need. Of course, we could have it
depend on all the files checked to generate it, but they also depend
on progs.h, so we'd end up getting cricular dependencies, which makes
make unhappy.
Furthermore, and this applies for the other generated files, having
them as targets means that they may be regenerated on the fly in some
cases, and since they get written to the source tree, this isn't such
a good idea if that tree is read-only (which is a possible situation
in an out-of-tree build).
So, we move all the actions to the 'generate' targets themselves, thus
making sure they get regenerated in a controlled manner and regardless
of dependencies.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Some implementations of sed require a newline before an ending '}'.
The easier method is to replace that sed command with the
corresponding perl command.
Closes RT#4448
Reviewed-by: Rich Salz <rsalz@openssl.org>
Depending on what has been built so far, all .d files may not be
present and 'find' will exit with non-zero exit code. This isn't a
bother for us but may break make, so clear the exit code with an added
'exit 0'.
Closes RT#4444
Reviewed-by: Rich Salz <rsalz@openssl.org>
generatesrc() did already receive dependency information, but never
used it, and never really needed to... until now.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Instead of relying on the '-nt' test operator, which doesn't exist
everywhere, use find's '-newer' to find out if any of the known .d
files is newer than Makefile.
Closes RT#4444
Reviewed-by: Andy Polyakov <appro@openssl.org>
On Windows, we set INSTALLTOP to default as follows:
VC-WIN32:
PREFIX: %ProgramFiles(x86)%\OpenSSL
OPENSSLDIR: %CommonProgramFiles(x86)%\SSL
VC-WIN64*:
PREFIX: %ProgramW6432%\OpenSSL
OPENSSLDIR: %CommonProgramW6432%\SSL
Should those environment variables be missing, the following is used
as fallback:
PREFIX: %ProgramFiles%\OpenSSL
OPENSSLDIR: %CommonProgramFiles%\SSL
Reviewed-by: Andy Polyakov <appro@openssl.org>
This is a living document, everyone is encouraged to add to it.
Implementation details as well as broader implementation philosophy
has a place here.
I'm starting with documentation of the how conditions in build.info
files are treated.
Reviewed-by: Rich Salz <rsalz@openssl.org>
In most builds, we can assume that engines live in the build tree
subdirectory "engines". This was hard coded into the tests that use
the engine ossltest.
However, that hard coding is tedious, it would need to be done in
every test recipe, and it's an incorrect assumption in some cases.
This change has us play it safe and let the build files tell the
testing framework where the engines are.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
util/mkdef.pl assumes it knows what the resulting library name will
be. Really, it shouldn't, but changing it will break classic native
Windows builds, so we leave it for now and change the LIBRARY line
externally when needed instead.
Reviewed-by: Matt Caswell <matt@openssl.org>
Normally we always refer to source files relative to $SRCDIR in Makefiles.
However the reference to unix-Makefile.tmpl was using a fully expanded
absolute path. This can cause problems for Mingw.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
In unix-Makefile.tmpl, this construction has been used a few times
if ! something; then ...
It seems, though, that some shells do not understand !, so these need
to be changed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
When passing down values to Makefile.shared, do so with single quotes
as much as possible to avoid having the shell create a mess of quotes.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The variable SHARED_CFLAGS and SHARD_LDFLAGS were used in the Unix
template because they normally contain options used when building
"shared". The Windows template, on the other hand, uses LIB_CFLAGS,
to express the intended use of those flags rather than their content.
The Windows template still used SHARED_LDFLAGS, which seems
inconsistent.
To harmonize the two, any SHARED_CFLAGS gets renamed to LIB_CFLAGS and
SHARED_LDFLAGS to LIB_LDFLAGS. That makes the intent consistent along
with BIN_{C,LD}FLAGS and DSO_{C,LD}FLAGS.
Finally, make sure to pass down $(LIB_CFLAGS) or $(DSO_CFLAGS) along
with $(CFLAGS) when using Makefile.shared.
Reviewed-by: Rich Salz <rsalz@openssl.org>
It turns out that different sed implementations treat -i differently
to cause issues. make it simpler by avoiding it entirely and give
perl the trust to be consistent enough.
Reviewed-by: Rich Salz <rsalz@openssl.org>
If pre-processor failed, an empty .s file could be left behind,
which could get successfully compiled if one simply re-ran make
and cause linking failures. Not anymore. Remove even intermediate .S
in case of pre-processor failure.
Reviewed-by: Richard Levitte <levitte@openssl.org>
One of them didn't clean away .d.tmp files properly.
The other would overwrite the .d files unconditionally, thereby
causing a possibly unnecessary dependency rebuild, which touches the
date of Makefile, which causes a possibly unnecessary rebuild of
buildinf.h and everything that depends on that.
Reviewed-by: Andy Polyakov <appro@openssl.org>
The source file generators sometimes use $(CC) to post-process
generated source, and getting the inclusion directories may be
necessary at times, so we pass them down.
RT#4406
Reviewed-by: Rich Salz <rsalz@openssl.org>
The reason for this is that the static libraries and the DLL import
libraries are named the same on Windows. When configured "shared",
the static libraries are unused anyway.
Reviewed-by: Rich Salz <rsalz@openssl.org>
