Chapter 5 - GCC Pass 2 - changing dynamic linker location

[gerard@…]

Current method:

for file in \

$(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)

do

This can probably be much simplified and shortened by using:

for file in gcc/config/linux64.h gcc/config/linux.h gcc/config/sysv4.h; do ... done

I think that construct is easier to understand. Using the find command seems overkill here to specify a mere three files in sequence.

[gerard@…]

Invalid. Seehttp://linuxfromscratch.org/pipermail/lfs-dev/2009-May/062812.html thread

In particular: ​http://linuxfromscratch.org/pipermail/lfs-dev/2009-May/062815.html

[DJ Lucas]

I'd like to make one last chance argument simply for clarity's sake. I'd have posted to -dev, but I can't right now because my smart host is rewriting the from address (which will be fixed tomorrow evening).

Upon reading Gerard's post, without extracting the gcc source and actually looking at the problem, I had also expected to find 3 files. The alternate below would have made it more clear, to me at least, at first glance.

Here is the original against a diff of the new:

[dj@name25 gcc-4.4.0]# for file in \
>     $(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)
> do
>     ls $file
> done | sort > testfile1
[dj@name25 gcc-4.4.0]# for file in gcc/config/{linux.h,*/{linux{,64},sysv4}.h}
> do
>     ls $file
> done | sort > testfile2
[dj@name25 gcc-4.4.0]# diff -au testfile1 testfile2
[dj@name25 gcc-4.4.0]# 

The commands produce the same output, but the second, while more complex, avoids a repeat of the original suggestion by being more explicit. It's not worth arguing too much over, but I though I'd throw this out there for reconsideration, especially seeing that two of us made the exact same assumption based on the current commands. I know that I've been doing this for far too long to even begin to imagine what a first time LFS'er sees and interprets, but I do know that I immediately said 'Oh yeah, that is better' when reading the Gerard's suggestion. That makes me wonder how much thought a first timer puts into the commands as they are in the book, when I myself made a similar assumption. Reopening, but please close it if y'all don't think it's worth changing.

[Bryan Kadzban]

That's odd. Upon reading Gerard's initial bug post, my first thought was "uh, if those files are in subdirectories, this won't catch them..."

:-)

As for explicitly specifying files, versus using find: If someone ever adds another level of directories, and we want to modify these files inside those directories, then find will continue to work. The explicit file list will start to fail. Now, the likelihood of this is probably pretty low, so I don't care all that much one way or the other, but it's there. :-)

(But then, I'd be a fan of "find /blah -name blah -exec sed whatever {} +" for stuff like this...)

[gerard@…]

Thanks DJ & Bryan.

Bryan raised a good point about possible additional sub-directories in the future. The current method would have a better chance at continuing to work.

DJ: your suggestion, while it would work, also is less readable. It's a good construct to use in scripting but in the spirit of the readability effort for the book, it's not as desirable.

I'm going to close it again. I think all the points of view have been covered. Of the possible ways of doing it, the current method in the book is still the best overall.

[DJ Lucas]

Replying to bryan@…:

That's odd. Upon reading Gerard's initial bug post, my first thought was "uh, if those files are in subdirectories, this won't catch them..."

Guess lack of activity has left me rusty then. :-)