- Feb 20, 2016
-
-
Richard Levitte authored
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>
-
Viktor Dukhovni authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Ben Laurie authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Ben Laurie authored
is a .s). Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
Don't check for no_shared Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
They depend on this feature because they use the engine ossltest, which is only available as a dynamic engine. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
Until now, the engines in engines/ were only built as dynamicaly loadable ones if shared libraries were built. We not dissociate the two and can build dynamicaly loadable engines even if we only build static libcrypto and libssl. This is controlled with the option (enable|disable|no)-static-engine, defaulting to no-static-engine. Note that the engines in crypto/engine/ (dynamic and cryptodev) will always be built into libcrypto. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
Depending on Makefile meant that a new attempt to rebuild the Makefile with "new" dependency data was done all the time, uncontrolled. Better to depend on configdata.pm, which truly only changes with reconfiguration. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Ben Laurie <ben@openssl.org>
-
Kurt Roeckx authored
Also gives an error message when you gave it a parameter it didn't expect. Reviewed-by: Rich Salz <rsalz@openssl.org> MR: #2009
-
Richard Levitte authored
One spot was forgotten. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
Object LiBrary Reviewed-by: Rich Salz <rsalz@openssl.org>
-
- Feb 19, 2016
-
-
Richard Levitte authored
It failed to remove lingering Makefile.new Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Richard Levitte authored
It was turning off output again in two place where it should have turned it on. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Andy Polyakov authored
Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Dr. Stephen Henson authored
Remove DSA private key code which tolerates broken implementations which use negative integers. Reviewed-by: Emilia Käsper <emilia@openssl.org>
-
Dr. Stephen Henson authored
Remove old code that handled various invalid DSA formats in ancient software. This also fixes a double free bug when parsing malformed DSA private keys. Thanks to Adam Langley (Google/BoringSSL) for discovering this bug using libFuzzer. CVE-2016-0705 Reviewed-by: Emilia Käsper <emilia@openssl.org>
-
Emilia Kasper authored
Adapted from BoringSSL. Added a test. The extension parsing code is already attempting to already handle this for some individual extensions, but it is doing so inconsistently. Duplicate efforts in individual extension parsing will be cleaned up in a follow-up. Reviewed-by: Stephen Henson <steve@openssl.org>
-
Emilia Kasper authored
This silences the memory sanitizer. All fields were already correctly initialized but the struct padding wasn't, causing an uninitialized read warning. Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Viktor Szakats authored
crypto.h: honor no-filenames config setting in missing cases Signed-off-by: Rich Salz <rsalz@akamai.com> Reviewed-by: Matt Caswell <matt@openssl.org>
-
Richard Levitte authored
Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
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>
-
Richard Levitte authored
Of course, if there are remaining files in a directory, it won't be removed. Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
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>
-
Richard Levitte authored
The engine DSOs were named as if they were shared libraries, and could end up having all sorts of fancy names: Cygwin: cygFOO.dll Mingw: FOOeay32.dll Unix: libFOO.so / libFOO.sl / libFOO.dylib / ... This may be confusing, since they look like libraries one should link with at link time, when they're just DSOs. It's therefore time to rename them, and do it consistently on all platforms: Cygwin & Mingw: FOO.dll Unix: FOO.{so,sl,dylib,...} Interestingly enough, the MSVC and VMS builds always did it this way. Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Richard Levitte authored
Because we know for certain that the link_shlib targets are used exclusively for shared libraries (libcrypto and libssl) and that they must have an associated .num file, we don't need to check the library name to produce an ld script. Just do it unconditionally. link_shlib.linux-shared can be simplified further, as most of it is exactly the same as $(DO_GNU_SO) with just one variable modification. Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
- 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>
-
Richard Levitte authored
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>
-
Richard Levitte authored
Some directories weren't removed. Reviewed-by: Andy Polyakov <appro@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
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>
-
Richard Levitte authored
We need to do the same dance as when object files are created. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
-
Richard Levitte authored
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>
-
Richard Levitte authored
The benefit with using configdata.pm is that Configure writes it for us. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
-
- Feb 18, 2016
-
-
Richard Levitte authored
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>
-