Re: [openssl-dev] Build issue

2017-08-02 Thread Matthew Stickney 
Aha, victory! Turns out this was a line-ending problem: after removing
the mingw perl, the mkdef.pl debug output had (among many, many other
things), the following when I went looking for MD2 references:

> DEBUG: include/openssl/md2.h: found tag OPENSSL_NO_MD2^M = -1

I checked, and sure enough the md2 header had windows line endings.
core.autocrlf was false, and core.eol was lf, so I'm not sure how only
some headers had the wrong line endings, but an "rm -rf * && git
checkout ." produced a working build.

Thanks for the time and assistance, everybody.

-Matt Stickney

On Wed, Aug 2, 2017 at 4:07 AM, Matt Caswell  wrote:
>
>
> On 02/08/17 03:19, Matthew Stickney wrote:
>> Ok, progress (sort of)! It turns out I was indeed using the wrong
>> version of perl -- I was using the perl that was installed as part of
>> the msys2 base-devel group, not the mingw-w64--perl package,
>> which is a whole separate thing.
>
>
> Errr no. You were right the first time - you should be using the msys2
> perl. This is my perl --version output:
>
> This is perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-msys-thread-multi
>
> Do NOT use the mingw perl (I think Richard misspoke when he said this
> before - the "matching perl" requirement means that using msys2 shell
> requires msys2 perl).
>
> Just to check - you are using the msys2 shell right?
>
> Matt
>
>
>>
>> However, having installed the mingw-w64 version of perl, the configure
>> script is failing because it thinks this is a unix-like platform, but
>> perl is producing windows-style paths:
>>
>>> This perl implementation doesn't produce Unix like paths (with forward slash
>>> directory separators).  Please use an implementation that matches your
>>> building platform.
>>
>>> This Perl version: 5.22.0 for MSWin32-x64-multi-thread
>>
>> I can't follow the configure script well enough to tell where it's
>> detecting the relevant bits from -- the build_scheme key seems to be
>> responsible for triggering the unix-checker.pm script that fails, but
>> grep only turns up two references to it: the readme, and the configure
>> script. Is this an issue with msys2+mingw-w64 environments?
>>
>> -Matt Stickney
>>
>> On Tue, Aug 1, 2017 at 8:54 AM, Sergio NNX  wrote:
 Ok, I have still not been able to reproduce this.
>>>
>>> Neither have I!
>>>
>>>
>>> I've just downloaded OpenSSL 1.1.0f and built it from source.
>>>
>>> This is my configuration:
>>>
>>>
>>> Microsoft Windows [Version 10.0.15063]
>>>
>>> This is perl 5, version 24, subversion 1 (v5.24.1)
>>>
>>> GCC v6.3.0 (64-bit)
>>>
>>>
>>> ./config mingw64  
>>>
>>> make depend
>>>
>>> make all
>>>
>>>
>>> After a while, I get the executable and libraries.
>>>
>>>
>>> OpenSSL 1.1.0f  25 May 2017
>>> built on: reproducible build, date unspecified
>>> platform: mingw64
>>>
>>>
>>> perl util/mkdef.pl 32 crypto debug 2> mkdef-debug.txt > /dev/null
>>> [It generates a huge file (125MB)]
>>>
>>> Cheers.
>>>
>>> Ser/
>>>
>>>
>>> P.S.: Try to use a more specific subject next time!
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-08-02 Thread Matt Caswell 


On 02/08/17 03:19, Matthew Stickney wrote:
> Ok, progress (sort of)! It turns out I was indeed using the wrong
> version of perl -- I was using the perl that was installed as part of
> the msys2 base-devel group, not the mingw-w64--perl package,
> which is a whole separate thing.


Errr no. You were right the first time - you should be using the msys2
perl. This is my perl --version output:

This is perl 5, version 22, subversion 1 (v5.22.1) built for
x86_64-msys-thread-multi

Do NOT use the mingw perl (I think Richard misspoke when he said this
before - the "matching perl" requirement means that using msys2 shell
requires msys2 perl).

Just to check - you are using the msys2 shell right?

Matt


> 
> However, having installed the mingw-w64 version of perl, the configure
> script is failing because it thinks this is a unix-like platform, but
> perl is producing windows-style paths:
> 
>> This perl implementation doesn't produce Unix like paths (with forward slash
>> directory separators).  Please use an implementation that matches your
>> building platform.
> 
>> This Perl version: 5.22.0 for MSWin32-x64-multi-thread
> 
> I can't follow the configure script well enough to tell where it's
> detecting the relevant bits from -- the build_scheme key seems to be
> responsible for triggering the unix-checker.pm script that fails, but
> grep only turns up two references to it: the readme, and the configure
> script. Is this an issue with msys2+mingw-w64 environments?
> 
> -Matt Stickney
> 
> On Tue, Aug 1, 2017 at 8:54 AM, Sergio NNX  wrote:
>>> Ok, I have still not been able to reproduce this.
>>
>> Neither have I!
>>
>>
>> I've just downloaded OpenSSL 1.1.0f and built it from source.
>>
>> This is my configuration:
>>
>>
>> Microsoft Windows [Version 10.0.15063]
>>
>> This is perl 5, version 24, subversion 1 (v5.24.1)
>>
>> GCC v6.3.0 (64-bit)
>>
>>
>> ./config mingw64  
>>
>> make depend
>>
>> make all
>>
>>
>> After a while, I get the executable and libraries.
>>
>>
>> OpenSSL 1.1.0f  25 May 2017
>> built on: reproducible build, date unspecified
>> platform: mingw64
>>
>>
>> perl util/mkdef.pl 32 crypto debug 2> mkdef-debug.txt > /dev/null
>> [It generates a huge file (125MB)]
>>
>> Cheers.
>>
>> Ser/
>>
>>
>> P.S.: Try to use a more specific subject next time!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-08-02 Thread Richard Levitte 
In message  
on Tue, 1 Aug 2017 22:19:20 -0400, Matthew Stickney  said:

mtstickney> However, having installed the mingw-w64 version of perl, the 
configure
mtstickney> script is failing because it thinks this is a unix-like platform, 
but
mtstickney> perl is producing windows-style paths:
mtstickney> 
mtstickney> > This perl implementation doesn't produce Unix like paths (with 
forward slash
mtstickney> > directory separators).  Please use an implementation that matches 
your
mtstickney> > building platform.
mtstickney> 
mtstickney> > This Perl version: 5.22.0 for MSWin32-x64-multi-thread
mtstickney> 
mtstickney> I can't follow the configure script well enough to tell where it's
mtstickney> detecting the relevant bits from -- the build_scheme key seems to be
mtstickney> responsible for triggering the unix-checker.pm script that fails, 
but
mtstickney> grep only turns up two references to it: the readme, and the 
configure
mtstickney> script. Is this an issue with msys2+mingw-w64 environments?

OR unix-checker.pem might be buggy.  May I suggest insert this line
before the check, try again and see what it says?

print STDERR "Current directory: ", rel2abs('.'), "\n";

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-08-01 Thread Matthew Stickney 
Ok, progress (sort of)! It turns out I was indeed using the wrong
version of perl -- I was using the perl that was installed as part of
the msys2 base-devel group, not the mingw-w64--perl package,
which is a whole separate thing.

However, having installed the mingw-w64 version of perl, the configure
script is failing because it thinks this is a unix-like platform, but
perl is producing windows-style paths:

> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.

> This Perl version: 5.22.0 for MSWin32-x64-multi-thread

I can't follow the configure script well enough to tell where it's
detecting the relevant bits from -- the build_scheme key seems to be
responsible for triggering the unix-checker.pm script that fails, but
grep only turns up two references to it: the readme, and the configure
script. Is this an issue with msys2+mingw-w64 environments?

-Matt Stickney

On Tue, Aug 1, 2017 at 8:54 AM, Sergio NNX  wrote:
>> Ok, I have still not been able to reproduce this.
>
> Neither have I!
>
>
> I've just downloaded OpenSSL 1.1.0f and built it from source.
>
> This is my configuration:
>
>
> Microsoft Windows [Version 10.0.15063]
>
> This is perl 5, version 24, subversion 1 (v5.24.1)
>
> GCC v6.3.0 (64-bit)
>
>
> ./config mingw64  
>
> make depend
>
> make all
>
>
> After a while, I get the executable and libraries.
>
>
> OpenSSL 1.1.0f  25 May 2017
> built on: reproducible build, date unspecified
> platform: mingw64
>
>
> perl util/mkdef.pl 32 crypto debug 2> mkdef-debug.txt > /dev/null
> [It generates a huge file (125MB)]
>
> Cheers.
>
> Ser/
>
>
> P.S.: Try to use a more specific subject next time!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-08-01 Thread Sergio NNX 
> Ok, I have still not been able to reproduce this.

Neither have I!


I've just downloaded OpenSSL 1.1.0f and built it from source.

This is my configuration:


Microsoft Windows [Version 10.0.15063]

This is perl 5, version 24, subversion 1 (v5.24.1)

GCC v6.3.0 (64-bit)


./config mingw64  

make depend

make all


After a while, I get the executable and libraries.


OpenSSL 1.1.0f  25 May 2017
built on: reproducible build, date unspecified
platform: mingw64


perl util/mkdef.pl 32 crypto debug 2> mkdef-debug.txt > /dev/null
[It generates a huge file (125MB)]


Cheers.


Ser/


P.S.: Try to use a more specific subject next time!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-08-01 Thread Richard Levitte 
Ok, I have still not been able to reproduce this.

We have already established that the perl you use is the mingw one,
haven't we?  (if we haven't, that really needs to be checked.
Matching perl and all that)

A test to figure out is this:

perl util/mkdef.pl 32 crypto debug 2> mkdef-debug.txt > /dev/null

Then let someone who knows mkdef look at the output.  I would usually
volunteer, but my time is currently limited (on vacation), so I won't
be able to look at it before mid August.  The debug output is messy,
fair warning.

Cheers,
Richard

In message  
on Mon, 31 Jul 2017 21:07:07 -0400, Matthew Stickney  
said:

mtstickney> I swear I sent my last reply to the list; either my mail client is
mtstickney> messing with me, or I'm going crazy. There's no reason for this to 
be
mtstickney> off-list, and that wasn't my intention in the first place.
mtstickney> 
mtstickney> Anyhow: util/libcrypto.num doesn't seem to have anything unusual in 
it
mtstickney> associated with '_num', so that's fine, but then neither does
mtstickney> crypto.def, so it seems like it's not an issue with util/mkdef.pl. I
mtstickney> mean, obviously the error is /somewhere/
mtstickney> 
mtstickney> -Matt Stickney
mtstickney> 
mtstickney> On Mon, Jul 31, 2017 at 10:22 AM, Matthew Stickney 
 wrote:
mtstickney> > Thanks for the suggestion, and my apologies: I didn't intend to 
take
mtstickney> > this off-list. I'll check libcrypto.num when I get back on the 
machine
mtstickney> > tonight. If it helps, I am building this with 64-bit mingw, but I
mtstickney> > don't see how that would have an effect (there are build warnings
mtstickney> > earlier in the process, but from what I've seen they look 
harmless).
mtstickney> >
mtstickney> > -Matt Stickney
mtstickney> >
mtstickney> > On Mon, Jul 31, 2017 at 10:17 AM, Richard Levitte 
 wrote:
mtstickney> >> util/mkdef.pl picks up all the data from configdata.pm, and 
regarding
mtstickney> >> options, it looks at $config{options}, which includes everything
mtstickney> >> that's disabled by default.
mtstickney> >>
mtstickney> >> This all is an issue that I'm currently labeling *weird*, 'cause 
it
mtstickney> >> makes no sense at all.  Most of all, this line really has me 
gawking,
mtstickney> >> scratching my head and generally looking silly:
mtstickney> >>
mtstickney> >> Error: _num does not have a number assigned
mtstickney> >>
mtstickney> >> Basically, it looks like *something* is getting ba-a-a-a-dly 
parsed,
mtstickney> >> and I have no idea if that's in util/libcrypto.num (could you 
try and
mtstickney> >> grep for '_num' and possibly '^_num' to see if you can find 
something
mtstickney> >> weird?) or if it's a serious corner case cock up in 
util/mkdef.pl.
mtstickney> >>
mtstickney> >> Worst thing is, I haven't been able to reproduce...  I am going 
to try
mtstickney> >> again just now, with the hope that 32-bit mingw doesn't make a
mtstickney> >> difference...
mtstickney> >>
mtstickney> >> Cheers,
mtstickney> >> Richard
mtstickney> >>
mtstickney> >> In message  on 
Mon, 31 Jul 2017 09:02:15 -0500, Benjamin Kaduk  said:
mtstickney> >>
mtstickney> >> bkaduk> Whoops, I missed that this was unicast when skimming 
mail over the weekend.
mtstickney> >> bkaduk> Looping back in Richard, at least, though if you don't 
mind, putting the list back would be best.
mtstickney> >> bkaduk>
mtstickney> >> bkaduk> Richard, my (extremely) quick skim of mkdef.pl is that 
it is only picking up explicitly set options
mtstickney> >> bkaduk> and not things disabled by default; does that seem 
plausible?
mtstickney> >> bkaduk>
mtstickney> >> bkaduk> -Ben
mtstickney> >> bkaduk>
mtstickney> >> bkaduk> On 07/28/2017 10:38 PM, Matthew Stickney wrote:
mtstickney> >> bkaduk>
mtstickney> >> bkaduk>  [1] has the contents of my crypto.def file, although I 
don't see
mtstickney> >> bkaduk> anything especially odd in there (not that I would know, 
really).
mtstickney> >> bkaduk>
mtstickney> >> bkaduk> I removed the offending symbols from crypto.def, and 
that caused the
mtstickney> >> bkaduk> previously-failing command to succeed. I added some 
print statements
mtstickney> >> bkaduk> to mkdef.pl and configured with "./configure mingw64 
no-rc5 no-md2",
mtstickney> >> bkaduk> and mkdef.pl appeared to be adding them to its list of 
disabled
mtstickney> >> bkaduk> algorithms, but the MD2 and RC5 symbols are still in 
crypto.def. I'm
mtstickney> >> bkaduk> no perl hacker, but I'll play around with it a bit.
mtstickney> >> bkaduk>
mtstickney> >> bkaduk> If I hand-remove the undefined symbols, building libssl 
fails with
mtstickney> >> bkaduk> undefined references if I run make again, and if I run 
make again
mtstickney> >> bkaduk> after that, building engines/e_capi.o fails with similar 
errors
mtstickney> >> bkaduk>

Re: [openssl-dev] Build issue

2017-07-31 Thread Matthew Stickney 
I swear I sent my last reply to the list; either my mail client is
messing with me, or I'm going crazy. There's no reason for this to be
off-list, and that wasn't my intention in the first place.

Anyhow: util/libcrypto.num doesn't seem to have anything unusual in it
associated with '_num', so that's fine, but then neither does
crypto.def, so it seems like it's not an issue with util/mkdef.pl. I
mean, obviously the error is /somewhere/

-Matt Stickney

On Mon, Jul 31, 2017 at 10:22 AM, Matthew Stickney  wrote:
> Thanks for the suggestion, and my apologies: I didn't intend to take
> this off-list. I'll check libcrypto.num when I get back on the machine
> tonight. If it helps, I am building this with 64-bit mingw, but I
> don't see how that would have an effect (there are build warnings
> earlier in the process, but from what I've seen they look harmless).
>
> -Matt Stickney
>
> On Mon, Jul 31, 2017 at 10:17 AM, Richard Levitte  wrote:
>> util/mkdef.pl picks up all the data from configdata.pm, and regarding
>> options, it looks at $config{options}, which includes everything
>> that's disabled by default.
>>
>> This all is an issue that I'm currently labeling *weird*, 'cause it
>> makes no sense at all.  Most of all, this line really has me gawking,
>> scratching my head and generally looking silly:
>>
>> Error: _num does not have a number assigned
>>
>> Basically, it looks like *something* is getting ba-a-a-a-dly parsed,
>> and I have no idea if that's in util/libcrypto.num (could you try and
>> grep for '_num' and possibly '^_num' to see if you can find something
>> weird?) or if it's a serious corner case cock up in util/mkdef.pl.
>>
>> Worst thing is, I haven't been able to reproduce...  I am going to try
>> again just now, with the hope that 32-bit mingw doesn't make a
>> difference...
>>
>> Cheers,
>> Richard
>>
>> In message  on Mon, 31 Jul 
>> 2017 09:02:15 -0500, Benjamin Kaduk  said:
>>
>> bkaduk> Whoops, I missed that this was unicast when skimming mail over the 
>> weekend.
>> bkaduk> Looping back in Richard, at least, though if you don't mind, putting 
>> the list back would be best.
>> bkaduk>
>> bkaduk> Richard, my (extremely) quick skim of mkdef.pl is that it is only 
>> picking up explicitly set options
>> bkaduk> and not things disabled by default; does that seem plausible?
>> bkaduk>
>> bkaduk> -Ben
>> bkaduk>
>> bkaduk> On 07/28/2017 10:38 PM, Matthew Stickney wrote:
>> bkaduk>
>> bkaduk>  [1] has the contents of my crypto.def file, although I don't see
>> bkaduk> anything especially odd in there (not that I would know, really).
>> bkaduk>
>> bkaduk> I removed the offending symbols from crypto.def, and that caused the
>> bkaduk> previously-failing command to succeed. I added some print statements
>> bkaduk> to mkdef.pl and configured with "./configure mingw64 no-rc5 no-md2",
>> bkaduk> and mkdef.pl appeared to be adding them to its list of disabled
>> bkaduk> algorithms, but the MD2 and RC5 symbols are still in crypto.def. I'm
>> bkaduk> no perl hacker, but I'll play around with it a bit.
>> bkaduk>
>> bkaduk> If I hand-remove the undefined symbols, building libssl fails with
>> bkaduk> undefined references if I run make again, and if I run make again
>> bkaduk> after that, building engines/e_capi.o fails with similar errors
>> bkaduk> (probably related, but seems strange that libssl is ignored after the
>> bkaduk> first failure). Some logs below.
>> bkaduk>
>> bkaduk> -Matt Stickney
>> bkaduk>
>> bkaduk> [1] 
>> https://gist.github.com/mtstickney/eac60bb98cafc9b978407cbb0a466cdc
>> bkaduk> [2] 
>> http://openssl.6102.n7.nabble.com/Issues-with-latest-snapshot-td36148.html
>> bkaduk>
>> bkaduk> perl ./util/mkrc.pl libssl-1_1-x64.dll | windres --target=pe-x86-64 
>> -o rc.o
>> bkaduk> LD_LIBRARY_PATH=.: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS 
>> -DOPENSSL_NO_STATI
>> bkaduk> C_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
>> -DOPENSSL_BN_AS
>> bkaduk> M_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
>> -DRC4_ASM -DM
>> bkaduk> D5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM 
>> -DECP_NISTZ256_ASM -DPADLOC
>> bkaduk> K_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" 
>> -DENGINESDIR="/usr/local/lib/
>> bkaduk> engines-1_1" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE 
>> -m64 -Wall -O
>> bkaduk> 3 -D_MT -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic 
>> -Wl,--out-implib,libssl.
>> bkaduk> dll.a ssl.def rc.o -o libssl-1_1-x64.dll -Wl,--whole-archive 
>> libssl.a -Wl,--no-w
>> bkaduk> hole-archive -L. -lcrypto -lws2_32 -lgdi32 -lcrypt32
>> bkaduk> libssl.a(ssl_init.o):ssl_init.c:(.text+0x276): undefined reference 
>> to `err_free_
>> bkaduk> strings_int'
>> bkaduk> libssl.a(ssl_lib.o):ssl_lib.c:(.text+0x1d6c): undefined reference to 
>> `d2i_PUBKEY
>> bkaduk> '
>> bkaduk> libssl.a(ssl_lib.o):ssl_lib.c:(.text+0x1ef9):

Re: [openssl-dev] Build issue

2017-07-28 Thread Benjamin Kaduk via openssl-dev 
On 07/28/2017 01:22 AM, Matthew Stickney wrote:
> With a make distclean, ./config, make depend (didn't appear to do
> anything), and a make, I'm getting the essentially the same thing:
>
> Error: _num does not have a number assigned
> /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres 
> --target=pe-x86-64
> -o rc.o
> LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS 
> -DOPENSSL_NO_STATIC
> _ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
> -DOPENSSL_BN_ASM
> _MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM 
> -DMD
> 5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
> -DPADLOCK
> _ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" 
> -DENGINESDIR="/usr/local/lib/e
> ngines-1_1" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall 
> -O3
>  -D_MT -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic 
> -Wl,--out-implib,libcrypt
> o.dll.a crypto.def rc.o -o libcrypto-1_1-x64.dll -Wl,--whole-archive 
> libcrypto.a
>  -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32
> Cannot export MD2: symbol not defined
> Cannot export MD2_Final: symbol not defined
> Cannot export MD2_Init: symbol not defined
> Cannot export MD2_Update: symbol not defined
> Cannot export MD2_options: symbol not defined
> Cannot export RC5_32_cbc_encrypt: symbol not defined
> Cannot export RC5_32_cfb64_encrypt: symbol not defined
> Cannot export RC5_32_decrypt: symbol not defined
> Cannot export RC5_32_ecb_encrypt: symbol not defined
> Cannot export RC5_32_encrypt: symbol not defined
> Cannot export RC5_32_ofb64_encrypt: symbol not defined
> Cannot export RC5_32_set_key: symbol not defined
> collect2.exe: error: ld returned 1 exit status
>

MD2 and RC5 are disabled by default, so it is expected that they will
not be defined.  It is hard to say whether those messages are the source
of the error exit status or just warnings, though.

It's certainly plausible that there are further mkdef.pl issues
responsible, though. Since mkdef.pl generates the crypto.def file
referenced on your link line, maybe you could post that somewhere and
link to it?  (mkdef.pl can also be used to generate .map files, but it
seems like the .def file is the relevant one at the moment.)

But I may have to defer to Richard for the workings of mkdef.pl itself...

-Ben
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-07-28 Thread Matthew Stickney 
With a make distclean, ./config, make depend (didn't appear to do
anything), and a make, I'm getting the essentially the same thing:

Error: _num does not have a number assigned
/usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres --target=pe-x86-64
-o rc.o
LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC
_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM
_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD
5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK
_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/e
ngines-1_1" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3
 -D_MT -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic -Wl,--out-implib,libcrypt
o.dll.a crypto.def rc.o -o libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a
 -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32
Cannot export MD2: symbol not defined
Cannot export MD2_Final: symbol not defined
Cannot export MD2_Init: symbol not defined
Cannot export MD2_Update: symbol not defined
Cannot export MD2_options: symbol not defined
Cannot export RC5_32_cbc_encrypt: symbol not defined
Cannot export RC5_32_cfb64_encrypt: symbol not defined
Cannot export RC5_32_decrypt: symbol not defined
Cannot export RC5_32_ecb_encrypt: symbol not defined
Cannot export RC5_32_encrypt: symbol not defined
Cannot export RC5_32_ofb64_encrypt: symbol not defined
Cannot export RC5_32_set_key: symbol not defined
collect2.exe: error: ld returned 1 exit status

On Thu, Jul 27, 2017 at 11:54 PM, Blumenthal, Uri - 0553 - MITLL
 wrote:
> Instead of "make clean" try "make distclean", then reconfigure and rebuild 
> (don't forget "make depend").
>
> Regards,
> Uri
>
> Sent from my iPhone
>
>> On Jul 27, 2017, at 23:24, Matthew Stickney  wrote:
>>
>>> On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte  
>>> wrote:
>>> Have you tried a 'make clean' and then rebuild?
>>
>> Yep, and building from the 1.1.0 stable branch (failed with different
>> errors), and from a new master.
>>
>>> On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk  wrote:
>>> Can you paste the actual linker invocation that is failing?
>>
>> I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work
>> quite correctly under MSYS2, so I have a build log, and errors,
>> separately. This looks like the relevant part of the build log:
>> make -f ./Makefile.shared -e \
>>ECHO=echo \
>>PLATFORM=mingw64 \
>>PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \
>>INSTALLTOP='/usr/local' LIBDIR='lib' \
>>LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \
>>LIBNAME=crypto SHLIBVERSION=1.1 \
>>STLIBNAME=libcrypto.a \
>>SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \
>>CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
>> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
>> -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
>> -DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN
>> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
>> -D_WINDLL' \
>>LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \
>>RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \
>>link_shlib.mingw-shared
>> make[2]: Entering directory '/c/Users/mts/Desktop/openssl'
>> /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres
>> --target=pe-x86-64 -o rc.o
>> LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
>> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
>> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl"
>> -DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN
>> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
>> -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic
>> -Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o
>> libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a
>> -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32
>>
>> The error messages also contain these, which seem interesting:
>> Error: _num does not have a number assigned
>> Cannot export MD2: symbol not defined
>> Cannot export MD2_Final: symbol not defined
>> Cannot export MD2_Init: symbol not defined
>> Cannot export MD2_Update: symbol not defined
>> Cannot export MD2_options: symbol not defined
>> Cannot export RC5_32_cbc_encrypt: symbol not defined
>> Cannot export RC5_32_cfb64_encrypt: symbol not defined
>> Cannot export RC5_32_decrypt: symbol not

Re: [openssl-dev] Build issue

2017-07-27 Thread Blumenthal, Uri - 0553 - MITLL 
Instead of "make clean" try "make distclean", then reconfigure and rebuild 
(don't forget "make depend").

Regards,
Uri

Sent from my iPhone

> On Jul 27, 2017, at 23:24, Matthew Stickney  wrote:
> 
>> On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte  wrote:
>> Have you tried a 'make clean' and then rebuild?
> 
> Yep, and building from the 1.1.0 stable branch (failed with different
> errors), and from a new master.
> 
>> On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk  wrote:
>> Can you paste the actual linker invocation that is failing?
> 
> I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work
> quite correctly under MSYS2, so I have a build log, and errors,
> separately. This looks like the relevant part of the build log:
> make -f ./Makefile.shared -e \
>ECHO=echo \
>PLATFORM=mingw64 \
>PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \
>INSTALLTOP='/usr/local' LIBDIR='lib' \
>LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \
>LIBNAME=crypto SHLIBVERSION=1.1 \
>STLIBNAME=libcrypto.a \
>SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \
>CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
> -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
> -DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN
> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
> -D_WINDLL' \
>LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \
>RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \
>link_shlib.mingw-shared
> make[2]: Entering directory '/c/Users/mts/Desktop/openssl'
> /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres
> --target=pe-x86-64 -o rc.o
> LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl"
> -DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN
> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
> -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic
> -Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o
> libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a
> -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32
> 
> The error messages also contain these, which seem interesting:
> Error: _num does not have a number assigned
> Cannot export MD2: symbol not defined
> Cannot export MD2_Final: symbol not defined
> Cannot export MD2_Init: symbol not defined
> Cannot export MD2_Update: symbol not defined
> Cannot export MD2_options: symbol not defined
> Cannot export RC5_32_cbc_encrypt: symbol not defined
> Cannot export RC5_32_cfb64_encrypt: symbol not defined
> Cannot export RC5_32_decrypt: symbol not defined
> Cannot export RC5_32_ecb_encrypt: symbol not defined
> Cannot export RC5_32_encrypt: symbol not defined
> Cannot export RC5_32_ofb64_encrypt: symbol not defined
> Cannot export RC5_32_set_key: symbol not defined
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [Makefile.shared:260: link_shlib.mingw] Error 1
> make[1]: *** [Makefile:658: libcrypto.dll.a] Error 2
> make: *** [Makefile:139: all] Error 2
> 
> -Matt Stickney
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-07-27 Thread Matthew Stickney 
On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte  wrote:
> Have you tried a 'make clean' and then rebuild?

Yep, and building from the 1.1.0 stable branch (failed with different
errors), and from a new master.

On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk  wrote:
> Can you paste the actual linker invocation that is failing?

I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work
quite correctly under MSYS2, so I have a build log, and errors,
separately. This looks like the relevant part of the build log:
make -f ./Makefile.shared -e \
ECHO=echo \
PLATFORM=mingw64 \
PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \
INSTALLTOP='/usr/local' LIBDIR='lib' \
LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \
LIBNAME=crypto SHLIBVERSION=1.1 \
STLIBNAME=libcrypto.a \
SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \
CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
-DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
-DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN
-DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
-D_WINDLL' \
LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \
RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \
link_shlib.mingw-shared
make[2]: Entering directory '/c/Users/mts/Desktop/openssl'
/usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres
--target=pe-x86-64 -o rc.o
LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
-DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
-DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl"
-DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN
-DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
-D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic
-Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o
libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a
-Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32

The error messages also contain these, which seem interesting:
Error: _num does not have a number assigned
Cannot export MD2: symbol not defined
Cannot export MD2_Final: symbol not defined
Cannot export MD2_Init: symbol not defined
Cannot export MD2_Update: symbol not defined
Cannot export MD2_options: symbol not defined
Cannot export RC5_32_cbc_encrypt: symbol not defined
Cannot export RC5_32_cfb64_encrypt: symbol not defined
Cannot export RC5_32_decrypt: symbol not defined
Cannot export RC5_32_ecb_encrypt: symbol not defined
Cannot export RC5_32_encrypt: symbol not defined
Cannot export RC5_32_ofb64_encrypt: symbol not defined
Cannot export RC5_32_set_key: symbol not defined
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile.shared:260: link_shlib.mingw] Error 1
make[1]: *** [Makefile:658: libcrypto.dll.a] Error 2
make: *** [Makefile:139: all] Error 2

-Matt Stickney
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-07-27 Thread Richard Levitte 
In message  
on Tue, 25 Jul 2017 20:49:14 -0400, Matthew Stickney  
said:

mtstickney> Possibly. The original errors and hanging perl process have been
mtstickney> replaced with an enormous number of "undefined reference" errors. 
For
mtstickney> example:
mtstickney> libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to 
`BN_ucmp'
mtstickney> libssl.a(tls_srp.o):tls_srp.c:(.text+0xd45): undefined reference to
mtstickney> `OPENSSL_cleanse'
mtstickney> libssl.a(tls_srp.o):tls_srp.c:(.text+0xd5f): undefined reference to 
`SRP_Calc_A'
mtstickney> collect2.exe: error: ld returned 1 exit status
mtstickney> 
mtstickney> I don't know enough about the build system to know whether the
mtstickney> mkdef.pl change might be responsible for this, or whether this is a
mtstickney> separate issue. To follow up on my previous post, the configure line
mtstickney> was indeed "./config", and this is commit 1843787173. Any other data
mtstickney> that I should collect?

Have you tried a 'make clean' and then rebuild?  If the previous run
gave incorrect results, you may have ended up with an incomplete
libcrypto.so, but with timestamps that make it look lite it's already
built.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-07-27 Thread Benjamin Kaduk via openssl-dev 
On 07/25/2017 07:49 PM, Matthew Stickney wrote:
> Possibly. The original errors and hanging perl process have been
> replaced with an enormous number of "undefined reference" errors. For
> example:
> libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to `BN_ucmp'
> libssl.a(tls_srp.o):tls_srp.c:(.text+0xd45): undefined reference to
> `OPENSSL_cleanse'
> libssl.a(tls_srp.o):tls_srp.c:(.text+0xd5f): undefined reference to 
> `SRP_Calc_A'
> collect2.exe: error: ld returned 1 exit status
>
> I don't know enough about the build system to know whether the
> mkdef.pl change might be responsible for this, or whether this is a
> separate issue. To follow up on my previous post, the configure line
> was indeed "./config", and this is commit 1843787173. Any other data
> that I should collect?
>

Hmm, all of the listed examples are for things in libssl failing to find
symbols from libcrypto, which perhaps suggests a link line ordering
issue.  Can you paste the actual linker invocation that is failing?

-Ben
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-07-25 Thread Matthew Stickney 
Possibly. The original errors and hanging perl process have been
replaced with an enormous number of "undefined reference" errors. For
example:
libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to `BN_ucmp'
libssl.a(tls_srp.o):tls_srp.c:(.text+0xd45): undefined reference to
`OPENSSL_cleanse'
libssl.a(tls_srp.o):tls_srp.c:(.text+0xd5f): undefined reference to `SRP_Calc_A'
collect2.exe: error: ld returned 1 exit status

I don't know enough about the build system to know whether the
mkdef.pl change might be responsible for this, or whether this is a
separate issue. To follow up on my previous post, the configure line
was indeed "./config", and this is commit 1843787173. Any other data
that I should collect?

-Matt Stickney
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

2017-07-25 Thread Richard Levitte 
Could it be that this patch fixes the issue?

diff --git a/util/mkdef.pl b/util/mkdef.pl
index b3eb6b3d9d..1f214dbb8b 100755
--- a/util/mkdef.pl
+++ b/util/mkdef.pl
@@ -876,7 +876,7 @@ sub do_defs
# Reduce argument lists to empty ()
# fold round brackets recursively: (t(*v)(t),t) -> 
(t{}{},t) -> {}
while(/\(.*\)/s) {
-   s/\([^\(\)]+\)/\{\}/gs;
+   s/\([^\(\)]*\)/\{\}/gs;
s/\(\s*\*\s*(\w+)\s*\{\}\s*\)/$1/gs;#(*f{}) 
-> f
}
# pretend as we didn't use curly braces: {} -> ()


In message  
on Tue, 25 Jul 2017 15:18:35 -0400, Matthew Stickney  
said:

mtstickney> I'm away from the machine in question right now, but:
mtstickney> 
mtstickney> > Also, presumably the perl is the msys perl, but please confirm -- 
it must be "matching" in order for things to work.
mtstickney> 
mtstickney> It's definitely the msys perl. I'll check the config line tonight, 
but
mtstickney> I'm virtually certain that it was "./config" in it's entirety.
mtstickney> 
mtstickney> > Can you state what OpenSSL version this is
mtstickney> 
mtstickney> I'll get the commit hash tonight, but this was the tip of master as 
of
mtstickney> about 9pm EDT last night, so I'd imagine that util/mkdef.pl in 
master
mtstickney> still has whatever the issue is.
mtstickney> 
mtstickney> -Matt Stickney
mtstickney> 
mtstickney> On Tue, Jul 25, 2017 at 2:59 PM, Richard Levitte 
 wrote:
mtstickney> > In message

Re: [openssl-dev] Build issue

2017-07-25 Thread Matthew Stickney 
I'm away from the machine in question right now, but:

> Also, presumably the perl is the msys perl, but please confirm -- it must be 
> "matching" in order for things to work.

It's definitely the msys perl. I'll check the config line tonight, but
I'm virtually certain that it was "./config" in it's entirety.

> Can you state what OpenSSL version this is

I'll get the commit hash tonight, but this was the tip of master as of
about 9pm EDT last night, so I'd imagine that util/mkdef.pl in master
still has whatever the issue is.

-Matt Stickney

On Tue, Jul 25, 2017 at 2:59 PM, Richard Levitte  wrote:
> In message 
>

Re: [openssl-dev] Build issue

2017-07-25 Thread Richard Levitte 
In message

Re: [openssl-dev] Build issue

2017-07-25 Thread Benjamin Kaduk via openssl-dev 
On 07/25/2017 01:52 PM, Matthew Stickney wrote:
> I've been trying to build OpenSSL to work on a new feature, but I've
> had problems with the build hanging. I'm building on Windows 10 with
> mingw-w64 under msys2; perl is v5.24, and I installed the
> Text::Template module from CPAN.
>

You did not show the config line used, which is perhaps relevant.

Also, presumably the perl is the msys perl, but please confirm -- it
must be "matching" in order for things to work.

-Ben
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] build issue with openssl 1.1.0-pre5

2016-06-29 Thread Matt Caswell 


On 29/06/16 15:35, Jan Just Keijser wrote:
> hi all,
> 
> I'm the maintainer of grid-proxy-verify, a grid-tool that uses "plain"
> openssl to verify a grid proxy (either RFC3820 or legacy Globus proxy).
> This tool
>   http://www.nikhef.nl/~janjust/proxy-verify/
> and
>   http://www.nikhef.nl/~janjust/proxy-verify/grid-proxy-verify.c
> builds without any warnings with openssl 0.9.8 and 1.0.x, e.g. using
>   gcc -Wall -pedantic -c -o grid-proxy-verify.o grid-proxy-verify.c
> but with 1.1.0 I run into all sorts of issues (see the bottom of this
> email). Most of these have to do with members of structs becoming opaque
> but especially the disappearance of the check_issued callback is
> worrisome, as that callback is crucial for verifying proxy certificates.
> How should I modify my code so that it builds and links with openssl 1.1.0?

There have been lots of structures made opaque.

Where as before you might have done this:

FOO x;

FOO_init(x);

x->bar = 1;

...

FOO_cleanup(x);

Now you might have to do:

FOO *x;

x = FOO_new();
if (x == NULL)
goto err;

FOO_set_bar(x, 1);

...

FOO_free(x);


Making these changes will fix most of the "incomplete type" issues you
are seeing.

This issue:
> grid-proxy-verify.c: In function ‘grid_verifyCert’:
> openssl-1.1.0-pre5/include/openssl/x509_vfy.h:107:56: error:
> dereferencing pointer to incomplete type
>  # define X509_STORE_set_verify_cb_func(ctx,func)
((ctx)->verify_cb=(func))
> ^
> grid-proxy-verify.c:686:5: note: in expansion of macro
> ‘X509_STORE_set_verify_cb_func’
>  X509_STORE_set_verify_cb_func (store, grid_X509_verify_callback);

is actually a bug in pre5. Fixed in the latest master version.


> grid-proxy-verify.c:965:5: warning: ‘ERR_remove_state’ is deprecated
> (declared at openssl-1.1.0-pre5/include/openssl/err.h:363)
> [-Wdeprecated-declarations]
>  ERR_remove_state(0);

ERR_remove_state() was actually deprecated in OpenSSL 1.0.0. Its
successor ERR_remove_thread_state() has also now been deprecated. You
should not need to call this at all in OpenSSL 1.1.0 - it can be
removed. The library is auto-deinitialised (see
https://www.openssl.org/docs/manmaster/crypto/OPENSSL_init_crypto.html)

The "check_issued" thing looks like a possible missing accessor
function(s) (if so please raise a GitHub Issue).

Matt

> 
> 
> thx for any pointers,
> 
> JJK / Jan Just Keijser
> 
> $ gcc -I openssl-1.1.0-pre5/include -o grid-proxy-verify.o
> grid-proxy-verify.c
> grid-proxy-verify.c: In function ‘grid_X509_check_issued_wrapper’:
> grid-proxy-verify.c:337:14: error: dereferencing pointer to incomplete type
>  if (!(ctx->param->flags & X509_V_FLAG_CB_ISSUER_CHECK)) return 0;
>   ^
> grid-proxy-verify.c:341:8: error: dereferencing pointer to incomplete type
>  ctx->error = ret;
> ^
> grid-proxy-verify.c:342:8: error: dereferencing pointer to incomplete type
>  ctx->current_cert = x;
> ^
> grid-proxy-verify.c:343:8: error: dereferencing pointer to incomplete type
>  ctx->current_issuer = issuer;
> ^
> grid-proxy-verify.c:344:15: error: dereferencing pointer to incomplete type
>  return ctx->verify_cb(0, ctx);
>^
> grid-proxy-verify.c: In function ‘grid_verifyProxy’:
> grid-proxy-verify.c:529:25: error: dereferencing pointer to incomplete type
>  if (pkey->type == EVP_PKEY_RSA)
>  ^
> grid-proxy-verify.c:531:56: error: dereferencing pointer to incomplete type
>  int key_strength = BN_num_bits(pkey->pkey.rsa->n);
> ^
> grid-proxy-verify.c: In function ‘grid_X509_verify_callback’:
> grid-proxy-verify.c:593:16: error: dereferencing pointer to incomplete type
>  ctx->error = errnum;
> ^
> grid-proxy-verify.c:620:21: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
>  certstack = (STACK_OF(X509) *) X509_STORE_CTX_get_chain( ctx );
>  ^
> grid-proxy-verify.c:627:12: error: dereferencing pointer to incomplete type
>  ctx->error = errnum;
> ^
> In file included from openssl-1.1.0-pre5/include/openssl/x509.h:363:0,
>  from grid-proxy-verify.c:38:
> grid-proxy-verify.c: In function ‘grid_verifyCert’:
> openssl-1.1.0-pre5/include/openssl/x509_vfy.h:107:56: error:
> dereferencing pointer to incomplete type
>  # define X509_STORE_set_verify_cb_func(ctx,func) ((ctx)->verify_cb=(func))
> ^
> grid-proxy-verify.c:686:5: note: in expansion of macro
> ‘X509_STORE_set_verify_cb_func’
>  X509_STORE_set_verify_cb_func (store, grid_X509_verify_callback);
>  ^
> grid-proxy-verify.c:720:10: error: dereferencing pointer to incomplete type
>  store->check_issued = grid_X509_check_issued_wrapper;
>