tresemi
30th March 2007 18:41 UTC

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!!

kichik
30th March 2007 18:58 UTC

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

kichik
31st March 2007 12:58 UTC

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

tresemi
2nd April 2007 15:03 UTC

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

kichik
2nd April 2007 15:45 UTC

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.

deckrider
16th April 2007 22:50 UTC

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?

kichik
16th April 2007 23:14 UTC

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)

deckrider
17th April 2007 19:45 UTC

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

deckrider
17th April 2007 19:49 UTC

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

kichik
17th April 2007 20:05 UTC

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

deckrider
17th April 2007 20:39 UTC

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.

deckrider
19th April 2007 17:23 UTC

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.

deckrider
20th April 2007 00:27 UTC

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.

kichik
20th April 2007 10:03 UTC

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

http://gcc.gnu.org/ml/gcc/1999-10n/msg00317.html

kichik
20th April 2007 13:02 UTC

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.

deckrider
20th April 2007 14:17 UTC

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).

deckrider
20th April 2007 15:45 UTC

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.

deckrider
20th April 2007 15:58 UTC

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.

deckrider
20th April 2007 16:23 UTC

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.

deckrider
20th April 2007 17:01 UTC

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>::operator>=(const std::fpos<_StateT>
&) const [with _StateT=mbstate_t]"
function "std::fpos<_StateT>::operator>=(std::streamoff) const
[with _StateT=mbstate_t]"
operand types are: std::basic_ifstream<char,
std::char_traits<char>>::pos_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.

kichik
20th April 2007 19:28 UTC

• SCons first tries to use hpcc and hpc++ before it looks for gcc. You can see this logic its source code near the bottom of SCons/Tool/__init__.py. Since it doesn't find hpcc, something must be wrong with SCons/Tool/hpcc.py.
• Since those tools have a different set of flags and probably issues, a new NSIS build configuration must be created for them. Copy SCons/Config/default to SCons/Config/hpux and modify as needed. For the build system to use it, add the following to SConstruct.

  elif 'hpcc' in tools:
          envs = SConscript('SCons/Config/hpux')
  

• Next come the build errors. I can see three types of errors.
  1. Silly conversion issues like that assert line. 0 needs to be converted to pos_type.
  2. DWORD conversions that are actually pointer conversions. ptrdiff_t or size_t should be used instead. This includes that ConvertEndianness which has no conversion at all.
  3. DWORD not being prolery defined. If DWORD is not 32-bit on ia64 it must be fixed. If DWORD isn't 32-bit, all of the structs definitions are worthless.

deckrider
20th April 2007 20:16 UTC

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

kichik
20th April 2007 20:19 UTC

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.

deckrider
20th April 2007 21:51 UTC

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.

kichik
20th April 2007 21:59 UTC

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.

deckrider
21st April 2007 00:16 UTC

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']

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')

/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.

kichik
21st April 2007 00:19 UTC

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.

deckrider
23rd April 2007 18:03 UTC

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

http://scons.tigris.org/servlets/Rea...rs&msgNo=10713

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

deckrider
23rd April 2007 20:59 UTC

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

kichik
24th April 2007 14:29 UTC

• 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'
  

• 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.
• Currently, your hpux changes the build flags for everything built. It allows you to build makensis but not the rest. I think the best thing here would be to extract most of the mingw stuff from SCons/Config/gnu to SCons/Config/posix and use that in both SCons/Config/gnu and SCons/Config/hpux. This way, everything could be built on HP-UX and there'd be no code duplication. I think some of the flags, like -g, are also common to the two configurations. Let me know if you're up to it.

deckrider
24th April 2007 21:26 UTC

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. Hmmm...shouldn't this then be a 'global' test instead of a platform-specific test?
  
  And if so, then shouldn't the test itself never look to see what the compiler defines, but always provide the 'correct' answer to the question of whether a system was big endian or not, thus avoiding the problem if two different compilers are used, once for CC and one for CXX, that give different #defines automatically?
  
  
• Currently, your hpux changes the build flags for everything built. It allows you to build makensis but not the rest. I think the best thing here would be to extract most of the mingw stuff from SCons/Config/gnu to SCons/Config/posix and use that in both SCons/Config/gnu and SCons/Config/hpux. This way, everything could be built on HP-UX and there'd be no code duplication. I think some of the flags, like -g, are also common to the two configurations. Let me know if you're up to it.

kichik
24th April 2007 21:34 UTC

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')

deckrider
25th April 2007 19:02 UTC

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

kichik
25th April 2007 19:52 UTC

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

deckrider
27th April 2007 00:43 UTC

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.

kichik
27th April 2007 12:51 UTC

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

deckrider
30th April 2007 17:08 UTC

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?

kichik
30th April 2007 19:14 UTC

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?

deckrider
30th April 2007 19:35 UTC

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

kichik
30th April 2007 19:38 UTC

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