Error Building NSIS on HP-UX

60 posts

deckriderApril 24, 2007 at 6:26 PM#

Thanks for the reply. Here are some thoughts, let me know what you think.

Originally posted by kichik
It's definitly a problem with SCons as it doesn't properly find aCC when it's actually there. But the temporary fix should work. However, it should check for the necessity of the change.
if 'gcc' in defenv['TOOLS']:

  defenv['CC'] = defenv['CXX'] + ' -Ae'

As far as I can tell, it does find aCC with no issue. And on any HPUX system, until there is some unaligned option, gcc/g++ cannot be used to build makensis, so aCC is exactly and only what is needed.

Given that we are using the scons detection of aCC to drive the process into using SCons/Conf/hpux, it seems correct to say that if we are in SCons/Conf/hpux, CXX = 'aCC' and thus CC must be 'aCC -Ae', no matter what scons says, even when all scons bugs are fixed.
I think it'd be better to check for _BIG_ENDIAN with a configuration test, just like in SCons/Config/gnu. A simple #ifdef can make sure the test program will return 1 in case _BIG_ENDIAN is defined.

kichikApril 24, 2007 at 6:34 PM#

It doesn't find aCC (the C compiler) and that's why it loads gcc. Look in SCons/Tool/__init__.py and you'll see this logic. I also forgot to mention that '-Ae' should go into CCFLAGS and not CC.

defenv.Append(CCFLAGS = '-Ae')

Regarding _BIG_ENDIAN, I prefer not to run tests that aren't really needed. With Visual C++, this isn't required because we're always building for Win32 and on GCC it's only required sometimes. It'd be semi-global if the split is made from SCons/Config/gnu into SCons/Config/posix.

Cross compilation environments aren't so elegant in SCons, but already dealt with in the gnu configuration file. There's a function there that converts a given environment to a cross-compile environment.

deckriderApril 25, 2007 at 4:02 PM#

It seems that anything I add to CCFLAGS also goes to CXX.

kichikApril 25, 2007 at 4:52 PM#

Right, that was recently changed. Use CFLAGS instead (one C only).

deckriderApril 26, 2007 at 9:43 PM#

Here is the latest incarnation of script/patches.

I have not addressed the cross-compiler issues, since don't have a cross compiler in this environment so as to test anything I do in this regard.

And I'm still setting CC = CXX because, even if it finds some other HP c compiler, I only want it to use CXX when building makensis.

kichikApril 27, 2007 at 9:51 AM#

Thanks. Please submit a patch and I'll add it after 2.26.

deckriderApril 30, 2007 at 2:08 PM#

nsis scons paradigm

I've not yet submitted a patch, because I'm still confused as to the mindset I should use when thinking about scons changes, specifically relating to selecting compilers and paths ($CC, $CXX, $PATH) on unix environments.

I'm an avid autotools user (autoconf, automake, libtool), so I tend to start with the idea that $CC, $CXX, $PATH can be determined by the person running the build.

When I patch nsis to accept my PATH, scons finds all my compilers on hpux ia64, but prefers CC=/opt/ansic/bin/cc and CXX=/opt/aCC/bin/aCC over any of the others.

On hpux, it is possible that one might have /opt/aCC/bin/aCC, but not /opt/ansic/bin/cc.

It may also be possible that the hpux user would want to select /opt/hp-gcc/bin/gcc and /opt/hp-gcc/bin/g++ over any of the other installed compilers.

There are options for each of these scenarios which will allow for unaligned access on hpux.

But currently, it is does not seem possible for the builder to determine PATH, CXX, and CC within nsis. I'm curious if this is your preference?

kichikApril 30, 2007 at 4:14 PM#

SCons doesn't provide much of a convenient user interface for selecting the compilers used to build. When you build an environment with the default values, it'll load what it thinks is best. Then it'll go on and search additional peripheral tools. It's also possible to pass a list of tools to load instead of this default behavior.

The tools define far more than just the path of the compiler. They define required flags, available builders, file extensions, etc. Tool definitions are made of code, so they are able to perform complex searches. Take NSIS/SCons/Tools/crossmingw.py for example, which searches for the right compiler.

Add the Options list only being able to perform on an already existing environment with a loaded set of tools and you get (1) an ugly hack to load specific tools and not the defaults, (2) inability to define just the compiler path and (3) errors about missing builders when using an incomplete list of tools (i.e. no tool for C selected).

Number 2 has a very good reason and I actually like that about SCons. Number 1 can be solved by using ARGUMENTS, which I forgot about. Number 3 must be handled by the user with a little help from the build scripts that add the tools that are always required - namely `zip`. It can also be solved by adding a tool selection mechanism to SCons which will allow selecting a specific tool for a specific task while allowing tools for other tasks to be automatically detected.

I've now added the TOOLSET option to SConstruct which allows passing a comma-separated list of tools to load instead of the default. It assumes the user selects a tool for each required task. Instead of directly selecting the C compiler, it asks for a name SCons builder to do the task. Flags can still be added with APPEND_CCFLAGS and APPEND_LINKFLAGS.

Which of the options work on GCC? Does the unalign lib work on GCC as well?

deckriderApril 30, 2007 at 4:35 PM#

Originally posted by kichik
Which of the options work on GCC? Does the unalign lib work on GCC as well?

Compiling with gcc/g++ seems to work fine with the following approach on hpux ia64:

1. since there are no headers for allow_unaligned_data_access(), one must define it:

extern "C" { void allow_unaligned_data_access(); }

2. then at the beginning of main():

allow_unaligned_data_access();

3a. finally, on Itanium link:

-lunalign

3b. or on PA-RISC link:

-lhppa

But of course, this means there must be some way of knowing you are on these platforms so as to select the correct actions.

kichikApril 30, 2007 at 4:38 PM#

SCons uses if env['PLATFORM'] == 'hpux', so that should be good enough.

deckriderApril 30, 2007 at 4:49 PM#

Originally posted by kichik
SCons uses if env['PLATFORM'] == 'hpux', so that should be good enough.

Is there another way that determines whether to use -lunalign or -lhppa? (note that on Itanium at least, both libraries are installed, because we have emulation capabilities).

kichikApril 30, 2007 at 4:52 PM#

If linking to both on Itanium is ok, both can be checked for and linked against if they exist.

deckriderApril 30, 2007 at 4:58 PM#

This is the result:

ld: Can't find library or mismatched ABI for -lhppa

(In our case, it is the mismatched ABI, since we are compiling for ia64).

kichikApril 30, 2007 at 5:03 PM#

As long as it's an error, it's good enough for the configuration functions which expect nothing bug success before they include a library. See AddAvailableLibs in SCons/utils.py.

deckriderApril 30, 2007 at 5:08 PM#

Yes, to confirm, both g++ and aCC return an error to the shell when trying to link to the wrong ABI.

deckriderMay 1, 2007 at 3:55 PM#

Originally posted by kichik
I've now added the TOOLSET option to SConstruct which allows passing a comma-separated list of tools to load instead of the default. It assumes the user selects a tool for each required task. Instead of directly selecting the C compiler, it asks for a name SCons builder to do the task. Flags can still be added with APPEND_CCFLAGS and APPEND_LINKFLAGS.

I've tried this TOOLSET option, but it isn't working, since the PATH cannot be set, and it doesn't seem to go through any scons logic to search the path.

deckriderMay 1, 2007 at 6:49 PM#

Here is the latest incarnation of make-nsis.txt script/patch.

I think the only remaining issue in the patch is that I've incorporated the PATH, so it can find the various tools, since on my HP system they are as follows (and who can predict where others may have installed their tools):

/opt/aCC/bin/aCC
/opt/ansic/bin/cc

/opt/hp-gcc/bin/gcc
/opt/hp-gcc/bin/g++

/usr/local/bin/gcc
/usr/local/bin/c++

However, I'm open to discovering or being shown other issues 🙂

It should work for both gcc/g++ and aCC on both PA-RISC/Itanium on all HP-UX.

To use g++/gcc instead, change from:

TOOLSET=hpc++,hpcc,hplink

to:

TOOLSET=g++,gcc,gnulink

Also, be sure your PATH contains all the locations of the tools you plan to use.

deckriderMay 7, 2007 at 1:58 PM#

Originally posted by kichik
Thanks. Please submit a patch and I'll add it after 2.26.

Patch #1714416 submitted.

kichikMay 19, 2007 at 5:48 PM#

Thanks. I'll take a look when I get the time.

PortanteJune 15, 2007 at 1:44 AM#

UCS-2LE not available under HP-UX

Hello folks,

I have tried deckrider's patch (applied to NSIS 2.28), and I have had to make a few other tweaks to get the install compiler built. However, the setup.exe generated hangs on our windows box. Perhaps I can confirm that the tweaks I have made are not too harmful.

I am running things on an rx2600 (IA) HP-UX 11.23 (the 0505 release) with the following compiler versions

B3901BA C.11.23.09 HP C/ANSI C Developer's Bundle (S800)
B3913DB C.05.55 HP aC++ Compiler (S800)

Using HP's C++ compiler the anonymous unions in ResourceEditor.h were considered errors. So as a work around, I named them _a and _b and modified the source code to reference them. Ugly, I know, but wanted to get around that for now.

I then modified deckrider's hpc++ configuration to add +W829 so that a number of warnings about deprecated constant conversions would be ignored.

I then had to tweak util.cpp, to change "CP1252" to "cp1252", and "UCS-2LE" to "UCS-2BE" in order for HP-UX's iconv_open() to accept the arguments. However, the use of UCS-2BE most likely means that I cannot use nsis-2.28.zip pre-compiled contents, as those executables use UCS-2LE, right?

Thanks, -peter

deckriderJune 15, 2007 at 8:53 AM#

Re: UCS-2LE not available under HP-UX

Originally posted by Portante
Hello folks,

I have tried deckrider's patch (applied to NSIS 2.28), and I have had to make a few other tweaks to get the install compiler built. However, the setup.exe generated hangs on our windows box

I haven't tried NSIS 2.28 yet. We've been using the patch (#1714416) that was uploaded to sourceforge without issue, but only to build the 'makensis' executable and only for NSIS 2.27. (I'll provide a few more details when I get to work--no such host with me here at home.) Do you have these issues with 2.27?

kichikJune 15, 2007 at 12:47 PM#

You can't use UCS-2BE. Windows uses little endian so every string must be encoded with little endian and not big endian. If HP-UX's libiconv doesn't support UCS-2LE, it can't be used and must be replaced.

deckriderJune 15, 2007 at 3:47 PM#

Re: Re: UCS-2LE not available under HP-UX

Originally posted by deckrider
(I'll provide a few more details when I get to work--no such host with me here at home.)

Still haven't tried 2.28 yet, but here are my details for 2.27:



$ uname -a

HP-UX omztdv1 B.11.23 U ia64 2505142627 unlimited-user license



$ aCC -V

aCC: HP C/aC++ B3910B A.06.12 [Aug 17 2006]



$ cc -V

cc: HP aC++/ANSI C B3910B A.06.10 [Mar 22 2006]



$ ldd `which makensis`

        libunalign.so.1 =>      /usr/lib/hpux32/libunalign.so.1

        libpthread.so.1 =>      /usr/lib/hpux32/libpthread.so.1

        libiconv.so =>  /usr/local/lib/hpux32/libiconv.so

        libstd_v2.so.1 =>       /usr/lib/hpux32/libstd_v2.so.1

        libCsup.so.1 => /usr/lib/hpux32/libCsup.so.1

        libm.so.1 =>    /usr/lib/hpux32/libm.so.1

        libunwind.so.1 =>       /usr/lib/hpux32/libunwind.so.1

        libc.so.1 =>    /usr/lib/hpux32/libc.so.1

        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1

        libc.so.1 =>    /usr/lib/hpux32/libc.so.1

        libuca.so.1 =>  /usr/lib/hpux32/libuca.so.1





# note above that I didn't link to the native libiconv

# but the one I link to is available from HP :



$ swlist -l file | grep /usr/local/lib/hpux32/libiconv.so



  GNUbase.GNUBASE-IPF-RUN: /usr/local/lib/hpux32/libiconv.so



# and finally how I build:



scons \

        SKIPSTUBS=all \

        SKIPPLUGINS=all \

        SKIPUTILS=all \

        SKIPMISC=all \

        VERSION=$PACKAGE_VERSION \

        PATH=$PATH \

        TOOLSET=hpc++,hpcc,hplink \

        APPEND_CPPPATH=/usr/local/include \

        APPEND_LIBPATH=/usr/local/lib/hpux32 \

        PREFIX_BIN=/opt/vzb/bin \

        PREFIX=/opt/vzb \

        PREFIX_CONF=/etc/opt/vzb \

        PREFIX_DEST=$DSTDIR \

        install-compiler

PortanteJune 28, 2007 at 12:47 PM#

Here is what I had to do to get NSIS 2.28 to work for HP-UX

Folks, here is what I had to do to get NSIS 2.28 to build and run on HP-UX 11.11 (PA) and 11.23 (IA) platforms. The additional patch (see attachment) contains:

hpc++: a couple of flags to enable the code to be compiled with only a few changes
SConstruct: change order of gnu and hpc++ conditionals so that GNU is not recognized by default
ResourceEditor.cpp, ResourceEditor.h, util.cpp: remove anonymous unions; this is a hack fix, which I did not like doing, but I didn't find a compiler switch to enable this behavior; also for util.cpp, the new and delete operator definitions conflicted with HP-UX C++ header files.

How to build NSIS for HP-UX (using NSIS 2.28 as an example)

Assumptions:

For 11.23 IA



$ swlist -a revision -a architecture -a title B3913DB,r=C.05.55

# B3913DB                       C.05.55        HP-UX_B.11.23_IA HP aC++ Compiler (S800) 

  B3913DB.C-Dev-Tools           B.11.23.03     HP-UX_B.11.23_IA C Language Development Tools 

  B3913DB.Caliper               B.11.23.03     HP-UX_B.11.23_IA HP Itanium Performance Measurement Tools 

  B3913DB.ACXX                  C.05.55        HP-UX_B.11.23_IA HP aC++        

  B3913DB.WDB-GUI               B.11.23.03     HP-UX_B.11.23_IA GUI for the HP WDB Debugger 

  B3913DB.WDB                   B.11.23.03     HP-UX_B.11.23_IA HP Wildebeest (HP WDB) Debugger 

  B3913DB.Auxiliary-Opt         B.11.23.03     HP-UX_B.11.23_IA Auxiliary Optimizer for HP Languages. 

$ aCC -V

aCC: HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003]

$ swlist -a revision -a architecture -a title B3901BA,r=C.05.55

# B3901BA                       C.05.55        HP-UX_B.11.23_IA HP C/ANSI C Developer's Bundle (S800) 

  B3901BA.C-ANSI-C              C.05.55        HP-UX_B.11.23_IA HP C/ANSI C Compiler 

  B3901BA.X11MotifDevKit        B.11.23.03     HP-UX_B.11.23_IA/PA HP-UX Developer's Toolkit - X11, Motif, and Imake 

  B3901BA.Caliper               B.11.23.03     HP-UX_B.11.23_IA HP Itanium Performance Measurement Tools 

  B3901BA.WDB-GUI               B.11.23.03     HP-UX_B.11.23_IA GUI for the HP WDB Debugger 

  B3901BA.WDB                   B.11.23.03     HP-UX_B.11.23_IA HP Wildebeest (HP WDB) Debugger 

  B3901BA.Auxiliary-Opt         B.11.23.03     HP-UX_B.11.23_IA Auxiliary Optimizer for HP Languages. 

  B3901BA.C-Dev-Tools           B.11.23.03     HP-UX_B.11.23_IA C Language Development Tools 

$ cc -V

cc: HP aC++/ANSI C B3910B A.05.55 [Dec 04 2003]

$ swlist -a revision -a architecture -a title gcc libiconv

# gcc                           3.4.3          HP-UX_B.11.23_64 gcc            

  gcc.gcc-INC                                                                

  gcc.gcc-MAN                                                                

  gcc.gcc-RUN                                                                

  gcc.gcc-SHLIBS                                                             

# libiconv                      1.11           HP-UX_B.11.23_64 libiconv       

  libiconv.libiconv-RUN

For 11.11 PA



$ swlist -a revision -a architecture -a title B3913DB,r=C.03.70

# B3913DB                       C.03.70        HP-UX_B.11.11_32/64 HP aC++ Compiler (S800) 

  B3913DB.C-Dev-Tools           B.11.11.16     HP-UX_B.11.00_32/64 C Language Development Tools 

  B3913DB.ACXX                  C.03.70        HP-UX_B.11.00_32/64 HP aC++        

  B3913DB.CodeAdvisor           C.01.00        HP-UX_B.11.00_32/64 HP Static Analysis Tool 

  B3913DB.WDB-GUI               B.11.11.16     HP-UX_B.11.00_32/64 GUI for the HP WDB Debugger 

  B3913DB.WDB                   B.11.11.16     HP-UX_B.11.00_32/64 HP Wildebeest (HP WDB) Debugger 

  B3913DB.DebugPrg              B.11.11.16     HP-UX_B.11.00_32/64 Debugging Support Tools 

  B3913DB.Auxiliary-Opt         B.11.11.16     HP-UX_B.11.00_32/64 Auxiliary Optimizer for HP Languages. 

# aCC -V

aCC: HP ANSI C++ B3910B A.03.70

# swlist -a revision -a architecture -a title B3901BA,r=B.11.11.16

# B3901BA                       B.11.11.16     HP-UX_B.11.11_32/64 HP C/ANSI C Developer's Bundle for HP-UX (S800) 

  B3901BA.C-ANSI-C              B.11.11.16     HP-UX_B.11.00_32/64 HP C/ANSI C Compiler 

  B3901BA.X11MotifDevKit        B.11.11.02     HP-UX_B.11.11_32/64 HP-UX Developer's Toolkit - X11, Motif, and Imake 

  B3901BA.ImagingDevKit         B.11.11.02     HP-UX_B.11.11_32/64 HP-UX Developer's Toolkit - Imaging 

  B3901BA.CDEDevKit             B.11.11.02     HP-UX_B.11.11_32/64 CDE Developer Kit 

  B3901BA.AudioDevKit           B.11.11.02     HP-UX_B.11.11_32/64 HP-UX Audio Developer Kit 

  B3901BA.CodeAdvisor           C.01.00        HP-UX_B.11.00_32/64 HP Static Analysis Tool 

  B3901BA.WDB-GUI               B.11.11.16     HP-UX_B.11.00_32/64 GUI for the HP WDB Debugger 

  B3901BA.WDB                   B.11.11.16     HP-UX_B.11.00_32/64 HP Wildebeest (HP WDB) Debugger 

  B3901BA.DebugPrg              B.11.11.16     HP-UX_B.11.00_32/64 Debugging Support Tools 

  B3901BA.Auxiliary-Opt         B.11.11.16     HP-UX_B.11.00_32/64 Auxiliary Optimizer for HP Languages. 

  B3901BA.C-Dev-Tools           B.11.11.16     HP-UX_B.11.00_32/64 C Language Development Tools 

  B3901BA.C-Analysis-Tools      B.11.11.16     HP-UX_B.11.00_32/64 C Language Analysis Tools 

# cc -V tmp.c

cpp.ansi: HP92453-01 B.11.11.16 HP C Preprocessor (ANSI)

ccom: HP92453-01 B.11.11.16 HP C Compiler

/usr/ccs/bin/ld: 92453-07 linker linker ld B.11.53 060322

$ swlist -a revision -a architecture -a title gcc libiconv

# gcc                           3.4.3          HP-UX_B.11.11_700/800 gcc            

  gcc.gcc-INC                                                                

  gcc.gcc-MAN                                                                

  gcc.gcc-RUN                                                                

# libiconv                      1.11           HP-UX_B./800   libiconv       

  libiconv.libiconv-RUN

/tmp/nsis-2.28.zip exists
/tmp/nsis-2.28-src.tar exists
/tmp/nsis-hpux.patch (http://sourceforge.net/tracker/downl...05&aid=1714416) exists
/tmp/nsis-hpux-vse.patch exists (see attachment)

Note that HP-UX's /usr/bin/patch does not work with the patch files listed above. So the source tree might first have to be patched up on a box with GNU patch 2.5.9 (http://mirrors.ibiblio.org/pub/mirro...h-2.5.9.tar.gz ) or later, and then moved to the target HP-UX box (installing and running GNU patch on the HP-UX box will work as well).

For both IA and PA first perform the following steps:



cd /opt

umask 022

unzip /tmp/nsis-2.28.zip

ln -s nsis-2.28 nsis

cd /tmp

tar xf /tmp/nsis-2.28-src.tar

cd nsis-2.28-src

patch -p1 < ../nsis-hpux.patch

patch -p1 < ../nsis-hpux-vse.patch

Then, for PA:



scons \

    SKIPSTUBS=all \

    SKIPPLUGINS=all \

    SKIPUTILS=all \

    SKIPMISC=all \

    NSIS_CONFIG_CONST_DATA_PATH=no \

    APPEND_CPPPATH=/usr/local/include \

    APPEND_LIBPATH=/usr/local/lib \

    PREFIX=/opt/nsis \

    install-compiler

Then, for IA (only difference is that APPEND_LIBPATH is set to /usr/local/lib/hpux32):



scons \

    SKIPSTUBS=all \

    SKIPPLUGINS=all \

    SKIPUTILS=all \

    SKIPMISC=all \

    NSIS_CONFIG_CONST_DATA_PATH=no \

    APPEND_CPPPATH=/usr/local/include \

    APPEND_LIBPATH=/usr/local/lib/hpux32 \

    PREFIX=/opt/nsis \

    install-compiler

kichikJune 29, 2007 at 3:02 PM#

Does that remove the need for the PATH change? deckrider, does the new patch work for you too?

deckriderJuly 20, 2007 at 5:39 PM#

Originally posted by kichik
Does that remove the need for the PATH change? deckrider, does the new patch work for you too?

Sorry to take so long to respond, I just noticed this recently. A friend loaned me some time on:

HP-UX B.11.11 U 9000/893 HP-UX
aCC: HP ANSI C++ B3910B A.03.34

As a small note, on this older compiler, I had to convert all the source
code from dos to unix line endings, otherwise it would fail on #define
multiline continuations.

I'm providing a patch to nsis-2.29-src which works for both the above
host/compiler and:

HP-UX B.11.23 U ia64
aCC: HP C/aC++ B3910B A.06.12 [Aug 17 2006]

The only real difference from my original patch is that it adds -AA to
CXXFLAGS (its the default on aCC A.06.12) and fixes some compile errors
in Source/util.cpp (they were only warnings on aCC A.06.12).

Clearly, the library locations will be different, but these should be
specified by the user anyway.

I should explain that my patches are essentially to add alignment fixups based on SIGBUS. Either -lunalign or -lhppa provides this handler
as documented here:

http://h30097.www3.hp.com/docs/porting/tru64-to-hpux/tru64-to-hpux.pdf

As for Portante's patch, I haven't yet had the time to analyze or test
it, but if it converts makensis to using only aligned access, then this
is better and the alignment fixups I'm using are not needed, and should
be removed.

deckriderJuly 20, 2007 at 6:36 PM#edited July 20, 2007 at 7:11 PM

I had more time than I thought this afternoon:

I tried applying nsis-hpux.patch-patch.txt, and during the hpux ia64 build I get these:

aCC: warning 967: Option -AA or -AP does not apply to ANSI C compilation, ignored.

Without the alignment fixups from http://h30097.www3.hp.com/docs/porti...64-to-hpux.pdf the running of makensis still results in a bus error.

But the 'anonymous' warnings are now gone 🙂 so I'm going to add that patch to my build of nsis-2.29-src.

Here are the only warnings left for me on hpux ia64:



aCC -o build/release/makensis/build.o -c +DD32 -mt -AA -D__BIG_ENDIAN__ -DNSIS_HPUX_ALLOW_UNALIGNED_DATA_ACCESS -D_WIN32_IE=0x0500 -I/usr/local/include Source/build.cpp

"Source/build.cpp", line 534: warning #2068-D: integer conversion resulted in

          a change of sign

                  *out++ = (unsigned int) NS_VAR_CODE; // Named user variable;

                           ^



"Source/build.cpp", line 558: warning #2068-D: integer conversion resulted in

          a change of sign

                  *out++=(unsigned int)NS_SHELL_CODE; // Constant code identifier

                         ^



"Source/build.cpp", line 579: warning #2068-D: integer conversion resulted in

          a change of sign

                  *out++ = (unsigned int)NS_LANG_CODE; // Next word is lang-string Identifier

                           ^



aCC -o build/release/makensis/script.o -c +DD32 -mt -AA -D__BIG_ENDIAN__ -DNSIS_HPUX_ALLOW_UNALIGNED_DATA_ACCESS -D_WIN32_IE=0x0500 -I/usr/local/include Source/script.cpp

"Source/script.cpp", line 2775: warning #2186-D: pointless comparison of

          unsigned integer with zero

          if (s < 0)

                ^



"Source/script.cpp", line 5760: warning #2111-D: statement is unreachable

      return PS_ERROR;

      ^



aCC -o build/release/makensis/util.o -c +DD32 -mt -AA -D__BIG_ENDIAN__ -DNSIS_HPUX_ALLOW_UNALIGNED_DATA_ACCESS -D_WIN32_IE=0x0500 -I/usr/local/include Source/util.cpp

"Source/util.cpp", line 676: warning #2186-D: pointless comparison of unsigned

          integer with zero

        if( nchars < 0 ){

                   ^

Note that I did not use +W829 (I think it just suppresses a compiler message for a certain compiler--not the version I'm using, since none of my warnings have that number)

deckriderJuly 20, 2007 at 7:59 PM#

Here is the final combined patch (thanks Portante) that I'm using (eliminates all aCC compiler warnings on hpux ia64 aCC HP C/aC++ B3910B A.06.12 [Aug 17 2006]).

kichikJuly 21, 2007 at 1:52 PM#

Could you change _a and _b to meaningful names, wrap __THROWSPEC_NULL in some kind of #ifdef and preferably comment on its meaning (Google shows nothing) and submit it as a patch?

deckriderJuly 23, 2007 at 11:07 AM#

Originally posted by kichik
Could you change _a and _b to meaningful names, wrap __THROWSPEC_NULL in some kind of #ifdef and preferably comment on its meaning (Google shows nothing) and submit it as a patch?

Ooops....didn't mean to let that slip through: '__THROWSPEC_NULL' should really be 'throw()' and '__THROWSPEC_X(__bad_alloc)' should really be 'throw(bad_alloc)'. The patch I submitted has that corrected, but not in any #ifdef, since it should just be standard for all compilers (but I haven't tested on msvc).

The meaningful names I chose are: UName and UOffset, but these can easily be searched and replaced in the patch if they aren't good.

I've submitted patch
1758863 at https://sourceforge.net/tracker/inde...49&atid=373087

I developed this patch using free accounts from http://www.testdrive.hp.com/ which I would like to recommend trying.

It may help to understand why PATH may need to be specified (for instance, if you want to compile using GCC on HPUX, but you must build/install GCC in your home directory since you don't have administrator rights).

Also, I think it may valuable to try some changes first hand if needed.