Bruce Dubbs wrote these words on 08/17/05 16:18 CST:
> Randy McMurchy quoted from the Bash man page:
>> "Command substitutions may be nested. To nest when using the
>> backquoted form, escape the inner backquotes with backslashes."
>
> Can you say *ugly*. :)
I know, I know
I debated e
Randy McMurchy wrote:
> Matthew Burgess wrote these words on 08/17/05 14:33 CST:
>
>
>> Unfortunately, one can't nest backticks,
>
>
> I'm not so sure about that. From the Bash man page:
>
> "Command substitutions may be nested. To nest when using the
> backquoted form, escape the inner
Randy McMurchy wrote:
Matthew Burgess wrote these words on 08/17/05 14:33 CST:
Unfortunately, one can't nest backticks,
I'm not so sure about that. From the Bash man page:
"Command substitutions may be nested. To nest when using the
backquoted form, escape the inner backquotes with ba
Matthew Burgess wrote these words on 08/17/05 14:33 CST:
> Unfortunately, one can't nest backticks,
I'm not so sure about that. From the Bash man page:
"Command substitutions may be nested. To nest when using the
backquoted form, escape the inner backquotes with backslashes."
--
Randy
On 8/17/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Basically it's because, purely through habit, I only ever use backticks.
> Unfortunately, one can't nest backticks, so I came up with the mixture
> of backticks and $(). Oh, plus the fact that in my makefile based
> scripts the '$' needs e
Mike Hernandez wrote:
This stuff is all over my head but I'm just wondering why you would
mix backticks and $(). Why not just use: echo $(dirname $(gcc
-print-file-name=libgcc.a))/specs ?
Basically it's because, purely through habit, I only ever use backticks.
Unfortunately, one can't nest b
Matthew Burgess wrote:
> The only question that remains
> is: Is the 'specs' file guaranteed to be searched for in the same dir as
> libgcc?
IMHO yes.
Don't forget, the sanity check is there for a purpose. It will detect any
cockups in this regard.
Regards
Greg
--
http://www.diy-linux.org/
-
Matthew Burgess wrote:
> Greg Schafer wrote:
>
>> The documented switch is:
>>
>> -print-file-name=
>>
>> However, the docs say it is only for "library", but it appears to work for
>> any file or dir within GCC's private dir eg: specs, startfiles,
>
> Doesn't appear to do what we need it to
Matthew Burgess wrote:
> Therefore, in order to change GCC's default specs file, I still think we
> need to 1) dump them (as gcc-4.x no longer installs a specs file) 2)
> change the relevant specs and 3) Place the updated specs file in
> whatever directory GCC searches for its default specs in.
On 8/16/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Matthew Burgess wrote:
>
> > # echo `dirname $(gcc -print-file-name=libgcc.a)`/specs
>
> That can actually be shortened down to:
>
> SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs
>
This stuff is all over my head but I'm just won
Matthew Burgess wrote:
# echo `dirname $(gcc -print-file-name=libgcc.a)`/specs
That can actually be shortened down to:
SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs
That's 20 characters less to type (compared to the current command in
gcc4), and a much simpler command too. The on
Greg Schafer wrote:
The documented switch is:
-print-file-name=
However, the docs say it is only for "library", but it appears to work for
any file or dir within GCC's private dir eg: specs, startfiles,
Doesn't appear to do what we need it to do though. In as much as if the
specs file is
steve crosby wrote:
gcc -dumpspecs | sed -e 's@ /lib/ld-linux.so.2@
/tools/lib/[EMAIL PROTECTED]' > tempfile
gcc -specs=tempfile
I'm not sure that does what you think it does. If I'm reading the
manual[1] correctly, the -specs flag is a runtime option to control what
specs the compiler u
Matthew Burgess wrote:
> Now, if we can simplify gcc4's SPECFILE assignment, that's great.
Um, the suggestion was to use the correctly documented switch, not to go
and completely redo the specs handling :-) Of course, you can do that if
you want to. I've done exactly that for the DIY build ie: d
On 8/16/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Matthew Burgess wrote:
>
> > GCC-3.x appears to support -dumpspecs
>
> Obviously (now I've read the two books!), that won't tell us where the
> specs file lives, which is what we need to know! For a clearer
Why do we need to know? we can
Matthew Burgess wrote:
GCC-3.x appears to support -dumpspecs
Obviously (now I've read the two books!), that won't tell us where the
specs file lives, which is what we need to know! For a clearer
comparison of the two books, here's the relevant snippets:
gcc4:
SPECFILE=`gcc -print-search-
Greg Schafer wrote:
Hi
During the toolchain adjustments, LFS does stuff like this:
gcc --print-file specs
IMHO the usage is bogus because:
1) `--print-file' is undocumented (therefore could break anytime)
2) `--print-file' only works by pure good fortune.
GCC-3.x appears to support -
On 8/15/05, Greg Schafer <[EMAIL PROTECTED]> wrote:
> 1) `--print-file' is undocumented (therefore could break anytime)
fair enough: suggested changes are:
Chapter 5
gcc -dumpspecs | sed -e 's@ /lib/ld-linux.so.2@
/tools/lib/[EMAIL PROTECTED]' > tempfile
gcc -specs=tempfile
rm tempfile
Ch
18 matches
Mail list logo
