From wesun@cisco.com

Created by wesun@cisco.com

When using HP ANIS C compiler on a HPUX 11.x server, the "configure" generates LDFLAGS by copying CCFLAGS. As a result, when enabling "use64bitall", the compiler only flag "+DD64" is leaked into LDFLAGS. This is not causing problem for perl compiling itself as the current makefile rulex do not use HP linker "ld" to link the binary. Instead, perl use cc and CFLAGS for linking and cc does accept "+DD64" though "cc" just filter it out before passing the rest of linking flags onto the linker.

However, with this setup, some of the modules (e.g., DBD-Oracle) is taking LDFLAGS from perl config for linking with HP linker "ld", which will reject "+DD64" flag and fail "make".

  oxen_wesun_1​: ld +DD64
  ld​: Unrecognized argument​: +DD64

Flags:
    category=install
    severity=low

Site configuration information for perl v5.8.5:

Configured by wesun at Mon Jul 26 00:10:36 EDT 2004.

Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
  Platform:
    osname=hpux, osvers=11.23, archname=IA64.ARCHREV_0-LP64
    uname='hp-ux goofy b.11.23 u ia64 2820982338 unlimited-user license '
    config_args='-des -Ulocincpth= -Uloclibpth= -Duse64bitall -Dprefix=/usr/local/perl5.8.5 -Duselargefiles -Dmake=gmake -Uinstallusrbinperl -Dlibs=-lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=define uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags =' -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ',
    optimize='+O2 +Onolimit',
    cppflags='-Aa -D__STDC_EXT__ -D_HPUX_SOURCE -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings'
    ccversion='B3910B A.05.55', gccversion='', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='/usr/bin/ld', ldflags =' +DD64 -L/usr/lib/hpux64'
    libpth=/usr/lib/hpux64 /lib /usr/lib /usr/ccs/lib /usr/local/lib
    libs=-lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc 
    perllibs=-lnsl -lnm -ldl -ldld -lm -lsec -lpthread -lc
    libc=/usr/lib/hpux64/libc.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_hpux.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred '
    cccdlflags='+Z', lddlflags='-b +vnocompatwarnings -L/usr/lib/hpux64'

Locally applied patches:
    


@INC for perl v5.8.5:
    /usr/local/perl5.8.5/lib/5.8.5/IA64.ARCHREV_0-LP64
    /usr/local/perl5.8.5/lib/5.8.5
    /usr/local/perl5.8.5/lib/site_perl/5.8.5/IA64.ARCHREV_0-LP64
    /usr/local/perl5.8.5/lib/site_perl/5.8.5
    /usr/local/perl5.8.5/lib/site_perl
    .


Environment for perl v5.8.5:
    HOME=/users/wesun
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/opt/emc/ECC/bin:/usr/symcli/bin:/sbin:/usr/sbin:/etc:/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/contrib/bin/X11:/usr/local/sbin:/usr/local/bin:/opt/ansic/bin:/opt/imake/bin:/opt/langtools/bin:/opt/perf/bin:/opt/samba/bin:/users/wesun/bin:/users/wesun/bin/script:.
    PERL_BADLANG (unset)
    SHELL=/bin/ksh

From @Tux

Was resolved by clearing out the source tree directory before restarting

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

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

From @Tux

I resolved the wrong one sorry :(

From wesun@cisco.com

Hi, Merijn,

I looked over both "hints/hpux.sh" and "Makefile.SH", there might not be
an easy fix for this because of the following general logic in Makefile.SH
across all platforms,

  LDFLAGS = $ldflags
  CLDFLAGS = $ldflags

If "+DD64" is taken out of ldflags from hpux.sh, CLDFLAGS in Makefile.SH
won't get the 64-bit capacity.

I am attempting to file a bug with HP on the linker to ask ld accept
"+DD64" flag (even not doing anything). But I can't come up with a
reasonable strong argument on this (ie, ld should accept all the cc
flags). Maybe the fact that all the other platforms behave in this fashion
is enough (or is that really a fact on solaris/digital/aix
linker/compilers) ?

--weiguo

On 7 Aug 2004, H. Merijn Brand via RT wrote​:

According to our records, your request regarding
"wrong LDFLAGS from configure when use HP ANSIC with 64 bit enabled"
has been resolved.

If you have any further questions or concerns, please respond to this message.

For other topics, please create a new ticket.

Please don't feel obligated to say "Thanks" or "Kudos" or "I owe you a beer" -- if you respond to this message it will reopen the ticket. If you must, please send email directly to the person who handled your ticket, and not to the tracking system.

<URL​: http​://rt.perl.org​:80/rt3/Ticket/Display.html?id=30971 >

From @Tux

On Sun 08 Aug 2004 20​:59, Weiguo Sun <wesun@​cisco.com> wrote​:

Hi, Merijn,

I looked over both "hints/hpux.sh" and "Makefile.SH", there might not be
an easy fix for this because of the following general logic in Makefile.SH
across all platforms,

LDFLAGS = $ldflags
CLDFLAGS = $ldflags

If "+DD64" is taken out of ldflags from hpux.sh, CLDFLAGS in Makefile.SH
won't get the 64-bit capacity.

I think inm fact this would better be +DA2.0w

I am attempting to file a bug with HP on the linker to ask ld accept
"+DD64" flag (even not doing anything).

Good idea! :)

But I can't come up with a
reasonable strong argument on this (ie, ld should accept all the cc
flags). Maybe the fact that all the other platforms behave in this fashion
is enough (or is that really a fact on solaris/digital/aix
linker/compilers) ?

The major problem still is a not-so-perfect DBD-Oracle environment to set up
the Makefile.
I am about to set up a 11i/64 Oracle environment in 2 weeks, so I will hit the
same trouble and feedback any patches to Tim

--weiguo

On 7 Aug 2004, H. Merijn Brand via RT wrote​:

According to our records, your request regarding
"wrong LDFLAGS from configure when use HP ANSIC with 64 bit enabled"
has been resolved.

If you have any further questions or concerns, please respond to this message.

For other topics, please create a new ticket.

Please don't feel obligated to say "Thanks" or "Kudos" or "I owe you a beer" -- if you respond to this message it will reopen the ticket. If you must, please send email directly to the person who handled your ticket, and not to the tracking system.

<URL​: http​://rt.perl.org​:80/rt3/Ticket/Display.html?id=30971 >

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i,
  AIX 4.3, SuSE 9.0, and Win2k. http​://www.cmve.net/~merijn/
http​://archives.develooper.com/daily-build@​perl.org/ perl-qa@​perl.org
send smoke reports to​: smokers-reports@​perl.org, QA​: http​://qa.perl.org

From @Tux

Since the last update on this bug, work has been done on all ends in the
toolchain, and DBD​::Oracle should build out of the box for all HP-UX
configurations.

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