- 08 3月, 2016 4 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org>
-
- 05 3月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
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: NKurt Roeckx <kurt@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 04 3月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
This construct in a Makefile is a bit overzealous: @echo FOO @FOO Cleaned up. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 03 3月, 2016 7 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
$target{lflags} and $target{plib_flag} were copied to %config for no good reason. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
- 02 3月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
This has no real meaning, except it gives Configure a hint that VC targets are indeed capable of producing shared objects. Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
- 01 3月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
- 28 2月, 2016 4 次提交
-
-
由 Richard Levitte 提交于
Exiting out of a recipe more than necessary leaves an ugly message. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Rich Salz 提交于
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: NRichard Levitte <levitte@openssl.org>
-
由 Richard Levitte 提交于
We don't want recipes for the same files generated more than once Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 27 2月, 2016 3 次提交
-
-
由 FdaSilvaYY 提交于
Signed-off-by: NRich Salz <rsalz@akamai.com> Reviewed-by: NKurt Roeckx <kurt@openssl.org>
-
由 Rob Percival 提交于
Reviewed-by: NBen Laurie <ben@openssl.org> Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Since the configs were remade into hash tables, this isn't needed any more. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 26 2月, 2016 2 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
- 25 2月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org>
-
- 23 2月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
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: NAndy Polyakov <appro@openssl.org>
-
- 22 2月, 2016 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 21 2月, 2016 4 次提交
-
-
由 Richard Levitte 提交于
On slower file systems, this makes a huge difference Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Ben Laurie 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Ben Laurie 提交于
is a .s). Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 20 2月, 2016 6 次提交
-
-
由 Richard Levitte 提交于
Don't check for no_shared Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
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: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
One spot was forgotten. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
Object LiBrary Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
It failed to remove lingering Makefile.new Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Richard Levitte 提交于
It was turning off output again in two place where it should have turned it on. Reviewed-by: NRich Salz <rsalz@openssl.org>
-