stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: patch for STDCXX-1051
Date Thu, 10 Mar 2011 03:04:10 GMT
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.


View raw message