[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171129213555.Horde.uLLr0y8vzhLaKXHy1bF7qph@webmail.your-server.de>
Date: Wed, 29 Nov 2017 21:35:55 +0100
From: altr@...2.de
To: john-dev@...ts.openwall.com
Subject: Re: aix 5 compilation
Zitat von Solar Designer <solar@...nwall.com>:
> On Tue, Nov 28, 2017 at 11:02:22PM +0100, altr@...2.de wrote:
>> by compiling jtr on an old AIX 5.3 machine (sigh, for compat reasons, ...):
>>
>> 1) there is a conflict for int64, renamed it to jtrint64.
> So it turns out these are insufficient, because AIX header files that we
> sometimes (indirectly) include (at least in jumbo) after having already
> included our math.h try to refer to AIX's own int64, but instead hit our
> workaround macro.
>
> I'll need to fix this in the core tree to avoid unnecessary differences
> between it and jumbo.
I see, thank you.
>> 3) arg list in the binary linking step was too long -> created a file
>> "jtr_link" with the command and bashed it
>
> Previously discussed in:
>
> https://github.com/magnumripper/JohnTheRipper/issues/2150
>
> Maybe we need to enhance jumbo to exclude opencl_*.o from linking when
> we're making non-OpenCL builds. magnum?
>
> Also, we may want to document use of AIX's chdev command:
>
> http://www.in-ulm.de/~mascheck/various/argmax/
>
> "The limit on AIX 5.1 can be changed at run time with "chdev -l sys0 -a
> ncargs=value", in the range from 6_4KB to 1024_4KB."
>
> And I don't see how people are bumping into the 24 KB default already.
> This default is not that low. Can you find out? Do you already have so
> many env vars set or whatever? Try something like "set | wc" in bash.
$ getconf ARG_MAX
24576
$ set | wc
2763 7039 69898
surprisingly sourcing the shell script worked, i wrote the script via
"make -n | head 10" and vim, of course. ;)
>> 4) no clue
>
>> In file included from SIPdump.c:51:
>> tcphdr.h:20: error: expected ':', ',', ';', '}' or '__attribute__'
>> before '.' token
>
> Previously discussed in:
>
> https://github.com/magnumripper/JohnTheRipper/issues/2153
>
> Apparently, libpcap upgrade helps.
I have to try that.
> Our tcphdr.h:20 is:
>
> uint8_t th_off:4;
>
> I am puzzled as to why this fails to compile, why line 21 apparently
> compiles (it's very similar, so maybe the issue is th_off specifically
> is already defined?), and and why upgrading libpcap would make a
> difference with respect to this error (does it possibly define TCPHDR_H
> on its own, which results in our tcphdr.h's content skipped?)
I could neither find that file nor define.
>> $ git log | head
>> commit 1b73c7339f385946e287696510909bd6f7950ce8
>> Author: jfoug <jfoug@...nwall.net>
>> Date: Tue Nov 28 11:49:41 2017 -0600
>> $ git diff > jtr.diff
>>
>> ... appended, is there a better way to do this? (git send-email ?)
>
> As you already found out, we use GitHub pull requests. Thank you for
> making one:
>
> https://github.com/magnumripper/JohnTheRipper/pull/2935
I am very new to that. It would be nice to hear how it works.
I am compiling john for AIX 5.3/6.1/7.1, HP-UX 11.11/11.31, linux
32bit 64bit, Solaris 5.10/5.11 (64 Bit) , Solaris Sparc 5.8 (32 Bit) /
5.9 (64 Bit) / 5.11 (64 Bit). There are a bunch of issues in the code,
how do you suggest to keep the issues independant? (accept one, reject
others ...)
If one issue is badly solved, it should be independant from the other
ones (to reject it) - so doing a single pull request seems a little
bit clumsy to do that.
But I am new to github so any help or comments are welcome. ;)
> Please exclude the int64 rename from there: that issue should be dealt
> with separately.
Yes, that's my question. I did three commits for three different
things and did one pull request - would it have been better to do
three pull requests?
> The unshadow.c changes, if needed, I should probably make in the core
> tree as well, and mine won't be exactly the same as yours. But I don't
> mind having this in jumbo as you wrote first.
Mine was a solution that solved a problem (for me). My idea was to
share it with you to have the problem saved for future releases.
Feel free to use or change it.
Regards,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
