Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of wojciech.meyer@arm.com
 designates 94.185.240.25 as permitted sender)
From: Wojciech Meyer <Wojciech.Meyer@arm.com>
To: Martin Sebor <msebor@gmail.com>, "dev@stdcxx.apache.org"
	<dev@stdcxx.apache.org>
Date: Thu, 10 Mar 2011 09:08:14 +0000
Subject: RE: patch for STDCXX-1051
Thread-Topic: patch for STDCXX-1051
Thread-Index: Acvez9ibJHJ+gWboTcSFCyPUnr0h5AAMRnWg
Message-ID: <DEE44AFE682197449410588EB783A51408DBC929A2@BUNGLE.Emea.Arm.com>
References: <4D72B23D.3090309@gmail.com>
 <001001cbdda2$fe9b4460$fbd1cd20$@Meyer@arm.com> <4D783FAA.6020608@gmail.com>
In-Reply-To: <4D783FAA.6020608@gmail.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
MIME-Version: 1.0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

> > 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=3D$$LD_LIBRARY_PATH:. ;             =
     \
> >                    LIBPATH=3D$$LIBPATH:. ;                             =
     \
> >                    export LIBPATH LD_LIBRARY_PATH ;                    =
   \
> >                    text=3D`./$$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 con=
fidential 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.