Error Building NSIS on HP-UX

Hi,

I'm trying to build NSIS on HP-UX environment.
I have installed Python-2.5, scons-0.96.95 and trying to install nsis-2.24.

I tried to install using:
scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all NSIS_CONFIG_CONST_DATA_PATH=no PREFIX=/tmp install-compiler

and that's the log:


root@itacare:/home/zembrzus/nsis/NSIS# scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all NSIS_CONFIG_CONST_DATA_PATH=no PREFIX=/tmp>
scons: Reading SConscript files ...
Delete("nsis-30-Mar-2007.cvs")
Delete(".instdist")
Delete(".test")
Using GNU tools configuration
Checking for linker flag -m32... (cached) yes
Checking for compiler flag -m32... (cached) no
Checking for linker flag $MAP_FLAG... (cached) no
Checking for linker flag -s... (cached) yes
Checking for linker flag $MAP_FLAG... (cached) no
Checking for linker flag -s... (cached) yes
Checking for memcpy requirement... (cached) yes
Checking for memset requirement... (cached) yes
Checking for linker flag -pthread... (cached) yes
Checking for __BIG_ENDIAN__... (cached) no
Checking for C library gdi32... (cached) no
Checking for C library user32... (cached) no
Checking for C library pthread... (cached) yes
Checking for C library stdc++... (cached) yes
Checking for C library iconv... (cached) no
Checking for C library dl... (cached) yes
Checking for C library gdi32... (cached) no
Checking for C library iconv... (cached) no
Checking for C library pthread... (cached) yes
Checking for C library user32... (cached) no
Checking for C++ library cppunit... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
g++ -o build/release/makensis/makensis -m32 -s -pthread build/release/makensis/build.o build/release/makensis/clzma.o build/release/makensis/crc32.o build/release/makensis/DialogTemplate.o build/release/makensis/dirreader.o build/release/makensis/fileform.o build/release/makensis/growbuf.o build/release/makensis/lang.o build/release/makensis/lineparse.o build/release/makensis/makenssi.o build/release/makensis/manifest.o build/release/makensis/mmap.o build/release/makensis/Plugins.o build/release/makensis/ResourceEditor.o build/release/makensis/ResourceVersionInfo.o build/release/makensis/script.o build/release/makensis/ShConstants.o build/release/makensis/strlist.o build/release/makensis/tokens.o build/release/makensis/util.o build/release/makensis/winchar.o build/release/makensis/writer.o build/release/makensis/bzip2/blocksort.o build/release/makensis/bzip2/bzlib.o build/release/makensis/bzip2/compress.o build/release/makensis/bzip2/huffman.o build/release/makensis/7zip/7zGuids.o build/release/makensis/7zip/7zip/Common/OutBuffer.o build/release/makensis/7zip/7zip/Common/StreamUtils.o build/release/makensis/7zip/7zip/Compress/LZ/LZInWindow.o build/release/makensis/7zip/7zip/Compress/LZMA/LZMAEncoder.o build/release/makensis/7zip/7zip/Compress/RangeCoder/RangeCoderBit.o build/release/makensis/7zip/Common/Alloc.o build/release/makensis/7zip/Common/CRC.o build/release/makensis/zlib/deflate.o build/release/makensis/zlib/trees.o -Lbuild/release/makensis -LSource -lpthread -lstdc++
ld: Unsatisfied symbol "libiconv_open" in file build/release/makensis/util.o
ld: Unsatisfied symbol "libiconv_close" in file build/release/makensis/util.o
ld: Unsatisfied symbol "libiconv" in file build/release/makensis/util.o
3 errors.
collect2: ld returned 1 exit status
scons: *** [build/release/makensis/makensis] Error 1
scons: building terminated because of errors.

Any toughts ?

Thanks in advance!!

Delete .sconsign.dblite and add LIBPATH=/usr/lib/where/ever/iconv/is/located to the build line.

I forgot LIBPATH doesn't actually work. Wait for 2.25 which will be released today and use APPEND_LIBPATH instead.

Ok. It have worked fine to me. Thanks.

Now I've nsis installed, but I'm getting this error trying to compile the example1.nsi.

What would be my fault?

Thanks.

root@itacare:/home/zembrzus/nsis-2.25# ./makensis Examples/example1.nsi
MakeNSIS v02-Apr-2007.cvs - Copyright 1995-2007 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.

Processing config:
Processing plugin dlls: "/home/zembrzus/nsis-2.25/Plugins/*.dll"

!define: "MUI_INSERT_NSISCONF"=""

Changing directory to: "/home/zembrzus/nsis-2.25/Examples"

Processing script file: "Examples/example1.nsi"
Name: "Example1"
OutFile: "example1.exe"
InstallDir: "$PROGRAMFILES\Example1"
Page: directory
Page: instfiles
Section: ""
SetOutPath: "$INSTDIR"
File: "example1.nsi" [compress] 378/794 bytes
SectionEnd

Processed 1 file, writing output:
Processing pages... Done!
Removing unused resources...
Error: Unsupported PE format
Error - aborting creation process

Sounds like every executable you extracted got corrupted somehow. Notice it doesn't find any plug-ins either. Try extracting the ZIP again and make sure the DLL files and the files in Stubs have have some normal data in them.

I'm also having the same problem:

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

Does anyone have any luck building AND using NSIS on this platform?

Seems like big endian support was broken since 2.24. The PE magic wasn't converted to big endian prior to comparison. Use the attached patch to fix this.

(Or on cvs)

Still not working. Here is more info, including an attached script you can run to reproduce my results:

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

$ gcc --version
gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ scons --version
SCons by Steven Knight et al.:
script: v0.96.96.D001, 2007/04/12 14:12:18, by knight on roxbury
engine: v0.96.96.D001, 2007/04/12 14:12:18, by knight on roxbury
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007 The SCons Foundation

Here is also the result of running the earlier build script.

That's due to memory alignment problems. There's an open bug report regarding this. For now, you can run makensis under WINE.

I'm dubious of wine working at all on hpux ia64, but I'll look into it: my initial attempt to compile on hpux ia64 failed quickly, and I'm not seeing pre-built binaries in my initial search.

Just thought I'd report back that I've given up on the possibility of makensis on HP-UX B.11.23 ia64. My skills are not good enough to patch either wine or nsis to make it work.

But just in case anyone out there can know a patch, I'll post the gdb backtrace here.

Hey, I got it working...after giving up and looking into some other issue, we stumbled across an HP compiler option "+u1" which allows for unaligned access. Anyone know if there is a corresponding gcc option for this?

So here is a crude script containing some patches--don't know if they are all really needed. I know a lot more about GNU autotools than 'scons'. It seems like it ought to be easier to pass compiler flags/options without patching files to do it, but maybe I'm just missing something.

Anyway, compiler options that only work with one compiler probably shouldn't be forced on other compilers (-Wall and -m32 come to mind).

Also the test for big endian appears to get it wrong for HPUX ia64, which is why I force the -D entry for it.

GCC should support -mno-strict-align according to the following message:

To add compiler flags or linker flags, you can pass APPEND_CCFLAGS or APPEND_LINKFLAGS in the scons build line.

-Wall and -m32 aren't forced on any compilers because the file that adds them (SCons/Config/gnu) is specific to gcc.

The test for big endian is pretty simple. If it failed, it's probably because the environment wasn't properly set when it was ran. To verify, delete .sconsign.dblite and .sconf_temp and run scons again. Then you can see exactly what happens in config.log.

We have 3 compilers on our system:

(1) hpux ansi c and c++:

/usr/bin/cc
/opt/aCC/bin/aCC

(2) gcc (I think it was version 3.4) packaged by hp

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

(3) gcc 4.1.2 packaged by hp

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

When I do no patches, it seems to select /opt/aCC/bin/aCC for c++ and /usr/local/bin/gcc for c (this last bit about gcc I will re-confirm when I get to the office).

And then "-Wall" is an error to /opt/aCC/bin/aCC.

I'm using scons 0.96.96.

I'm willing to learn and help to get any of this nicely fixed (I know not everyone has access to this platform). Let me know what you would like from me and I can try to provide it (unfortunately I cannot provide direct login access to our hardware).

Re: "(2) gcc (I think it was version 3.4) packaged by hp"

... the precise version is 3.4.3

Re: "When I do no patches, it seems to select /opt/aCC/bin/aCC for c++ and /usr/local/bin/gcc for c."

... I have re-verified this behavior.

Thus, the first un-patched error looks like this (notice "Using GNU tools configuration", how do I get it not to use that, since the aCC compiler became selected?):

deverly@omztdv1:~/helper-tools/nsis-2.25-src$ scons DEBUG=yes STRIP=no SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all PREFIX_BIN=/opt/vzb/bin PREFIX=/opt/vzb PREFIX_CONF=/etc/opt/vzb APPEND_LINKFLAGS="-L/usr/local/lib/hpux32" install-compiler
scons: Reading SConscript files ...
Delete("nsis-20-Apr-2007.cvs")
Delete(".instdist")
Delete(".test")
Using GNU tools configuration
Checking for linker flag -m32... yes
Checking for compiler flag -m32... no
Checking for linker flag $MAP_FLAG... no
Checking for linker flag $MAP_FLAG... no
Checking for memcpy requirement... yes
Checking for memset requirement... yes
Checking for linker flag -pthread... yes
Checking for __BIG_ENDIAN__... no
Checking for C library gdi32... no
Checking for C library user32... no
Checking for C library pthread... yes
Checking for C library stdc++... yes
Checking for C library iconv... yes
Checking for C library dl... yes
Checking for C library gdi32... no
Checking for C library iconv... yes
Checking for C library pthread... yes
Checking for C library user32... no
Checking for C++ library cppunit... no
scons: done reading SConscript files.
scons: Building targets ...
/opt/aCC/bin/aCC -o build/debug/makensis/build.o -c -g -Wall -D_WIN32_IE=0x0500 -Ibuild/debug/makensis -ISource Source/build.cpp
aCC: error 1914: bad form for `-W' option
scons: *** [build/debug/makensis/build.o] Error 1
scons: building terminated because of errors.

I've looked at the __BIG_ENDIAN__ test and now see that both flavors of gcc/g++/c++ on my system define __BIG_ENDIAN__, but cc/aCC do not (they define _BIG_ENDIAN instead).

So the bad test was really a symptom caused by the bad combination of gcc with aCC noted earlier.

Just tested: both gcc 3.4.3 and 4.1.2 do NOT support -mno-strict-align on hpux ia64:

error: invalid option `no-strict-align'

Thus far this means only the HP compilers and their options can be used.

Under nsis 2.25 and HP cc/aCC, there are two compile errors in the unpatched source code:

/opt/aCC/bin/aCC -o build/debug/makensis/Plugins.o -c -mt +u1 -g -D__BIG_ENDIAN__ -D_WIN32_IE=0x0500 -Ibuild/debug/makensis -ISource Source/Plugins.cpp
"Source/Plugins.cpp", line 72: error #2350: more than one operator ">="
matches these operands:
built-in operator "arithmetic >= arithmetic"
function "std::fpos<_StateT>:😳perator>=(const std::fpos<_StateT>
&) const [with _StateT=mbstate_t]"
function "std::fpos<_StateT>:😳perator>=(std::streamoff) const
[with _StateT=mbstate_t]"
operand types are: std::basic_ifstream<char,
std::char_traits<char>>:😛os_type >= int
assert(result >= 0);
^

1 error detected in the compilation of "Source/Plugins.cpp".
scons: *** [build/debug/makensis/Plugins.o] Error 2
scons: building terminated because of errors.


/opt/aCC/bin/aCC -o build/debug/makensis/ResourceEditor.o -c -mt +u1 -g -D__BIG_ENDIAN__ -D_WIN32_IE=0x0500 -Ibuild/debug/makensis -ISource Source/ResourceEditor.cpp

"Source/ResourceEditor.cpp", line 684: error #2308: more than one instance of
overloaded function "ConvertEndianness" matches the argument list:
function "ConvertEndianness(DWORD)"
function "ConvertEndianness(LONG)"
function "ConvertEndianness(WORD)"
argument types are: (unsigned long)
PIMAGE_RESOURCE_DATA_ENTRY(cRDataE->m_dwWrittenAt)->OffsetToData = ConvertEndianness(seeker - pbRsrcSec + m_dwResourceSectionVA);
^

1 error detected in the compilation of "Source/ResourceEditor.cpp".
scons: *** [build/debug/makensis/ResourceEditor.o] Error 2
scons: building terminated because of errors.

Well I've tried the SCons/Config/hpux with patching in the elif 'hpcc' statement, but its still selecting gnu instead.

The SCons problem needs to be handled first. Because it selects gcc for C code, NSIS build system selects the gnu configuration. For test purpose you can change the elif line just one line above the one you've added.

Originally posted by kichik
The SCons problem needs to be handled first. Because it selects gcc for C code, NSIS build system selects the gnu configuration. For test purpose you can change the elif line just one line above the one you've added.

I'm not sure I understand what you mean ... what I think you mean didn't fix it.

Here is what I have working so far. It is attached as a build/patch script and the output of it.

(I know it only patches SConstruction and SCons/Config/gnu, but I'm still clueless on them).

Interestingly, it builds 5 out of 6 examples under "Examples/Modern UI". The one it fails on is MultiLanguage.nsi as follows:

Removing unused resources... Done!
Generating language tables...
Error while applying NLF font/RTL: Unicode conversion failed
Error - aborting creation process

Just above the elif line you've added to the SConstruct file there's an elif line for the gnu configuration. Either put hpux line first or remove the gnu line completely for test purpose. This assumes you already have a configuration file for hpux in SCons/Config, which you don't have. At least according to the patch.

Unicode conversion usually fails because of a missing codepage. Your iconv probably doesn't support one of the codepages used by the language files. You can have `create_code_page_string` in Source/util.cpp print out the codepages it tries to initialize to find out exactly which one is missing.

So I printed 'tools' and here is what came out:

['default', 'hplink', 'gcc', 'hpc++', 'g77', 'as', 

'ar', 'lex', 'm4', 'RCS', 'rpcgen', 'SCCS', 'tar', 'yacc', 

'zip']

I assumed then that I should have this in SConstruct:

print tools

if 'msvc' in tools or 'mstoolkit' in tools:

        envs = SConscript('SCons/Config/ms')

elif 'hpc++' in tools:

        envs = SConscript('SCons/Config/hpux')

elif 'gcc' in tools:

        envs = SConscript('SCons/Config/gnu')

else:

        envs = SConscript('SCons/Config/default')

However, it still tries to use gcc instead of /usr/bin/cc (symlink to /opt/ansic/bin/cc, the HP ANSI C compiler, as installed by HP):

/opt/aCC/bin/aCC -o build/release/makensis/clzma.o -c -mt

  +u1 -D_WIN32_IE=0x0500 Source/clzma.cpp

gcc -o build/release/makensis/crc32.o -c -mt +u1

  -D_WIN32_IE=0x0500 Source/crc32.c

gcc: +u1: No such file or directory

cc1: error: invalid option `t'

scons: *** [build/release/makensis/crc32.o] Error 1

scons: building terminated because of errors.

I know its now picking up the SCons/Config/hpux file, but I'm not sure how that file should be altered, given that scons seems to want gcc for its c compiler.

(Just FYI, I'll be leaving for the weekend, but can pick this back up on Monday ... thanks for all your help!)

Using GCC is a SCons issue which should be fixed on the SCons side. See my first bullet in 6 replies above. Loading SCons/Config/hpux only configures flags and such. It's SCons that configures the compiler paths and the default flags and search directories.

I don't have enough knowledge to know whether there is a scons bug or not, so I posted a message here:



Meanwhile, perhaps we don't have to wait. I'm attaching another try, following the pattern I think you have suggested. It is a script with some patches and its output, as well as the output of running the built makensis against the 6 MUI examples.

The script copies SCons/Config/default to SCons/Config/hpux and then patches SCons/Config/hpux so that the exact changes will be easily seen.

Here is a summmary of the counted and sorted compiler warnings:

1 "Source/build.cpp", line 488: warning #2068-D: integer conversion resulted in a change of sign
1 "Source/build.cpp", line 512: warning #2068-D: integer conversion resulted in a change of sign
1 "Source/build.cpp", line 533: warning #2068-D: integer conversion resulted in a change of sign
1 "Source/script.cpp", line 2771: warning #2186-D: pointless comparison of unsigned integer with zero
1 "Source/script.cpp", line 5838: warning #2111-D: statement is unreachable
1 "Source/util.cpp", line 583: warning #2541-D: omission of exception specification is incompatible with previous function "operator new(size_t)" (declared at line 89 of "/opt/aCC/include_std/new")
1 "Source/util.cpp", line 590: warning #2541-D: omission of exception specification is incompatible with previous function "operator delete(void *)" (declared at line 91 of "/opt/aCC/include_std/new")
1 "Source/util.cpp", line 594: warning #2541-D: omission of exception specification is incompatible with previous function "operator delete[](void *)" (declared at line 95 of "/opt/aCC/include_std/new")
1 "Source/util.cpp", line 682: warning #2186-D: pointless comparison of unsigned integer with zero
12 "Source/ResourceEditor.h", line 64: warning #3055-D: types cannot be declared in anonymous unions
12 "Source/ResourceEditor.h", line 78: warning #3055-D: types cannot be declared in anonymous unions

As it turns out, the aCC compiler is all that is needed, since it has this option:

-Ae        In aC++, invokes aCC as an ANSI-C compiler

I've found that just because aCC exists doesn't mean /opt/ansic/bin/cc does. So I've make a small change in the script to allow compiling with just aCC.