No matter. As soon as we have to perform a new build (will be done on Visual
Studio 2015 later this year) and I discover the same issue, I will report it.
Kees
-Original Message-
From: Rich Salz via RT [mailto:r...@openssl.org]
Sent: Tuesday, February 02, 2016 22:16
To: Kees Dekker
Cc:
Hi,
It unfortunately took a long time that I was able to check the problem below
again. The proposed fix is incorrect. Because the .mak file is generated by
util/mk1mf.pl, the change should be done on top of that file. Both for
openssl1.0.1e as well as for openssl1.0.1g the following diff can b
Hi,
It may be useful to add the .pdb file to the lib directory in the install
target. Windows build that adopt OpenSSL may benefit from it. When using
ssleay32.lib and/or libeay32.lib then Visual Studio may complain about missing
symbol information. That information is in the pdb file. If a pdb
I think you can indeed remove ar rs completely for 64-bit sparc too... In a 10
year timeframe some things may have changed... It is really impressive that you
found something in your archive that happened so long ago. If you put Solaris
10 as minimum OS version, then you can safely remove that a
Hi,
I used a slightly modified script:
if (@ARGV[0]) {
while(<>) { print "foo".$_; }
} else {
print "Running on $^O, using: $^X, version $]\n";
open STDOUT,"| \"$^X\" $0 -";
print "bar\n";
close STDOUT;
}
Results (the first sentence is comment
FYI:
When building OpenSSL, using the solaris64-sparcv9-cc config, then RANLIB uses
ar -rs as RANLIB command. Solaris 10 on UltraSparc (in my case a V440 system)
suffers from a bug in:
/usr/ccs/bin/ar:
SunOS 5.10 Generic 144500-19 Jul 2011
/etc/release:
Oracle Solari
It is indeed the quoting of the perl command interpreter issue.
I also work often on *nix platforms, and tested with \"$^X\", which worked. But
I can’t guarantee that too for all *nix flavors... It may be worth trying it
(unless someone else complains).
If you are unsure for a certain *nix fl
Andy,
Thanks for explanation.
As answer on your question whether ml64.exe is existent: when setting Visual
Studio 2010 (SP1) x64 command line environment, ml64.exe is accessible via the
path (in c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\bin\amd64\ml64.exe).
Microsoft has al
Hi,
In addition to my previous email:
The utils\pl\VC-32.pl always add (not taking care for no-asm option) the
following line
$banner.=<<'___' if ($FLAVOR =~ /WIN64/);
CRYPTOOBJ=ms\uptable.obj $(CRYPTOOBJ)
Although I did not test it, I can imagine that the 32-bit build also like
Hi,
I noticed that the Microsoft Assembler compiler support has gone, however, I
also found that ms\do_ms.bat does NOT use assembly (no-asm flag is used), while
ms\do_win64a.bat silently expects nasm compiler (according to INSTALL.WIN32 the
only supported assembly compiler). Similar is true (bu
Hi,
Something may be wrong, but I'm not sure. At least te output below gives some
confusion regarding possible errors. See transcript below. The Operating system
is Windows XP, the compiler is visual studio 2005 SP1. The necessary steps to
build openSSL are performed as custom build step from w
Hi,
Openssl1.0.0d contains a typo in a ifndef directive, see transscript below.
This bug pops up in a build on a Tru64 V5.1B system.
DOPENSSL_BN_ASM_MONT -c -o bn_asm.o bn_asm.c
/bin/perl asm/alpha-mont.pl | cc -E - | tee alpha-mont.s > /dev/null
cc: Warning: , line 1: "indef" is an invalid pr
Just one idea, which popped up today.
What about of using UuidCreate() function, see:
http://msdn.microsoft.com/en-us/library/aa379205(VS.85).aspx
In our case, our software runs as a service, in its own desktop/winstation.
That desktop does not have a bitmap at all, or if it has one, it is alway
Hi,
Yes, this patch worked, thanks, i.e. my application to not crash anymore upon
startup/init.
Unfortunatelly, I was still not able to file a defect to Sun. I will still try
to file the conflict with -lmalloc + ldevinfo to Sun, but I'm not sure whether
this will succeed.
Anyhow, the ur
I will try. I will send an update when done.
Kees
-Original Message-
From: Andy Polyakov via RT [mailto:r...@openssl.org]
Sent: Tuesday, 07 September, 2010 09:47
To: Kees Dekker
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #2321] bug report: core dump on OPENSSL_cpuid_set
Hi,
What do you mean with the last paragraph in your email?
Do you like to make a fix, in such way that the sun way becomes more similar to
the linux way?
I will update when I can get a fix from SUN. In the meanwhile - since we can't
easily set env.vars., because our program is a network s
Mistake: openssl linked -lmalloc + mallopt(M_KEEP,0) ran on USII (no vis2).
Our own application still crashed. Anyhow, this is something for Sun to fix IMO.
Kees
-Original Message-
From: Kees Dekker
Sent: Thursday, 26 August, 2010 14:16
To: 'r...@openssl.org'
Cc: openssl-dev@ope
Hi,
Sorry, I forgot to test with mallinfo(). Now added a call in sparcv9cap.c, just
before dlopen(), but it did not solve the problem :-(.
The reproduction provided by you also crashed on my SparcIII machine if
-lmalloc was used. A call to mallopt(M_KEEP,0) did not solve the SIGSEGV,
becau
Hi,
Why does Solaris 10 on SparcIII not suffer from this problem, is unclear to me.
We always use -lmalloc for our application, and have only one solaris 10 build
(used on all Solaris systems, regardless the processor type).
Unfortunatelly, (our) support for Solaris is system limited, and w
Addition: building the openssl application with -lmalloc results in the same
coredump
May be dlopen(libdevinfo.so.1) and using -lmalloc does not work together (at
least on UltraSparcII).
Kees
> -Original Message-
> From: Kees Dekker
> Sent: Tuesday, 24 August, 2010 14:25
> T
> -Original Message-
> From: Andy Polyakov via RT [mailto:r...@openssl.org]
> Sent: Monday, 23 August, 2010 17:23
> To: Kees Dekker
> Cc: openssl-dev@openssl.org
> Subject: Re: [openssl.org #2321] bug report: core dump on
> OPENSSL_cpuid_setup() on Solaris 10 with a Sun Enterprise
Hi,
> -Original Message-
> From: Andy Polyakov via RT [mailto:r...@openssl.org]
> Sent: Saturday, 21 August, 2010 14:42
> To: Kees Dekker
> Cc: openssl-dev@openssl.org
> Subject: Re: [openssl.org #2321] bug report: core dump on
> OPENSSL_cpuid_setup() on Solaris 10 with a Sun Enter
Hi,
The 32-bit of openSSL 1.0.0a (solaris-sparcv9-cc configuration) coredumps upon
initialization. The stack trace is (of our product binary):
#0 0xff360c90 in free_unlocked () from /usr/lib/libmalloc.so.1
#1 0xff360b78 in free () from /usr/lib/libmalloc.so.1
#2 0x007107a4 in OPENSSL_cpuid_set
Hi,
Many thanks for your quick response. The fix worked. This ticket can be closed
then.
Just a few another questions:
1. Do you know when next release becomes available?
2. Do you continue maintaining both 0.9.x stream and 1.0.x, or will openSSL
move at a certain point to 1.x only? It i
Hi,
When building openSSL on Tru64, 5.1b-3, I get:
$ gmake
making all in crypto...
gmake[1]: Entering directory
`/home/port/MaintASM.night.rel/thirdparty/OpenSSL/32bit/openssl-1.0.0a/crypto'
gmake[1]: *** No rule to make target `alphacpuid.o', needed by
`../libcrypto.a'. Stop.
gmake[1]: Leavin
Most of my systems do not have pkgconfig. The variable passed to cURL was
LDFLAGS=-L, where lib is OpenSSL platform specific, e.g.
-L/lib64 for Linux. With older openssl versions, cURL was happy with
the openssl prefixdir, and assumed that the headers were in
/include and libraries in /lib.
Hi,
cURL uses --prefix to find the include files as well and assumes that the
libraries are in /lib.
Till now, cURL has a possibility to say where the library reside (with LDFLAGS
environment variable).
The problem is (but I'm not 100% sure) that the pkgconfig dir is also not in a
fixed pla
Hi,
I noticed that the output directories of any prefixed (--prefix) OpenSSL build
for some Unix 64-bit flavors changed.
In the past (at least with openSSL openssl-0.9.8k), after calling gmake
install, the include files were in prefix/include, the libraries in prefix/lib.
Due to the changed out
> -Original Message-
> From: Andy Polyakov via RT [mailto:r...@openssl.org]
> Sent: Monday, April 12, 2010 12:08
> To: Kees Dekker
> Cc: openssl-dev@openssl.org
> Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll
>
> > May be there is another method to check wether
> -Original Message-
> From: Andy Polyakov via RT [mailto:r...@openssl.org]
> Sent: Saturday, April 10, 2010 23:33
> To: Kees Dekker
> Cc: openssl-dev@openssl.org
> Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll
>
> > I agree that OPENSSL_isservice() cannot be ch
> -Original Message-
> From: Andy Polyakov via RT [mailto:r...@openssl.org]
> Sent: Monday, March 22, 2010 22:48
> To: Kees Dekker
> Cc: openssl-dev@openssl.org
> Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll
>
> >>> I agree that OPENSSL_isservice() cannot be change
>
> > I agree that OPENSSL_isservice() cannot be changed,
>
> ??? My suggestion for *you* was to modify it to
> unconditionally return 1...
Our application can both run in foreground and in service context. So simply
changing to return 1 is not possible.
May be there is another method to check
> -Original Message-
> From: Kees Dekker
> Sent: Tuesday, March 16, 2010 22:53
> To: 'r...@openssl.org'
> Cc: openssl-dev@openssl.org
> Subject: RE: [openssl.org #2194] Unwanted dependencies to user32.dll
>
> > -Original Message-
> > From: Andy Polyakov via RT [mailto:r...@openssl
> -Original Message-
> From: Andy Polyakov via RT [mailto:r...@openssl.org]
> Sent: Tuesday, March 16, 2010 22:23
> To: Kees Dekker
> Cc: openssl-dev@openssl.org
> Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll
>
> > When building openSSL on Windows with:
> >
> > *
Hi,
When building openSSL on Windows with:
* CONFIG=VC-WIN64A or CONFIG=VC-WIN32
* no-shared no-threads -DWINVER==0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS
* With Visual Studio 2005
I get dependencies to user32.dll, when using libeay32.lib, e.g:
2>libeay32.lib(rand_win.obj) : err
Hi,
Many thanks for this info.
Thanks,
Kees
BTW. the lowest supported linux version for Suse is Suse 9, which has gcc
3.3.3. The -m32 is already supported there. You may consider to put gcc 3.3.3
as minimum version? Unfortunatelly, I don't have a 64-bit box with this
compiler to test it.
--
Hi,
The build of 32-bit openSSL (openssl-0.9.8k) fails on x64 systems with the
following error (and more similar errors like these):
x86cpuid-elf.s:13: Error: suffix or operands invalid for `push'
This problem can be fixed by adding -m32 to Configure for the linux-elf
configuration, see the di
37 matches
Mail list logo