Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perl-5.8.8 - AIX 5.3 64bit build issues #8943

Closed
p5pRT opened this issue Jun 22, 2007 · 7 comments
Closed

perl-5.8.8 - AIX 5.3 64bit build issues #8943

p5pRT opened this issue Jun 22, 2007 · 7 comments

Comments

@p5pRT
Copy link

p5pRT commented Jun 22, 2007

Migrated from rt.perl.org#43291 (status was 'resolved')

Searchable as RT43291$

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2007

From nikke@acc.umu.se

Hi!

perl-5.8.8 does not build out of the box when compiling in 64bit mode
on the latest AIX 5.3 stable technology level with the latest compiler
version due to passing compiler options to the linker.

OS​: AIX 5.3 5300-05-CSP
Compiler​: vac.C 8.0.0.14 (latest version with latest patches).

When digging into this I noticed the following issues related to
linker flags when compiling on AIX​:

- The build system passes compiler flags to the linker. The linker in
  current AIX versions returns an error and aborts when encountering
  them.
- The build system includes -bmaxdata​:0x80000000 to increase the heap
  data area to 2GB (from the default 256MB in 32bit mode) when using
  native dlopen. This has the effect of reducing the heap area when
  doing 64bit builds.

The attached patch is how we solved the problem​:
- Don't pass compiler flags to the linker.
- Hard-code cc to cc in 32 or 64bit mode to obtain the effect that
  passing compiler flags to the linker was trying to achieve.
- Only pass -bmaxdata when doing 32bit builds, but do it for all
  those builds and not only when using native dlopen.

However, I'm not fully satisfied with this solution for the following
reasons​:
- Makefile.SH separates LDFLAGS (for use by LD) and CLDFLAGS (for use
  by CC). However, both are set to $ldflags. If the build system knew
  about the difference the fix would be far more elegant and
  appropriate.
- Modern versions of the AIX compiler understands -Wl,linkerflag so
  there is really no need to not use that notation everywhere.
- I'm not really clued on when and how the different callbacks are
  used, so I might have gotten the usage of them wrong. For example, I
  have the feeling that in my patch maxdata etc will only be set when
  uselargefiles is enabled.

I would really prefer a solution where all linker/compiler flags was
dealt with first in a common way, and then doing the gcc/xlc specific
stuff last. Right now it's rather messy.

Also, the current build process results in a perl binary with library
search path to the build directory. This is rather annoying, and the
only way to solve it seems to be to manually relink the perl binary
when installing it. I would really prefer to having the perl binary
build with the real libpath and having a wrapper script a la libtool
that solves the runtime library issues when doing tests on it before
installation.

/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @​ {acc,hpc2n}.umu.se | nikke@​acc.umu.se


  That's a weird place for a horn. Oh, that's not a horn. - Dawn
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2007

From nikke@acc.umu.se

perl-588-aix64bitlink.patch
--- ../dist/hints/aix.sh	2005-07-26 15:46:55.000000000 +0200
+++ hints/aix.sh	2007-06-21 14:05:54.000000000 +0200
@@ -309,8 +309,37 @@
 		;;
 	    esac
 
+	# -bmaxdata:0x80000000  
+	# - This increases the size of heap memory available to perl.
+	#   Default is 256 MB, which sounds large but caused a software
+	#   vendor problems. So this sets heap to 2 GB maximum. Anything
+	#   higher and you'd want to consider 64 bit perl.
+	# - NOTE however, that setting this in 64bit mode will limit your
+	#   amount of available memory to 2GB, so we set this only in
+	#   32bit mode to avoid future problems a la "should be enough
+	#   for everyone" ...
+	#
+	case "$use64bitall" in
+	    $define|true|[yY]*)
+		:
+		;;
+	    *)
+	    	ldflags="$ldflags -bmaxdata:0x80000000"	
+		;;
+	    esac
+
 	case "$gccversion" in
-	    '') ;;
+	    '') 
+		# Not using gcc.
+	    	# Due to calling $cc without $cflags when linking some
+		# binaries we need to hardwire $cc to the right mode.
+		# The correct fix would be to have Makefile.SH not set
+		# CLDFLAGS from $ldflags ...
+		case "$use64bitall" in
+		    $define|true|[yY]*) cc="$cc -q64"	;;
+		    *)			cc="$cc -q32"	;;
+		    esac
+		;;
 	    *)  # Remove xlc-specific -qflags.
 		ccflags="`echo $ccflags | sed -e 's@ -q[^ ]*@ @g' -e 's@^-q[^ ]* @@g'`"
 		ldflags="`echo $ldflags | sed -e 's@ -q[^ ]*@ @g' -e 's@^-q[^ ]* @@g'`"
@@ -319,9 +348,18 @@
 		ldflags="`echo ' '$ldflags | sed -e 's@ -b@ -Wl,-b@g'`"
 		lddlflags="`echo ' '$lddlflags | sed -e 's@ -b@ -Wl,-b@g'`"
 		lddlflags="`echo ' '$lddlflags | sed -e 's@ -G @ -Wl,-G @g'`"
+
+	    	# Due to calling $cc without $cflags when linking some
+		# binaries we need to hardwire $cc to the right mode.
 		case "$use64bitall" in
-		    $define|true|[yY]*) ld="$cc -maix64"	;;
-		    *)			ld="$cc"		;;
+		    $define|true|[yY]*) 
+			cc="$cc -maix64"
+			ld="$cc"
+			;;
+		    *)
+			cc="$cc -maix32"
+			ld="$cc"
+			;;
 		    esac
 		echo >&4 "(using ccflags   $ccflags)"
 		echo >&4 "(using ldflags   $ldflags)"
@@ -401,13 +439,10 @@
 	trylist="`echo $trylist | sed -e 's@^ar @@' -e 's@ ar @ @g' -e 's@ ar$@@'`"
 	ar="ar -X64"
 	nm_opt="-X64 $nm_opt"
-	# Note: Placing the 'qacflags' variable into the 'ldflags' string
-	# is NOT a typo.  ldflags is passed to the C compiler for final
-	# linking, and it wants -q64 (-b64 is for ld only!).
 	case "$qacflags$qaldflags$qalibs" in
 	    '') ;;
 	    *)  ccflags="$ccflags $qacflags"
-		ldflags="$ldflags $qacflags"
+		ldflags="$ldflags"
 		lddlflags="$qaldflags $lddlflags"
 		libswanted="$libswanted $qalibs"
 		;;
@@ -435,14 +470,9 @@
     #			    ".so"-suffix libraries as well as ".a" suffix
     #			    libraries. AIX allows both .so and .a libraries to
     #			    contain dynamic shared objects.
-    # -bmaxdata:0x80000000  This increases the size of heap memory available
-    #			    to perl. Default is 256 MB, which sounds large but
-    #			    caused a software vendor problems. So this sets
-    #			    heap to 2 GB maximum. Anything higher and you'd
-    #			    want to consider 64 bit perl.
     case "$cc" in
-	*gcc*) ldflags="$ldflags -Wl,-brtl -Wl,-bdynamic -Wl,-bmaxdata:0x80000000" ;;
-	*)     ldflags="$ldflags -brtl -bdynamic -bmaxdata:0x80000000" ;;
+	*gcc*) ldflags="$ldflags -Wl,-brtl -Wl,-bdynamic" ;;
+	*)     ldflags="$ldflags -brtl -bdynamic" ;;
 	esac
 elif test -f /lib/libC.a -a X"`$cc -v 2>&1 | grep gcc`" = X; then
     # If the C++ libraries, libC and libC_r, are available we will

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2007

From @Tux

On Fri, 22 Jun 2007 00​:30​:36 -0700, Niklas Edmundsson (via RT)
<perlbug-followup@​perl.org> wrote​:

Hi!

perl-5.8.8 does not build out of the box when compiling in 64bit mode
on the latest AIX 5.3 stable technology level with the latest compiler
version due to passing compiler options to the linker.

OS​: AIX 5.3 5300-05-CSP
Compiler​: vac.C 8.0.0.14 (latest version with latest patches).

When digging into this I noticed the following issues related to
linker flags when compiling on AIX​:

- The build system passes compiler flags to the linker. The linker in
current AIX versions returns an error and aborts when encountering
them.
- The build system includes -bmaxdata​:0x80000000 to increase the heap
data area to 2GB (from the default 256MB in 32bit mode) when using
native dlopen. This has the effect of reducing the heap area when
doing 64bit builds.

Thanks for both analysis, clear comments, and patches.

The attached patch is how we solved the problem​:
- Don't pass compiler flags to the linker.

Does this work in all combinations? xlc/vac vs GNU gcc and ld vs gld?

- Hard-code cc to cc in 32 or 64bit mode to obtain the effect that
passing compiler flags to the linker was trying to achieve.

I'm not familiar with AIX 5.3, but I would assume that setting $OBJECT_MODE
to 32 or 64 would be a more generic solution when building perl, but I do
understand that this would not promote to %Config, and will thus not be
seen or used with external XS modules.

- Only pass -bmaxdata when doing 32bit builds, but do it for all
those builds and not only when using native dlopen.

Good.

However, I'm not fully satisfied with this solution for the following
reasons​:
- Makefile.SH separates LDFLAGS (for use by LD) and CLDFLAGS (for use
by CC). However, both are set to $ldflags. If the build system knew
about the difference the fix would be far more elegant and
appropriate.
- Modern versions of the AIX compiler understands -Wl,linkerflag so
there is really no need to not use that notation everywhere.

Older versions do not? FWIW, aix-4 and aix-3 have their own hint files,
so changing aix.sh wont hurt those older machines (that are likely to
have the older compilers)

- I'm not really clued on when and how the different callbacks are
used, so I might have gotten the usage of them wrong. For example, I
have the feeling that in my patch maxdata etc will only be set when
uselargefiles is enabled.

I would really prefer a solution where all linker/compiler flags was
dealt with first in a common way, and then doing the gcc/xlc specific
stuff last. Right now it's rather messy.

It is. Main problem is the detection of multiple C compilers, and
dealing with them properly. We have had a case that someone had both
AIX compilers (C and C++) and the full suite from GNU, and the build
process went completely bezerque.

Also, the current build process results in a perl binary with library
search path to the build directory. This is rather annoying, and the
only way to solve it seems to be to manually relink the perl binary
when installing it. I would really prefer to having the perl binary
build with the real libpath and having a wrapper script a la libtool
that solves the runtime library issues when doing tests on it before
installation.

Don't know about that.

FWIW I have been maintaining aix.sh for the last years, and that is not
because I like doing it. I really hate AIX, so if you have the guts and
the tuits to revise aix.sh and README.aix, please step forward. We like
to have someone in our mids with both knowledge and affection for AIX.

/Nikke

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and Cygwin. http​://qa.perl.org
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org
  http​://www.goldmark.org/jeff/stupid-disclaimers/

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2007

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2007

From @Tux

Applied in change #31445
Bug closed.

@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2007

@Tux - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Jun 22, 2007
@p5pRT
Copy link
Author

p5pRT commented Jun 22, 2007

From @Tux

On Fri, 22 Jun 2007 00​:30​:36 -0700, Niklas Edmundsson (via RT)
<perlbug-followup@​perl.org> wrote​:

perl-5.8.8 does not build out of the box when compiling in 64bit mode
on the latest AIX 5.3 stable technology level with the latest compiler
version due to passing compiler options to the linker.

Patch applied (I removed some trailing whitespace)

OS​: AIX 5.3 5300-05-CSP
Compiler​: vac.C 8.0.0.14 (latest version with latest patches).

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and Cygwin. http​://qa.perl.org
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org
  http​://www.goldmark.org/jeff/stupid-disclaimers/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant