Also update the nit checker to catch missing spaces in prototypes as
that is where the majority of errors were located.
---
crypto/bn/README.pod | 10 +-
doc/apps/ec.pod | 2 +-
doc/apps/ecparam.pod | 2 +-
doc/
atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools. So add support for the standard $RC
/ $WINDRES env vars as well.
---
Configure | 1 +
Makefile.in | 2 ++
Makefile.shared | 2 +-
3 files changed, 4 insertions(+), 1 del
On 08 Mar 2015 20:26, Salz, Rich wrote:
> > Lets add + to the rules we know are make based.
>
> Isn't that a gnu-make-only thing?
looks to me like POSIX specifies it:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_76_13_03
-mike
__
The _BSD_SOURCE macro is replaced by the _DEFAULT_SOURCE macro. Using
just the former with newer versions leads to a build time warning, so
make sure to use the new macro too.
---
test/ssltest.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/test/ssltest.c b/test/ssltest.c
index 26cf96c..b36
When the crypto/ssl targets attempt to build their shared libs, they run:
cd ..; make libcrypto.so.1.0.0
The top level Makefile in turn runs the build-shared target for that lib.
The build-shared target depends on both do_$(SHLIB_TARGET) & link-shared.
When building in parallel, make is al
atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools. So add support for the standard $RC
/ $WINDRES env vars as well.
---
Configure | 3 +++
Makefile.org| 2 ++
Makefile.shared | 2 +-
3 files changed, 6 insertions(+), 1 d
When building on x32 systems where the default type is 32bit, make sure
we can transparently represent 64bit integers. Otherwise we end up with
build errors like:
/usr/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s
Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xlate.pl
lin
Reported-by: Conrad Kostecki
URL: https://bugs.gentoo.org/543828
---
crypto/bio/bss_dgram.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c
index aef8149..ed275d1 100644
--- a/crypto/bio/bss_dgram.c
+++ b/crypto/bio/bss_dgram
Some of the recursive commands are too complicated for make to detect
that the child is actually make. This causes warnings like:
warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
Lets add + to the rules we know are make based.
---
Makefile.org | 30 ++--
The current code has dummy sleep/touch commands to try and work
around the parallel issue, but that is obviously racy. Instead
lets force one of the files to depend on the other so we know
they'll never run in parallel.
---
crypto/objects/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 de
The mkdir-p.pl does not handle parallel creation of directories.
This comes up when the install_sw and install_docs rules run and
both call mkdir-p.pl on sibling directory trees.
Instead, lets create a single install_dirs rule that makes all of
the dirs we need, and have these two install steps de
atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools. So add support for the standard $RC
/ $WINDRES env vars as well.
---
Configure | 3 +++
Makefile.org| 2 ++
Makefile.shared | 2 +-
3 files changed, 6 insertions(+), 1 d
this can be closed now since d475b2a3bfde8d4aceefb41b21acc3711893d2a8 fixed it
-mike
signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On 26 Oct 2014 22:58, Andy Polyakov wrote:
> > I would go with option 2. and detect the ARM architecture that we are
> > compiling for in the configure phase and compile for it.
>
> As mentioned in another message question was not about removing run-time
> switch as concept, but about limiting it
On 26 Aug 2014 19:44, Timo Teras wrote:
> On Tue, 26 Aug 2014 10:12:06 -0400 "Salz, Rich" wrote:
> > > Find a C version (which I have written) of the utility at:
> > > http://git.alpinelinux.org/cgit/aports/plain/main/openssl/c_rehash.c
> >
> > That's pretty cool. We'd need to modify it to not us
On Tue 16 Sep 2014 08:15:37 Andy Polyakov via RT wrote:
> >>> This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34.
> >>>
> >>> When gcc is given a .s file and told to preprocess it, it outputs
> >>> nothing.
> >>> Since gcc targets are more common/important than OSF, revert it and let
> >
On Tue 16 Sep 2014 08:15:37 Andy Polyakov via RT wrote:
> >>> This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34.
> >>>
> >>> When gcc is given a .s file and told to preprocess it, it outputs
> >>> nothing.
> >>> Since gcc targets are more common/important than OSF, revert it and let
> >
On Fri 12 Sep 2014 09:44:59 Andy Polyakov via RT wrote:
> > This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34.
> >
> > When gcc is given a .s file and told to preprocess it, it outputs nothing.
> > Since gcc targets are more common/important than OSF, revert it and let
> > the original
On Fri 12 Sep 2014 09:44:59 Andy Polyakov via RT wrote:
> > This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34.
> >
> > When gcc is given a .s file and told to preprocess it, it outputs nothing.
> > Since gcc targets are more common/important than OSF, revert it and let
> > the original
On Wed 27 Aug 2014 15:24:45 Salz, Rich via RT wrote:
> > i don't think that's really true. else, why is autoconf & friends relying
> > on a shell and not perl ? those see way more distribution than openssl.
>
> Last I looked, autoconf doesn't use anything that really wasn't in Version 7
> Bourne
On Wed 27 Aug 2014 15:24:45 Salz, Rich via RT wrote:
> > i don't think that's really true. else, why is autoconf & friends relying
> > on a shell and not perl ? those see way more distribution than openssl.
>
> Last I looked, autoconf doesn't use anything that really wasn't in Version 7
> Bourne
On Tue 26 Aug 2014 04:31:07 Rich Salz via RT wrote:
> The sad thing is, perl is widely available than posix shell. cool hack tho.
i don't think that's really true. else, why is autoconf & friends relying on
a shell and not perl ? those see way more distribution than openssl.
-mike
___
On Tue 26 Aug 2014 04:31:07 Rich Salz via RT wrote:
> The sad thing is, perl is widely available than posix shell. cool hack tho.
i don't think that's really true. else, why is autoconf & friends relying on
a shell and not perl ? those see way more distribution than openssl.
-mike
_
On Tue 01 Jul 2014 08:53:56 Tim Hudson wrote:
> On 30/06/2014 10:23 PM, Salz, Rich wrote:
> >> On Tue, Jul 01, 2014 at 12:25:00AM +0200, Rich Salz via RT wrote:
> >>> Unsupported platform.
> >>
> >> Not having read the ticket, uClibc and newlib might be useful to support
> >> if
> >> possible sinc
On Mon 16 Jun 2014 06:39:40 Viktor Dukhovni wrote:
> On Mon, Jun 16, 2014 at 02:10:14AM -0400, Mike Frysinger wrote:
> > On Mon 28 Apr 2014 09:32:40 Salz, Rich wrote:
> > > > While rpaths are not needed in some contexts, they are important in
> > > > others, p
On Thu 01 May 2014 13:26:48 Stephen Henson via RT wrote:
> On Thu May 01 12:29:58 2014, meiss...@suse.de wrote:
> > SUSE has received a bugreport from a user, that the "padding"
> > extension
> > change breaks IronPort SMTP appliances.
> >
> > There might a RT on this already, not sure.
> >
> > h
On Mon 28 Apr 2014 09:32:40 Salz, Rich wrote:
> > While rpaths are not needed in some contexts, they are important in
> > others, please do not remove rpath support.
> Yes, such as cross-compiling or embedded systems. I think it's reasonable
> to make it a config option tho.
eh ? rpaths are not
On Fri 06 Jun 2014 09:15:09 Kurt Roeckx via RT wrote:
> On Fri, Jun 06, 2014 at 01:27:02AM -0400, Mike Frysinger wrote:
> > On Thu 05 Jun 2014 22:53:32 Matt Caswell via RT wrote:
> > > On Sun Apr 27 13:04:20 2014, vap...@gentoo.org wrote:
> > > > It's a standa
On Fri 06 Jun 2014 09:15:09 Kurt Roeckx via RT wrote:
> On Fri, Jun 06, 2014 at 01:27:02AM -0400, Mike Frysinger wrote:
> > On Thu 05 Jun 2014 22:53:32 Matt Caswell via RT wrote:
> > > On Sun Apr 27 13:04:20 2014, vap...@gentoo.org wrote:
> > > > It's a standa
On Thu 05 Jun 2014 22:53:32 Matt Caswell via RT wrote:
> On Sun Apr 27 13:04:20 2014, vap...@gentoo.org wrote:
> > It's a standard setting that other build systems use.
>
> Can you explain why you need this?
because people want to set custom linker flags. `man ld` shows quite a large
number tha
On Thu 05 Jun 2014 22:53:32 Matt Caswell via RT wrote:
> On Sun Apr 27 13:04:20 2014, vap...@gentoo.org wrote:
> > It's a standard setting that other build systems use.
>
> Can you explain why you need this?
because people want to set custom linker flags. `man ld` shows quite a large
number tha
On Mon, May 5, 2014 at 9:37 AM, Viktor Dukhovni wrote:
> On Sun, May 04, 2014 at 11:59:55PM +0100, Matt Caswell wrote:
>> > As far as I understand if you want to have both -lssl -lcrypto you
>> > should use "openssl" instead of "libssl"?
>> >
>> > Anyway, I think this makes perfect sense and if thi
On Mon 05 May 2014 00:36:57 Matt Caswell via RT wrote:
> This patch changes the output of "pkg-config --libs libssl" from:
> -L/usr/local/ssl/lib -lssl -lcrypto
> to:
> -L/usr/local/ssl/lib -lssl
>
> Arguably this is the strictly "correct" approach. However in practice I
> suspect many build scrip
On Mon 05 May 2014 00:36:57 Matt Caswell via RT wrote:
> This patch changes the output of "pkg-config --libs libssl" from:
> -L/usr/local/ssl/lib -lssl -lcrypto
> to:
> -L/usr/local/ssl/lib -lssl
>
> Arguably this is the strictly "correct" approach. However in practice I
> suspect many build scrip
On Sun 27 Apr 2014 14:08:12 Kurt Roeckx via RT wrote:
> > -DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)"
> > +DO_GNU_APP=LDFLAGS="$(LDFLAGS) $(CFLAGS)"
>
> Shouldn't that be this?
> +DO_GNU_APP=LDFLAGS="$(LDFLAGS) -Wl,-rpath,$(LIBRPATH)"
i didn't mean to include dropping of the rpath in t
On Sun 27 Apr 2014 14:08:12 Kurt Roeckx via RT wrote:
> > -DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)"
> > +DO_GNU_APP=LDFLAGS="$(LDFLAGS) $(CFLAGS)"
>
> Shouldn't that be this?
> +DO_GNU_APP=LDFLAGS="$(LDFLAGS) -Wl,-rpath,$(LIBRPATH)"
i didn't mean to include dropping of the rpath in t
This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34.
When gcc is given a .s file and told to preprocess it, it outputs nothing.
Since gcc targets are more common/important than OSF, revert it and let
the original submitter sort out the problem.
URL: https://bugs.gentoo.org/499086
---
cr
Have the .pc files depend on each other rather than duplicating the
various link settings.
---
Makefile.org | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/Makefile.org b/Makefile.org
index 991a439..c9a7253 100644
--- a/Makefile.org
+++ b/Makefile.org
@@ -468,11 +46
It's a standard setting that other build systems use.
---
Makefile.org| 1 +
Makefile.shared | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile.org b/Makefile.org
index e7f6e5b..991a439 100644
--- a/Makefile.org
+++ b/Makefile.org
@@ -217,6 +217,7 @@ BUILDENV= PLA
On Thursday 25 July 2013 13:48:20 Kurt Roeckx wrote:
> I've submitted a patch in 2007 to make as much as possible static,
> but it never got applied, so I never bothered writing a patch to
> make the rest hidden. I think making things static is even better
> than hiding them, and should work on al
On Sunday 20 October 2013 10:40:10 Kx Mp via RT wrote:
> when install target folder have lib64 folder
> it will auto install into lib64 rather than lib folder
what exactly is the suggestion ? there is a --libdir configure flag to set the
path as needed. trying to add logic to guess what the "ri
On Sunday 15 September 2013 18:30:32 Yuriy Kaminskiy wrote:
> Cristian Rodríguez wrote:
> > El 12/09/13 14:17, Yuriy Kaminskiy escribió:
> >> This will break on glibc-3.0.
> >>
> >> #if defined(__GLIBC_PREREQ) && __GLIBC_PREREQ(2, 16)
> >
> > Yes, that is the correct way, but ensure is being inc
On Friday 13 September 2013 16:27:03 Green, Paul wrote:
> Cristian Rodríguez wrote:
> > El 12/09/13 14:17, Yuriy Kaminskiy escribió:
> >> This will break on glibc-3.0.
> >> #if defined(__GLIBC_PREREQ) && __GLIBC_PREREQ(2, 16)
> >
> >Yes, that is the correct way, but ensure is being included.
>
>
On Wednesday 11 September 2013 10:49:36 Kyle McMartin wrote:
> +#if defined(__GNUC__) && __GNUC__>=2
> +void OPENSSL_cpuid_setup(void) __attribute__((constructor));
> +#endif
> +void OPENSSL_cpuid_setup(void)
this can be made simpler:
#if defined(__GNUC__) && __GNUC__>=2
__attribut
On Saturday 22 June 2013 15:07:49 Ben Laurie wrote:
> On 22 June 2013 19:04, Mike Frysinger wrote:
> > On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote:
> >> On 18 June 2013 22:35, Mike Frysinger wrote:
> >> > On Tuesday 18 June 2013 07:37:55 Richard Weinberger
On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote:
> On 18 June 2013 22:35, Mike Frysinger wrote:
> > On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote:
> >> While building openssl-1.0.1e I noticed that the parallel build
> >> is broken.
> >
> > y
On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote:
> While building openssl-1.0.1e I noticed that the parallel build
> is broken.
yes, it's pretty much always been broken
> I found this patch on the net:
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/fi
> les/o
On Friday 03 May 2013 12:56:41 Mitch Halmu via RT wrote:
> When running the config script on Solaris 9 (sparc), the symbolic link
> /dev/null -> /devices/pseudo/mm@0:null is destroyed. You will notice it
> happened by the error messages that start spewing. To repair:
>
> # ln -s /devices/pseudo/mm
i've improved the original patch to make the -4/-6 behavior consistent across
the tools. i also tweaked the behavior slightly to make it run correctly
(imo).
-mike
http://rt.openssl.org/Ticket/Display.html?id=2051
user/pass: guest/guest
Index: apps/s_apps.h
On Tuesday 09 April 2013 09:56:59 Quanah Gibson-Mount wrote:
> --On Tuesday, April 09, 2013 4:43 PM +0530 Balakumaran Kannan wrote:
> > I recently joined Openssl mailing list. Currently I'm trying to implement
> > IPv6 support to openssl binary (s_server and s_client) as part of my
> > work. I saw
On Thursday 15 March 2012 03:19:07 Ludwig Nussel wrote:
> Dr. Stephen Henson wrote:
> > On Wed, Mar 14, 2012, Mike Frysinger wrote:
> >> i'm not looking for downstream workarounds here but rather the right
> >> answer. is openssl-1.0.1 expected to be ABI co
On Wednesday 14 March 2012 19:23:14 Dr. Stephen Henson wrote:
> On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > i'm not looking for downstream workarounds here but rather the right
> > answer. is openssl-1.0.1 expected to be ABI compatible with
> > openssl-1.0.0 ?
>
&
On Wednesday 14 March 2012 17:18:19 Kurt Roeckx wrote:
> On Wed, Mar 14, 2012 at 02:30:29PM -0400, Mike Frysinger wrote:
> > On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> > > On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > > > On Wednesday 14 Mar
On Wednesday 14 March 2012 14:36:09 Dr. Stephen Henson wrote:
> On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> > > On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > > > On Wednesday 14 Mar
On Wednesday 14 March 2012 14:25:32 Dr. Stephen Henson wrote:
> On Wed, Mar 14, 2012, Mike Frysinger wrote:
> > On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
> > >OpenSSL version 1.0.1 released
> > >===
> > >
> &
On Wednesday 14 March 2012 11:09:22 OpenSSL wrote:
>OpenSSL version 1.0.1 released
>===
>
>http://www.openssl.org/source/exp/CHANGES.
>
>The most significant changes are:
>
> o TLS/DTLS heartbeat support.
> o SCTP support.
> o RFC
the current generated .pc files dump all libraries into the Libs: section.
this is incorrect: only the "main" library should be listed there while all
others should be listed under "Libs.private". in other words, if people want
to use libcrypto, they should just link with -lcrypto by default.
On Tuesday 22 November 2011 17:49:50 Tomas Mraz via RT wrote:
> The attached patch changes the generated pkgconfig files so the
> libraries needed for static linking are in Libs.private instead of Libs.
ah, this is better than the current state, but i ended up posting a patch
earlier today that g
atm, the windres code in openssl is only usable via the cross-compile prefix
option unlike all the other build tools. so add support for the standard $RC
/ $WINDRES env vars as well.
-mike
Index: Configure
===
RCS file: /usr/local/
if i load a fresh browser (i.e. no cookies/etc...), and do:
- goto http://rt.openssl.org/
- login with guest/guest
- enter "alpha" into search box in upper right
- click the link for the 2nd alpha bug (1597)
http://rt.openssl.org/Ticket/Display.html?id=159
--- crypto/bn/asm/alpha-mont.pl
+++ crypto/bn/asm/alpha-mont.pl
@@ -41,7 +41,7 @@ $j="s4";
$m1="s5";
$code=<<___;
-#indef __linux__
+#ifdef __linux__
#include
#else
#include
-mike
signature.asc
Description: PGP signature
On Monday, September 13, 2010 09:38:01 Andy Polyakov via RT wrote:
> > finally, we're left with one warning:
> > :36: Warning: operand out of range (0xf000 is not
> > between 0x and 0x00ff)
> >
> > which is due to this insn:
> > mov -4096,$at
> >
> > i don
On Monday, September 13, 2010 09:38:01 Andy Polyakov via RT wrote:
> > finally, we're left with one warning:
> > :36: Warning: operand out of range (0xf000 is not
> > between 0x and 0x00ff)
> >
> > which is due to this insn:
> > mov -4096,$at
> >
> > i don
first, let's ignore the "alphacpuid.s not bundled problem" as it is already
filed as ticket #2309. once that is fixed, we hit a rash of other issues.
seems this alpha assembly was tested with a toolchain other than the GNU one
(meaning the GNU assembler or "gas"), and it was tested on a host ot
while openssl requires perl in order to compile, nothing that it installs
requires perl at runtime. that is except for the simple "c_rehash" script.
for such a simple wrapper, i dont think the perl requirement is justified.
fortunately, the PLD Linux guys have already rewritten things in POSIX
On Sunday 10 January 2010 21:53:03 Mike Frysinger wrote:
> openssl-1.0.0-beta4 and the openssl-1.0.0-stable branch are still using
> "/lib/" instead of "/$(LIBDIR)/" in a few places.
there is also a missing ref in the top level Makefile.org
openssl-1.0.0-beta4 and the openssl-1.0.0-stable branch are still using
"/lib/" instead of "/$(LIBDIR)/" in a few places.
-mike
Index: engines/Makefile
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/engines/Makefile,v
retrieving
On Thursday 05 November 2009 11:53:54 Ben Laurie wrote:
>OpenSSL version 0.9.8l released
the tarball seems to contain files it shouldnt:
$ tar tf openssl-0.9.8l.tar.gz | egrep '(orig|rej|~)'
openssl-0.9.8l/CHANGES.~1.1238.2.145.~
openssl-0.9.8l/Configure.orig
openssl-0.9.8l/Configure.rej
opens
On Wednesday 28 October 2009 10:18:10 Stephen Henson via RT wrote:
> > [vap...@gentoo.org - Mon Oct 26 13:59:37 2009]:
> >
> > the current util/domd script defaults $MAKEDEPEND to `makedepend` and
> > then
> > checks the value against "gcc". this doesnt work if $MAKEDEPEND is
> > set to a
> > gcc
On Wednesday 28 October 2009 10:18:10 Stephen Henson via RT wrote:
> > [vap...@gentoo.org - Mon Oct 26 13:59:37 2009]:
> >
> > the current util/domd script defaults $MAKEDEPEND to `makedepend` and
> > then
> > checks the value against "gcc". this doesnt work if $MAKEDEPEND is
> > set to a
> > gcc
the current util/domd script defaults $MAKEDEPEND to `makedepend` and then
checks the value against "gcc". this doesnt work if $MAKEDEPEND is set to a
gcc compiler by another name (i686-pc-linux-gcc, cc, etc...). so invert the
script logic so that it runs the makedepend code when using makedep
a bunch of the top level targets do not list their dependencies which means
building in parallel will often fail
patch is against OpenSSL_0_9_8-stable
-mike
Index: Makefile.org
===
RCS file: /usr/local/src/openssl/CVSROOT/openssl/Ma
the openssl man pages should mention the headers that need to be included in
order to use the function in question. the function prototypes should also be
indented slightly for the perl code to process things correctly (and match the
rest of the .pod file styles).
patch is against OpenSSL_0_9_
the engines/Makefile install target will try to install files into
$(INSTALL_PREFIX)$(INSTALLTOP)/lib/engines, but it doesnt make sure the
directory exists before doing so. simple patch to use the included mkdir-p.pl
script to create the dir first.
the trivial patch is against the OpenSSL_0_9_
if the toolchain env vars $AR and/or $RANLIB are set in the environment, the
Configure script should default to those. this matches behavior of many other
package build systems (like autotools) and usage already in place in openssl
itself (CC/etc...).
patch is against OpenSSL_0_9_8-stable, but
if building on a system with GNU make installed as `gmake` and a
deficient/old/broken/crappy version of make installed as `make`, the perl
Configure script will hard code `make` when processing the links target
regardless of the make that was used.
this patch will leverage the env var $MAKE ins
On Sunday 06 January 2008, David Schwartz wrote:
> > looks to me like tar+lzma is the way to go, not 7z
>
> In my quick test, lzma got a 7.6, beating 7z by a negligible margin.
>
> I think it largely comes down to whether any of these are popular enough to
> justify the effort of offering in that f
On Sunday 06 January 2008, David Schwartz wrote:
> > Hi,
> >
> > the 7-Zip archiver has recently become very popular because of
> > its good compression rate;
> > f.e. recent snapshot is about 34% smaller when packed with 7z
> > compared to tar.gz:
> >
> > -rw-r--r-- 1 root root 2484981 Jan 5 17:
i was flipping through the tracker when i noticed #1342
(bug/gentoo/bashdb/stdin) ... this isnt an openssl by any means so the ticket
can simply be punted
-mike
signature.asc
Description: This is a digitally signed message part.
On Friday 22 December 2006 10:58, Andy Polyakov wrote:
> > right now you need to include sys/types.h yourself before trying to
> > include openssl/sha.h or the build fails ... this patch does what some of
> > other openssl headers do and include sys/types.h properly
>
> This is about size_t, isn't
On Tuesday 12 September 2006 18:10, James Jones wrote:
> Is anyone aware that digium is using openssl in there g729 codec code
> and license registration with it display the openssl copyright info.
what's your point ?
-mike
__
Ope
On Tuesday 16 May 2006 10:56, Brad House wrote:
> It's the GPL license that's broken, not OpenSSL. I believe the main
> reason that you cannot link with OpenSSL's license is because of the
> BSD with credit/advertising clause.
the advertising clause was dropped from the BSD license a long time ag
it's nice when a build system respects the env settings of CC/AR/RANLIB so
here's a minor patch to Configure to do just that
-mike
--- Configure
+++ Configure
@@ -949,7 +949,7 @@
print "IsMK1MF=$IsMK1MF\n";
my @fields = split(/\s*:\s*/,$table{$target} . ":" x 30 , -1);
-my $cc = $fields[$idx_c
this patch adds an #include line to pod files that document API but dont
mention the header file where you can find the documented functions
also, i indented a few files as the standard seems to be to have one leading
space with prototypes
-mike
--- doc/crypto/ASN1_generate_nconf.pod
+++ doc/cry
On Wednesday 15 February 2006 06:04, Gisle Vanem wrote:
> "Mike Frysinger" <[EMAIL PROTECTED]> wrote:
> > On Tuesday 14 February 2006 11:26, Gisle Vanem wrote:
> >> Some of the new ts/ files are too long for a 8+3 filesystem.
> >
> > a ton of files
On Tuesday 14 February 2006 11:26, Gisle Vanem wrote:
> Some of the new ts/ files are too long for a 8+3 filesystem.
a ton of files are too long for 8+3 filesystem in the openssl tarball
-mike
__
OpenSSL Project
simple patch ... the current config script does not force LC_ALL=C when
running sed with [a-z] ... this will break in some locales where Z is not the
last letter
-mike
__
OpenSSL Project http://ww
attached patch is against current cvs head to add support for m68k linux
targets
-mike
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.o
On Saturday 14 January 2006 12:02, Lee Thompson wrote:
> How does this approach look? Should be more generic.
looks much more sane
> +# --with-rpath Use rpath linking, only makes sense with the use of
> shared.
might want to say the "shared libraries" or "the shared option"
> +#
On Friday 13 January 2006 11:38, Lee Thompson wrote:
> The code certainly runs so is your issue a point of
> coding style?
just because the path is correct on your machine has no relevance to anyone
else, and forcing people to install into "/opt/assembly/lib" wont fly
-mike
__
On Friday 13 January 2006 01:48, Lee Thompson wrote:
> I'd be interested in your thoughts on this approach.
well your hardcoding of "-Wl,-R/opt/assembly/lib" in the linux-elf-rpath line
certainly wont work ...
-mike
__
OpenSSL Pr
On Wed, Nov 09, 2005 at 05:38:39PM +0100, Andy Polyakov wrote:
> >(and doesn't affect any non-linux platform anyway).
>
> How come it turns from unsure "should be portable" to definitive
> "doesn't affect" so easily:-)
it should be portable across all ELF targets ... after all, you're just addin
On Wed, Nov 09, 2005 at 03:21:20PM +0100, Dirk Mueller wrote:
> On Wednesday 09 November 2005 15:15, Mike Frysinger wrote:
>
> > btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to
> > generate some source files which are included in the final lib, it&#x
On Wed, Nov 09, 2005 at 02:39:47PM +0100, Dirk Mueller wrote:
> Ok, thanks for your help and the hint. I'd like to suggest the following
> patch
> for inclusion into OpenSSL.
thanks, we've just been forcing -Wa,--noexecstack in Gentoo ... this is much
nicer :)
btw, does x86nasm.pl need to be f
On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote:
> the appended patch makes libcrypto.so compile without executable stack
> requirements. it should be portable accross all versions of binutils (and
> doesn't affect any non-linux platform anyway).
it will break non-ELF builds though
On Thursday 06 October 2005 01:44 pm, Anil Gunturu wrote:
> Looks like latest openssl-0.9.8 doesn't have it
this is why more details is better :p
with 0.9.8, a lot of the linux targets were consolidated ... so try running:
./Configure linux-generic32 -DL_ENDIAN ...
-mike
_
On Thursday 06 October 2005 04:58 am, Anil Gunturu wrote:
> I am having trouble compiling compiling openssl for linux arm? I have
> added a target for linux-arm-elf (similar to linux-elf), but got rid of
> references to x86
why ? a linux-elf-arm target already exists ... i use it to cross-compil
On Saturday 03 September 2005 03:19 pm, Dan Kegel wrote:
> Denis Andreevich wrote:
> > Ok... ok... If you do not want use 7zip because it is win-app,
7zip is hardly standard and rarely found on any machine, regardless of
operating system
> > but why you don't want use "standard" tool like bzip2?
find attached a small patch which detects endian settings when building on
SuperH machines ... this applies cleanly to cvs HEAD and the 0.9.8 branch but
needs a little manual intervention for 0.9.7 branch
-mike
__
OpenSSL Projec
On Monday 13 June 2005 12:19 am, Richard Levitte - VMS Whacker wrote:
> OpenSSL version 0.9.8 Beta 5
`./config && make && make test` passed on Gentoo/armel
Gentoo/armeb failed the x509 certificate test ('test_ss') due to lack of
enough random data, but i'm pretty sure that's a system issue and
1 - 100 of 113 matches
Mail list logo
