On 03/08/2011 08:10 AM, Wojciech Meyer wrote:
2) Removed the changes to the link and compile_then_link functions. Because of the comments within them these were effectively commented out and had no effect. I also don't understand why the chmod +x command is necessary. The linker should set the executable bit after a successful link. There is one linker (HP) that fails (or used to) to delete the output file on failure (maybe when when it crashes). With that linker the only way to tell that the file is bad (other than the exit status of the linker) is by examining the executable bit.I don't remember why I did this, but I remember it was something that I needed to do, probably it was related somewhat to cross-compilation.Now I know! The reason behind it, is that our linker which performs linking *does not* setup executable flag on the destination file. It's an image which should not be executed directly anyway. Now, it would be all fine besides that stdcxx build system checks for this flag here (..) etc/config/GNUmakefile.cfg:247: elif [ ! -x $$file ] ; then \ nm -gp $$file.o 2>&1 | grep "T *main *$$">/dev/null ; \ test -f $$file.o -a ! $$? -eq 0 ; \ else \ echo "./$$file">>$(LOGFILE) ; \ LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:. ; \ LIBPATH=$$LIBPATH:. ; \ export LIBPATH LD_LIBRARY_PATH ; \ text=`./$$file` ; \ fi; \ (..) So, I needed to do it manually to ensure it does search for that. Using this shell trickery everything seems to work fine. Let me know your thoughts.
The change would cause problems for the HP linker. We don't want to break one build to make another work. One way you could work around it is by writing a wrapper script for your linker and setting the executable bit in it. From a design POV, since your linker behaves in an "unusual" way (i.e., different than all the linkers stdcxx usually targets), I would prefer to avoid changing the configuration machinery this way. But if you can come up with a "clean" solution that improves the machinery for all linkers I would certainly support it. Martin
