Re: haproxy AIX 7.1.0.0 compile issues

2018-12-27 Thread Willy Tarreau
On Thu, Dec 27, 2018 at 02:51:35PM +, Overbey, Patrick (Sioux Falls) wrote:
> Hi Willy,
> Thanks for your prompt response. I appreciate your help with this matter.
> 
> Here is the ld version on my AIX system. 
> ld: LD 1.65.6.6 (4/1/14)
> 
> I tried changing the linker in the Makefile from gcc to ld, but ran into
> similar undefined symbol errors. I installed binutils which includes gld
> version 2.29.1, but ran into many undefined reference errors (attached). 

OK. By the way, I'm totally shocked by the amount of warnings you're getting
after we've managed to be able to build with -Werror on most platforms!
Anyway, I think we cannot swap gcc to ld this way but you should be able to
pass this to your LDFLAGS instead to let gcc rely on gld (and then don't set
LD). However I can't figure in gcc's man howe to do this. The following will
indicate what LD gcc uses :

gcc -print-prog-name=ld

I've found that you can set the linker to be bfd-compatible using -fuse-ld=bfd
or gold-compatible by specifying -fuse-ld=gold. In this case gcc will use a
different linker name. E.g. :

  willy@wtap:haproxy$ gcc -print-prog-name=ld 
  ld
  willy@wtap:haproxy$ gcc -print-prog-name=ld -fuse-ld=gold
  ld.gold
  willy@wtap:haproxy$ gcc -print-prog-name=ld -fuse-ld=bfd 
  ld.bfd

So if gld is also accessible as ld.bfd or ld.gold, you have an option here to
make it work, e.g. :

LDFLAGS="-fuse-ld=gold"

Otherwise it's possible to enforce the search path for the subprograms
using -B or using the GCC_EXEC_PREFIX environment variable. If your linker
is installed next to gcc that might work, but I suspect it could also cause
more headache than it fixes, thus you'll need to have a look at the man page
to experiment.

Willy



RE: haproxy AIX 7.1.0.0 compile issues

2018-12-27 Thread Overbey, Patrick (Sioux Falls)
Hi Willy,
Thanks for your prompt response. I appreciate your help with this matter.

Here is the ld version on my AIX system. 
ld: LD 1.65.6.6 (4/1/14)

I tried changing the linker in the Makefile from gcc to ld, but ran into 
similar undefined symbol errors. I installed binutils which includes gld 
version 2.29.1, but ran into many undefined reference errors (attached). 

Thank you!

Patrick Overbey
Fiserv


-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu] 
Sent: Thursday, December 27, 2018 8:17 AM
To: Overbey, Patrick (Sioux Falls) 
Cc: Aleksandar Lazic ; haproxy@formilux.org
Subject: Re: haproxy AIX 7.1.0.0 compile issues

Hi Patrick,

On Thu, Dec 27, 2018 at 01:37:15PM +, Overbey, Patrick (Sioux Falls) wrote:
> I have attached connection.c and vars.c (aixchg.tar.bz2) which had to 
> have changes to (ip_v and var) variable assignments to compile version 1.8.
> 
> I have also attached a build log (haproxy-make.zip) for version 1.9 
> when the build failed which has the same code changes to connection.c and 
> vars.c.

Thanks for your report. That's really sad that it broke, to say the least :-(

The problem that the change addressed was that we were dealing with init 
ordering dependencies that really required to do something finer than what we 
had till now. Certain things couldn't be pre-initialized (e.g. thread-local 
variables), resulting in the need to run through complex fixing operations when 
switching to multi-thread.

What you report indicates that your linker doesn't seem to create the start and 
end of section automatic symbols that we are relying on. 
Could you please send the output of "ld --version" ? I suspect it's not a 
binutils-compatible linker but there might be some options to make it become 
more compatible and/or to emit these symbols.

Alternatively maybe you have another linker available on the system.
Please check if you have something called "gld", "gcc-ld" or so, I wouldn't be 
surprised.

> When I attempt to add the -bnoquiet to the LDFLAGS, I get an error 
> that it is an unrecognized command line option. Here is the command I 
> used that included the -bnoquiet.
> 
> /usr/local/gnu-2018/bin/gmake -B CFLAGS="-maix64" LDFLAGS="-maix64 -bnoquiet"
> TARGET=aix52 USE_OPENSSL=1 SSL_INC=/opt/freeware/include/openssl
> SSL_LIB=/opt/freeware/lib USE_ZLIB=1 2>&1 | tee haproxy-make.log
> 
> gcc: error: unrecognized command line option '-bnoquiet'; did you mean 
> '-quiet'?

Regarding this one I'm less worried. We default to LD=$(CC) so by just setting 
"LD=ld" or wherever your ld is located, it should more or less be OK.

At the moment I'd really like to see how to make your linker generate the 
initcall symbols.

Regards,
Willy


haproxy-gld.log.bz2
Description: haproxy-gld.log.bz2


Re: haproxy AIX 7.1.0.0 compile issues

2018-12-27 Thread Willy Tarreau
Hi Patrick,

On Thu, Dec 27, 2018 at 01:37:15PM +, Overbey, Patrick (Sioux Falls) wrote:
> I have attached connection.c and vars.c (aixchg.tar.bz2) which had to have
> changes to (ip_v and var) variable assignments to compile version 1.8. 
> 
> I have also attached a build log (haproxy-make.zip) for version 1.9 when the
> build failed which has the same code changes to connection.c and vars.c. 

Thanks for your report. That's really sad that it broke, to say the least :-(

The problem that the change addressed was that we were dealing with
init ordering dependencies that really required to do something finer
than what we had till now. Certain things couldn't be pre-initialized
(e.g. thread-local variables), resulting in the need to run through
complex fixing operations when switching to multi-thread.

What you report indicates that your linker doesn't seem to create the
start and end of section automatic symbols that we are relying on. 
Could you please send the output of "ld --version" ? I suspect it's
not a binutils-compatible linker but there might be some options to
make it become more compatible and/or to emit these symbols.

Alternatively maybe you have another linker available on the system.
Please check if you have something called "gld", "gcc-ld" or so, I
wouldn't be surprised.

> When I attempt to add the -bnoquiet to the LDFLAGS, I get an error that it is
> an unrecognized command line option. Here is the command I used that included
> the -bnoquiet. 
> 
> /usr/local/gnu-2018/bin/gmake -B CFLAGS="-maix64" LDFLAGS="-maix64 -bnoquiet"
> TARGET=aix52 USE_OPENSSL=1 SSL_INC=/opt/freeware/include/openssl
> SSL_LIB=/opt/freeware/lib USE_ZLIB=1 2>&1 | tee haproxy-make.log
> 
> gcc: error: unrecognized command line option '-bnoquiet'; did you mean
> '-quiet'?

Regarding this one I'm less worried. We default to LD=$(CC) so by just
setting "LD=ld" or wherever your ld is located, it should more or less
be OK.

At the moment I'd really like to see how to make your linker generate
the initcall symbols.

Regards,
Willy



Re: haproxy AIX 7.1.0.0 compile issues

2018-12-26 Thread Aleksandar Lazic

Hi Patrick.

Am 26-12-2018 22:26, schrieb Overbey, Patrick (Sioux Falls):


Hello,

First off, I want to say thank you for your hard work on haproxy. It is 
a very fine piece of software.
I recently ran into a bug compiling haproxy 1.9+ on AIX 7.1 
7100-00-03-1115 using gmake 4.2 and gcc 8.1.0. I had previously had 1.8 
compiling using this same setup with a few minor code changes to 
variable names in vars.c and connection.c. I made those same changes in 
version 1.9, but have now ran into a compile issue that I cannot get 
around due to initcall.h being new in 1.9.


Please can you tell us which `minor code changes` was necessary to be 
able to compile on AIX 7.1.



Here are the compile errors I am seeing.

ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more 
information.


What do you get when you add `-bnoquiet` to the LDFLAGS?
Please can you share the compile output with `V=1`  activated.


ld: 0711-317 ERROR: Undefined symbol: __start_init_STG_PREPARE

ld: 0711-317 ERROR: Undefined symbol: __stop_init_STG_PREPARE

ld: 0711-317 ERROR: Undefined symbol: __start_init_STG_LOCK

ld: 0711-317 ERROR: Undefined symbol: __stop_init_STG_LOCK

ld: 0711-317 ERROR: Undefined symbol: __start_init_STG_ALLOC

ld: 0711-317 ERROR: Undefined symbol: __stop_init_STG_ALLOC

ld: 0711-317 ERROR: Undefined symbol: __start_init_STG_POOL

ld: 0711-317 ERROR: Undefined symbol: __stop_init_STG_POOL

ld: 0711-317 ERROR: Undefined symbol: __start_init_STG_REGISTER

ld: 0711-317 ERROR: Undefined symbol: __stop_init_STG_REGISTER

ld: 0711-317 ERROR: Undefined symbol: __start_init_STG_INIT

ld: 0711-317 ERROR: Undefined symbol: __stop_init_STG_INIT

Would anyone have suggestions for how to fix this?

Also, as a note I am able to compile haproxy 1.5 out of the box, but 
starting with version 1.6 is where I run into compile errors. Is there 
support for these compile bugs or am I on my own?


Please can you be more precise which compile errors you got, thanks.


Thanks for any help you can offer.

PATRICK OVERBEY

Software Development Engineer Staff

Product Development/Bank Solutions

Office: 605-362-1260  x7290

FISERV
JOIN US @ FORUM 2019
Fiserv | Join Our Team | Twitter | LinkedIn | Facebook
FORTUNE Magazine WORLD'S MOST ADMIRED COMPANIES® 2014 | 2015 | 2016 | 
2017 | 2018
(c) 2018 Fiserv Inc. or its affiliates. Fiserv is a registered 
trademark of Fiserv Inc. Privacy Policy