Re: [openssl-dev] Build issue

[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

[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

[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>