stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wojciech Meyer <Wojciech.Me...@arm.com>
Subject RE: patch for STDCXX-1051
Date Thu, 10 Mar 2011 09:08:14 GMT
> > 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.

Ouch, no good.

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

Yes indeed, I thought the same, maybe we should set up this flag.
I raised that to the linker person, and he said that it would be an
enhancement to actually provide a command-line switch to support it.
For time being please commit your version of the patch, and I will stick
with the wrapper script.

I will send another (bigger) patch soon. Thanks.

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

I will try to figure out this as well.

> Martin

Thanks,
Wojciech

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may
also be privileged. If you are not the intended recipient, please notify the sender immediately
and do not disclose the contents to any other person, use it for any purpose, or store or
copy the information in any medium.  Thank you.


Mime
View raw message