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>
This introduces the settings loutflag and aroutflag, because different
Windows tools that do the same thing have different ways to specify
the output file.
The Borland C++ config is commented away for the monent, perhaps
permanently.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This change is a bit more complex, as it involves several recipe
variants.
Also, remove the $(CROSS_COMPILE) prefix for the makedepend program.
When we use the program "makedepend", this doesn't serve anything,
and when we use the compiler, this value isn't even used.
Reviewed-by: Rich Salz <rsalz@openssl.org>
VMS doesn't have "makedepend" anyway, so this is just a matter of using
the right qualifiers when 'makedepend' is enabled.
Reviewed-by: Rich Salz <rsalz@openssl.org>
For assembler, we want the final target to be foo.s (lowercase s).
However, the build.info may have lines like this (note upper case S):
GENERATE[foo.S]=foo.pl
This indicates that foo.s (lowercase s) is still to be produced, but
that producing it will take an extra step via $(CC) -E. Therefore,
the following variants (simplified for display) can be generated:
GENERATE[foo.S]=foo.pl => foo.s: foo.pl
$(PERL) $foo.pl $@.S; \
$(CC) $(CFLAGS) -E -P $@.S > $@ && \
rm -f $@.S
GENERATE[foo.s]=foo.pl => foo.s: foo.pl
$(PERL) $foo.pl $@
GENERATE[foo.S]=foo.m4 => foo.s: foo.m4
m4 -B 8192 $foo.m4 > $@.S; \
$(CC) $(CFLAGS) -E -P $@.S > $@ && \
rm -f $@.S
GENERATE[foo.s]=foo.m4 => foo.s: foo.m4
m4 -B 8192 $foo.m4 > $@
Reviewed-by: Andy Polyakov <appro@openssl.org>
Make all scripts produce .S, make interpretation of $(CFLAGS)
pre-processor's responsibility, start accepting $(PERLASM_SCHEME).
[$(PERLASM_SCHEME) is redundant in this case, because there are
no deviataions between Solaris and Linux assemblers. This is
purely to unify .pl->.S handling across all targets.]
Reviewed-by: Richard Levitte <levitte@openssl.org>
For config targets such as 'dist', which doesn't have a BASE template,
we still need to have a default build scheme.
Additionally, the unified Makefile template's target 'tar' wasn't
quite as flexible as the unixmake one.
Finally, .travis-create-release.sh can be somewhat simplified now that
it builds with the unified build scheme.
Reviewed-by: Matt Caswell <matt@openssl.org>
Should it be needed because the recipes within a RAW section might
clash with those generated by Configure, it's possible to tell it
not to generate them with the use of OVERRIDES, for example:
SOURCE[libfoo]=foo.c bar.c
OVERRIDES=bar.o
BEGINRAW[Makefile(unix)]
bar.o: bar.c
$(CC) $(CFLAGS) -DSPECIAL -c -o $@ $<
ENDRAW[Makefile(unix)]
Reviewed-by: Rich Salz <rsalz@openssl.org>
In some cases, one might want to generate some source files from
others, that's done as follows:
GENERATE[foo.s]=asm/something.pl $(CFLAGS)
GENERATE[bar.s]=asm/bar.S
The value of each GENERATE line is a command line or part of it.
Configure places no rules on the command line, except the the first
item muct be the generator file. It is, however, entirely up to the
build file template to define exactly how those command lines should
be handled, how the output is captured and so on.
Reviewed-by: Rich Salz <rsalz@openssl.org>
When object files with common block symbols are added to static
libraries on Darwin, those symbols are invisible to the linker that
tries to use them. Our solution was to use -fno-common when compiling
C source.
Unfortunately, there is assembler code that defines OPENSSL_ia32cap_P
as a common block symbol, unconditionally, and in some cases, there is
no other definition. -fno-common doesn't help in this case.
However, 'ranlib -c' adds common block symbols to the index of the
static library, which makes them visible to the linker using it, and
that solves the problem we've seen.
The common conclusion is, either use -fno-common or ranlib -c on
Darwin. Since we have common block symbols unconditionally, choosing
the method for our source is easy.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
We copied $target{cflags}, $target{defines} and a few more to %config,
just to add to the entries. Avoid doing so, and let the build templates
deal with combining the two.
There are a few cases where we still fiddle with %target, but that's
acceptable.
Reviewed-by: Andy Polyakov <appro@openssl.org>
The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags. Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.
Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).
Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.
The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config. Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: Andy Polyakov <appro@openssl.org>
Instead, make the build type ("debug" or "release") available through
$config{build_type} and let the configs themselves figure out what the
usual settings (such as "cflags", "lflags" and so on) should be
accordingly.
The benefit with this is that we can now have debug and release
variants of any setting, not just those Configure supports, and may
also involve other factors (the MSVC flags /MD[d] and /MT[d] involve
both build type and whether threading is enabled or not)
Reviewed-by: Andy Polyakov <appro@openssl.org>
Configure had the Unix centric addition of -lz when linking with zlib
is enabled, which doesn't work on other platforms. Therefore, we move
it to the BASE_unix config template and add corresponding ones in the
other BASE_* config templates. The Windows one is probably incomplete,
but that doesn't matter for the moment, as mk1mf does it's own thing
anyway.
This required making the %withargs table global, so perl snippets in
the configs can use it.
Reviewed-by: Andy Polyakov <appro@openssl.org>
These BASE templates are intended to hold values that are common for
all configuration variants for whole families of configurations.
So far, three "families" are identified: Unix, Windows and VMS, mostly
characterised by the build system they currently use.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This has no real meaning, except it gives Configure a hint that VC
targets are indeed capable of producing shared objects.
Reviewed-by: Matt Caswell <matt@openssl.org>
There are cases, for example when configuring no-asm, that the added
uplink source files got in the way of the cpuid ones. The best way to
solve this is to separate the two.
Reviewed-by: Andy Polyakov <appro@openssl.org>
When building with GNU C, clang or VMS C, it's more efficient to
generate dependency file and object file in one call rather than two.
Have the dependency output in a temporary file and compare it with the
previous one if available to see if replacement is waranted, thereby
avoiding unnecessary reconstruction of Makefile / descrip.mms.
Github issue #750
Reviewed-by: Rich Salz <rsalz@openssl.org>
I read the PROBLEMS, and they're outdated; nothing I'd put in the
online FAQ, for example. Test-builds work without using these files.
Had to remove the rehash.time stuff from Makefile.in
Reviewed-by: Richard Levitte <levitte@openssl.org>
They now default to " " as separator, but that can be overridden by
having a hash with parameters as last argument. The only currently
recognised parameter is `separator'.
The special separator `undef' will force the result to become a list
rather than a concatenated string.
Reviewed-by: Andy Polyakov <appro@openssl.org>
If the local system doesn't have GNU C or clang, and not even
makedepend, the build will stop because the call of 'makedepend'
fails. This changes so the build won't stop because of such failure.
The result will be empty .d files, and that's ok.
Reviewed-by: Rich Salz <rsalz@openssl.org>
These flags are limitting needlessly, are often patched by packagers,
and should be specified on the configuration command line by anyone
who desires for it to be specific rather than forced by us.
This work was already done with mingw when those configs were worked
on, now it gets applied to the remaining configs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
GNU make will re-exec if (it thinks that) the Makefile has changed.
Just having the target Makefile seems to make it think it has, so we
end up in a look where GNU make re-execs for ever.
The fix is easy, just remove the Makefile target and have the depend
target run the recipe on its own instead of depending on Makefile.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This takes us away from the idea that we know exactly how our static
libraries are going to get used. Instead, we make them available to
build shareable things with, be it other shared libraries or DSOs.
On the other hand, we also have greater control of when the shared
library cflags. They will never be used with object files meant got
binaries, such as apps/openssl or test/test*.
With unified, we take this a bit further and prepare for having to
deal with extra cflags specifically to be used with DSOs (dynamic
engines), libraries and binaries (applications).
Reviewed-by: Rich Salz <rsalz@openssl.org>
So far, MingW shared libraries were named like this
libeay32.dll + libeay32.dll.a
ssleay32.dll + ssleay32.dll.a
That naming scheme is antiquated, a reminicense of SSLeay. We're
therefore changing the scheme to something that's more like the rest
of OpenSSL.
There are two factors to remember:
- Windows libraries have no recorded SOvers, which means that the
shared library version must be encoded in the name. According to
some, it's unwise to encode extra periods in a Windows file name,
so we convert version number periods to underscores.
- MingW has multilib ability. However, DLLs need to reside with the
binaries that use them, so to allow both 32-bit and 64-bit DLLs to
reside in the same place, we add '-x64' in the name of the 64-bit
ones.
The resulting name scheme (for SOver 1.1) is this:
on x86:
libcrypto-1_1.dll + libcrypto.dll.a
libssl-1_1.dll + libssl.dll.a
on x86_64:
libcrypto-1_1-x64.dll + libcrypto.dll.a
libssl-1_1-x64.dll + libssl.dll.a
An observation is that the import lib is the same for both
architectures. Not to worry, though, as they will be installed in
PREFIX/lib/ for x86 and PREFIX/lib64/ for x86_64.
As a side effect, MingW got its own targets in Makefile.shared.
link_dso.mingw-shared and link_app.mingw-shared are aliases for the
corresponding cygwin-shared targets. link_shlib.mingw-shared is,
however, a target separated from the cygwin one.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Better libclean that removes the exact files that have been built,
nothing more and nothing less.
Corrected typo
A couple of editorial changes.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Since we're using the acronym DSO everywhere else and that's a common
name for that kind of object, we might as well do so here as well.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Instead of having the installation recipe rely on special knowledge,
feed it with information, including what shared library files belong
together. For Cygwin and Mingw, that's the .dll and its import
library .dll.a. For Unixen, it's the shared library file name with SO
version and the one without.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Originally, the Makefile.shared targets described what they used as
input for a shared object, be it a shared library or a DSO. It turned
out, however, that the link_o targets were used exclusively for
engines and the link_a targets were for libcrypto and libssl.
This rename fest turns and indication on the kind of input the targets
get to the intention with using them.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Then it can pass around the information where it belongs. The
Makefile templates pick it up along with other target data, the
DSO module gets to pick up the information through
crypto/include/internal/dso_conf.h
Reviewed-by: Andy Polyakov <appro@openssl.org>
- install_sw had a display of text that belongs under the install target
- previous layout installed architecture dependent files in
dev:['prefix'.'arch'.LIB], dev:['prefix'.'arch'.EXE] and
dev:['prefix'.'arch'.ENGINES]. Changed to dev:['prefix'.LIB.'arch'],
dev:['prefix'.EXE.'arch'] and dev:['prefix'.ENGINES.'arch'] instead.
Reviewed-by: Andy Polyakov <appro@openssl.org>
This is done with a simple file name comparison. We could think of
something more elegant in the future.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Adding uplink and applink to some builds was done by "magic", the
configuration for "mingw" only had a macro definition, the Configure
would react to its presence by adding the uplink source files to
cpuid_asm_src, and crypto/build.info inherited dance to get it
compiled, and Makefile.shared made sure applink.o would be
appropriately linked in. That was a lot under the hood.
To replace this, we create a few template configurations in
Configurations/00-base-templates.conf, inherit one of them in the
"mingw" configuration, the rest is just about refering to the
$target{apps_aux_src} / $target{apps_obj} in the right places.
Reviewed-by: Andy Polyakov <appro@openssl.org>
VMS DIFF tries to calculate all the differences, which is slower than
just reading the files and stopping at the first difference. The
latter doesn't exist as a command, so the problem is solved with perl
and File::Compare (has been in core perl since very early version 5).
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
DCL may be in extended parsing style, which makes it less case
insensitive, so when removing a string from another, make sure to get
casing correctly.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
This isn't the fully featured combination of compiler generated
dependency files and Makefile include directives, but a cheaper
variant of the same.
The dependency files are generated automatically, but then we have the
usual "depend" target. However, we depend on it in the bigger phony
targets that are the most likely to be used. That make this feature
automatic enough.
A side effect is that we can't use the build file's timestamp to check
if reconfiguring might be in order. In its place, we use a flag file
that depends on Configure and the build file template and depend on it
in spots where it makes sense to check for the need to reconfigure.
Reviewed-by: Rich Salz <rsalz@openssl.org>
When cross compiling, we may end up with someting like apps/openssl.exe
and a number of test/*.exe. However, util/shlib_wrap.sh doesn't know
what the executable extension should be, if any, so we need to make
sure it has access to that information when testing, since
OpenSSL::Test uses that script to execute all programs.
Reviewed-by: Rich Salz <rsalz@openssl.org>
All those flags existed because we had all the dependencies versioned
in the repository, and wanted to have it be consistent, no matter what
the local configuration was. Now that the dependencies are gone from
the versioned Makefile.ins, it makes much more sense to use the exact
same flags as when compiling the object files.
Reviewed-by: Rich Salz <rsalz@openssl.org>
.d (.MMS in the VMS world) files with just dependencies are built from
exactly the same conditions as the object files. Therefore, the rules
for them can be built at the same time as the rules for the
corresponding object files.
This removes the requirement for a src2dep function in the build file
templates, and for common.tmpl to call it. In the end, the existence
of depend files is entirely up to the build file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
That variable isn't for us, it's for any user, distributor or package
builder that wants one after the section number. "ssl" seems to be
popular...
Reviewed-by: Matt Caswell <matt@openssl.org>
The installation of man files and html files alike didn't properly
check that file names with different casing could be the same on
case-insensitive file systems. This change fixes that.
Reviewed-by: Rich Salz <rsalz@openssl.org>
There was a catch 22, where 'make depend' directly after configuring
in an otherwise pristine build tree would fail because buildinf.h
didn't exist yet.
This change has the depend building targets depend on the same other
targets as the object file building targets, so the generation of
buildinf.h and similar files would kick in during 'make depend'.
Reviewed-by: Rich Salz <rsalz@openssl.org>
INSTALL_PREFIX is a confusing name, as there's also --prefix.
Instead, tag along with the rest of the open source world and adopt
the Makefile variable DESTDIR to designate the desired staging
directory.
The Configure option --install_prefix is removed, the only way to
designate a staging directory is with the Makefile variable (this is
also implemented for VMS' descrip.mms et al).
Reviewed-by: Rich Salz <rsalz@openssl.org>
apps/progs.pl counted on the caller to provide the exact command
files. The unified build doesn't have that knowledge, and the easier
and more flexible thing to do is to feed it all the apps/*.c files and
let it figure out the command names by looking inside (looking for
/int ([a-z0-9][a-z0-9_]*)_main\(int argc,/).
Also, add it to the generate command, since it's a versioned file.
Reviewed-by: Rich Salz <rsalz@openssl.org>
On Windows POSIX layers, two files are produced for a shared library,
there's {shlibname}.dll and there's the import library {libname}.dll.a
On some/most Unix platforms, a {shlibname}.{sover}.so and a symlink
{shlibname}.so are produced.
For each of them, unix-Makefile.tmpl was entirely consistent on which
to have as a target when building a shared library or which to use as
dependency.
This change clears this up and makes it consistent, we use the
simplest form possible, {lib}.dll.a on Windows POSIX layers and
{shlibname}.so on Unix platforms. No exception.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Because the command line definitions of OPENSSLDIR and ENGINESDIR
contain quotes, we need a variant of CFLAG where backslashes and
quotes are escaped when we produce buildinf.h
Reviewed-by: Rich Salz <rsalz@openssl.org>
As part of this, change util/mkdef.pl to stop adding libraries to
depend on in its output. mkdef.pl should ONLY output a symbol
vector.
Because symbol names can't be longer than 31 characters, we use the
compiler to shorten those that are longer down to 23 characters plus
an 8 character CRC. To make sure users of our header files will pick
up on that automatically, add the DEC C supported extra headers files
__decc_include_prologue.h and __decc_include_epilogue.h.
Furthermore, we add a config.com, so VMS people can configure just as
comfortably as any Unix folks, thusly:
@config
Reviewed-by: Rich Salz <rsalz@openssl.org>
Cygwin and Mingw name their libraries a bit differently from the rest
of the POSIXly universe, we need to adapt to that.
In Makefile.tmpl, it means that some hunks will only be output
conditionally.
This also means that shared_extension for the Cygwin and Mingw
configurations in Configurations/10-main.conf are changing from .dll.a
to .dll. Makefile.shared does a fine job without having them
specified, and it's much easier to work with tucking an extra .a at
the end of files in the installation recipes than any amount of name
rewrites, especially with the support of the SHARED_NAME in the top
build.info.
Reviewed-by: Rich Salz <rsalz@openssl.org>
