This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Less kludgy way to fix PR/17369, take 2 (a month after...)
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: 29 Mar 2005 23:26:00 -0300
- Subject: Re: Less kludgy way to fix PR/17369, take 2 (a month after...)
- Organization: Red Hat Global Engineering Services Compiler Team
- References: <424925D2.8060202@lu.unisi.ch>
On Mar 29, 2005, Paolo Bonzini <paolo.bonzini@lu.unisi.ch> wrote:
> +target_modules = { module= libstdc++-v3; lib_path=.libs; raw_cxx=true; };
> +target_modules = { module= libmudflap; lib_path=.libs; };
I don't like explicit references to .libs. It's an internal
implementation detail of libtool, subject to change. In fact, if the
filesystem in use doesn't support directories named .libs, libtool
will use _libs. Could you try to find a better way to do this,
without explicitly referencing .libs, for example, use
dir/libtool --config | sed -n 's,^objdir=,,p' ? I won't block the
patch on this, because the references to .libs were there before.
Other than that, the patch looks reasonable, but I can't say I fully
understand the reasoning behind the existing implementation. If an
uberbaum --enable-shared build works, I say go ahead and check it in.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}