Hi Илья,
I agree! I just made a new patch which adds the missing documentation
for the new build-TARGET as well as the two new CPU-types.
thanks,
Chris
On Tue, Feb 11, 2020 at 8:29 PM Илья Шипицин wrote:
>
> there's AIX related build guide
>
> https://github.com/haproxy/haproxy/blob/master/INSTALL#L512-L517
>
> maybe it should be updated as well
>
> пн, 10 февр. 2020 г. в 16:45, Chris :
>>
>> Hi Willy,
>>
>> thanks a lot for your input and sorry for the delay. Work is pretty
>> rough right now...
>>
>> > Thank you for doing this work. I'm having a few questions below.
>> Sure, I am glad I can help :).
>>
>> > > +# AIX 7.2 and above
>> > > +ifeq ($(TARGET),aix72-gcc)
>> > > + set_target_defaults = $(call default_opts, \
>> > > +USE_POLL USE_THREAD USE_LIBCRYPT USE_OBSOLETE_LINKER
>> > > USE_GETADDRINFO USE_TFO)
>> >
>> > Are you really really sure about USE_TFO ? I suspect you might have
>> > accidently borrowed it from another line. It stands for TCP FastOpen
>> > and is really not broadly deployed, I was only aware of Linux and
>> > FreeBSD, but there are likely a few other ones. And the fact that it
>> > looks OK is possibly just that it's causing a different TCP socket
>> > option to be set on the connection, so if you're not certain we'd
>> > rather avoid it.
>> I think you are right. I kept USE_TFO in there because it neither
>> introduced any build-issues nor did it cause any runtime issues.
>> However, it probably does nothing and should be removed as long as we
>> are not certain it is actually beneficial. I will have a look at the
>> corresponding AIX internals later at some point.
>>
>> > > src/hlua.c: In function 'hlua_panic_ljmp':
>> > > src/hlua.c:128:1: warning: no return statement in function returning
>> > > non-void [-Wreturn-type]
>> > > static int hlua_panic_ljmp(lua_State *L) { longjmp(safe_ljmp_env, 1); }
>> > > ^~
>> >
>> > Don't worry about this one, I'll handle it. I suspect that on linux
>> > platforms the longjmp() function prototype is decorated with
>> > __attribute__((noreturn)) which makes the compiler happy, but that's
>> > likely not the case on any system not relying on a gcc-compatible
>> > compiler by default.
>> Thanks for handling this one. If there is something I shoult test
>> please let me know.
>>
>> > Just two small extra requests :
>> > - please rebase it on top of the development branch. If you really
>> > need it in 2.1, just indicate it. Given that it's well isolated,
>> > I'm fine with having it backported.
>> >
>> > - please have a look at CONTRIBUTING to get guidance to write a
>> > subject and a commit message. It doesn't need to be very long
>> > but at least indicating what options you chosed to enable/disable
>> > and on what system you tested it will be enough if we need to
>> > reconsider parts of it later.
>> I already made a new patch based on the current development-HEAD and
>> tried to follow all the guidelines from CONTRIBUTING. I would love to
>> have it backported to 2.1 as the patch is pretty much identical and
>> should not cause any regressions. The patch will follow shortly!
>>
>> > Do you have a permanent and durable access to this machine, with the
>> > ability to occasionally re-run a build test in case we ask you (likely
>> > no more than 2-3 times a year in the worst case) ? I'm asking because
>> > I'm still keeping a very old IBM server running 5.2 on a Power3 just
>> > for the sake of revalidating new releases once in a while. Given that
>> > I could not upgrade it to latest OpenSSL, it cannot even be used to
>> > provide complete binaries to those needing them, so it's getting very
>> > obsolete and knowing that there's a better solution somewhere would
>> > allow me to get rid of it.
>> Well, I am not the primary administrator of this machine. However, I
>> have permanent access and no problem doing the occasional build on it.
>> I will have a chat with the server admin in regards to the longtime
>> prospects of this server and report back to you.
>>
>> > thanks!
>> > Willy
>> You are welcome - I am happy I can contribute!
>>
>> thanks,
>> Christian
>>
>> On Thu, Feb 6, 2020 at 3:36 PM Willy Tarreau wrote:
>> >
>> > Hello Christian,
>> >
>> > On Mon, Feb 03, 2020 at 12:09:46PM +0100, Chris wrote:
>> > > Hello everybody,
>> > >
>> > > I spent some time making haproxy compile and run successfully on AIX
>> > > 7.2 using GCC 8.3 and wanted to contribute my patch in the hope that
>> > > it could be merged. The patch is based on the current haproxy 2.1 head
>> > > revision. I can make one for the development branch too - but it
>> > > should be basically identical.
>> >
>> > Thank you for doing this work. I'm having a few questions below.
>> >
>> > > +# AIX 7.2 and above
>> > > +ifeq ($(TARGET),aix72-gcc)
>> > > + set_target_defaults = $(call default_opts, \
>> > > +USE_POLL USE_THREAD USE_LIBCRYPT USE_OBSOLETE_LINKER
>> > > USE_GETADDRINFO USE_TFO)
>> >
>> > Are you really really sure
