| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
handle recursive dependencies, so explicitly disabling, say, ecc_key, doesn't
disable cvc as it should. However it does fix the problem of building with
--with-tr1=none, which was the main problem people were having WRT to this.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
TARGET_CPU_IS macro. This would otherwise cause problems on HP-PA, as
it would generate invalid macros like TARGET_CPU_IS_HPPA2.0
Also in configure.py, replace hyphens with underscores in the submodel name
for generating the macro (configure.pl already did this). Otherwise using
the sparc64-ultraX submodels would also generate an invalid macro in build.h
|
| |
|
|
|
|
|
|
|
|
|
| |
Previous behavior was that if a module was explicitly disabled, the
libraries that module used would still be linked in. So for instance
configure.pl --disable-modules=pthreads --without-openssl
would cause libpthread and libcrypto to be included in the final link!
This bug only affected the Perl configure
|
| | |
|
| |
|
|
|
|
|
|
| |
Fix --enable-asm (had same effect as --disable-asm)
Fix mp_bits calculation; took into account both modules which were enabled
and ones that were explicitly disabled, for instance
./configure.pl --disable-modules=mp_amd64 -> mp_bits == 64
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
wrong for a while, which suggests perhaps that 2.95 has finally died out
in the wild. Praise be.
|
| |
|
|
|
|
| |
officially deprecate the Perl configure, though it probably won't be
removed until a development tree release since otherwise will break
distro packaging scripts.
|
| | |
|
| |
|
|
| |
for macro generation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
had been denoted with @{var:NAME}, this has changed to %{NAME}. This is
pretty much a wash for configure.pl but it makes it much easier to process
the templates using Python's string.Template. The logic being the 'var:'
prefix had been to support conditional statements in the templates (using
an 'if:' prefix), but this functionality was not being used and support
for it is removed from configure.pl in this revision.
For a similiar reason, rename a number of template variables with hyphens
in their name to use underscores instead. This is slightly more consistent
anyway (since many variable names had already used _ instead of -) but more
importantly makes them much easier to deal with using aforementioned Python
template code.
This should not result in any user-visible change (unless I messed up).
|
| |
|
|
|
|
|
|
|
|
|
| |
since they often contain spaces. This doesn't matter to configure.pl's
hand-done regex 'parser', but it makes things more consistent and makes
it possible to use the shlex parser included with python to parse all of
the data files.
Also remove the unused <arch> entry in darwin - this information had
previously be removed from all the other files but I guess that one was
missed.
|
| |
|
|
| |
number increments, for stable releases that don't affect binary compat.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on Solaris 10 with GCC 3.4.3.
First, remove the definition of _XOPEN_SOURCE_EXTENDED=1 in mmap_mem.cpp
and unix_cmd.cpp, because apparently on Solaris defining this macro breaks
C++ compilation entirely with GCC:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6395191
In es_egd.cpp and es_dev.cpp, include <fcntl.h> to get the declaration of
open(), which is apparently where open(2) lives on Solaris - this matches
the include the *BSD man pages for open(2) show, though AFAIK the BSDs
all compiled fine without it (probably due to greater efforts to be
source-compatible with Linux systems by *BSD developers).
I have not been able to test these changes personally on Solaris but
Rickard reports that with these changes everything compiles OK.
Update lib version to 1.8.0-pre. ZOMG. Finally.
|
| | |
|
| |
|
|
|
| |
decide later on if changes warrant another release candiate or not. If
not, 1.7.24 will be remarked as 1.8.0 prior to release.
|
| |
|
|
|
|
|
|
| |
the user that it can override via --cpu, however if it was guessed using
Config{'archname'} the user was not so reminded. This is actually the worst
possible case since Perl's Config setting is probably the least reliable
method (which is why it is only used if /proc/cpuinfo and uname are not
around).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNU MP, zlib, and bzip2.
--with-{openssl,gnump,bzip2,zlib}
--without-{openssl,gnump,bzip2,zlib}
They have the exact same effect as --enable-modules=x or --disable-modules=x
This turned out to be a much easier way of specifying options for the
Gentoo ebuild. It is likely that other distro builds architectures will
also prefer this option style as being somewhat more autoconf-like and
fitting in with existing command templates.
|
| |
|
|
|
|
| |
--disable-modules. While updating the Gentoo ebuild I found it was
much easier to autogen the configure line if both of these options
are no-ops if used with no value.
|
| |
|
|
|
|
| |
Print the version number at the start of the build.
Fix compiler name in TR1 message
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
both support TR1 fine AFAICT.
Add ability to explicitly disable using TR1 with --with-tr1=none
Add a marker in the cc info files specifiying if TR1 should be chosen
by default. Yes, autoconf would be better for this than a static
per-compiler setting. Yes, I totally hate autoconf. Yes, I would still
consider autoconf patches. No, I'm not going to do it myself. :)
I am looking forward to being able to safely adopt C++0x and TR2
throughout the library and make the need for a lot of this special-casing
stuff go away.
Until then, it seems better to defaulting to using tr1 (and thus, ECC) than
not.
|
| | |
|
| |
|
|
| |
this if desired)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
was not the right place to keep track of this information. Also modify
all Algorithm_Factory constructor functions to take instead of a SCAN_Name
a pair of std::strings - the SCAN name and an optional provider name. If
a provider is specified, either that provider will be used or the request
will fail. Otherwise, the library will attempt best effort, based on
user-set algorithm implementation settings (combine with benchmark.h for
choosing the fastest implementation at runtime) or if not set, a static
ordering (preset in static_provider_weight in prov_weight.cpp, though it
would be nice to make this easier to toggle).
|
| | |
|
| |
|
|
|
| |
botan-17, which was potentially confusing (and apparently contradictory to
normal pkg-config naming conventions).
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
instead of in the toplevel directory.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
out of tree builds.
Also rename the generated botan-config script so that it is, like the
pkg-config settings, namespaced by the major and minor version numbers
(eg, botan-17-config). This is useful in particular for distros like
Debian which ship both stable and unstable versions. Currently Debian
is actually the only distro I know of shipping 1.7 as well as 1.6, but
I would certainly like to encourage more in the future by making it
easy to do.
|
| | |
|
| |
|
|
|
|
|
| |
$ pkg-config botan-17 --libs
-L/usr/local/lib -lbotan -lm -lpthread -lrt
to make it easier to have multiple versions of Botan installed and in
use at the same time.
|
| | |
|
| |
|
|
|
| |
the submodel it is referencing - this is usually more recognizable.
Suggested by Markus Wanner.
|
| |
|
|
|
|
| |
of /proc/cpuinfo in configure.pl
This is probably only useful for testing.
|
| | |
|
| |
|
|
| |
rather than silently ignoring it.
|
| | |
|
