Build order/hard-coded binary pathname issues...

[chris@…]

Many packages end up with hard-coded names to various binaries, which has usually been solved by either switching the build order around when needed to ensure that certain programs were in specific places when they were found by other packages, or creating symlinks to some binaries. However, this is essentially a completely different issue for the sysroot book since it will be looking at program locations on the host system. In a way it simplifies things because the build order is less important, but it can also cause problems when programs on the host system that packages hard-code paths to are not in the same place on the host system as on the final CLFS system.

The most obvious way to solve this is to create symlinks on the host to any such programs, but we do want to avoid touching the host whenever possible. Does anyone else have ideas for any other potential solution?

[Joe Ciccone]

Assuming the binary is located via configure. Usualy the paths can be over-ridden by an entry in config.cache.

Eg, for patch I did the following:

echo "ac_cv_path_ed_PROGRAM=ed" > config.cache

[chris@…]

Would this cause issues if that program with the hard-coded pathname is also used in the package build process?

[chris@…]

For example, I just tried it with e2fsprogs, which hard-codes the path to the sed program in a script...I moved sed to /usr/bin temporarily and added ac_cv_path_SED=${ac_cv_path_SED=/bin/sed} to config.cache. When I tried make, it failed because it couldn't find sed. Granted, for e2fsprogs the only occurrence of hard-coding sed's path is in a bash script so it's easy to fix, but it could get more complicated with other packages...

[chris@…]

Oh duh, I guess you could just put the program name there with no specific pathname at all (which was probably the point of your example). Yeah, that should work (for any such programs that are found through the configure script anyway...).

[Joe Ciccone]

You still do have a point. It depends on how the program is being called. I did a quick grep through e2fsprogs for @SED@:

configure:15056:s,@SED@,$SED,;t t
lib/ss/mk_cmds.sh.in:8:SED=@SED@
MCONFIG.in:54:SED = @SED@
util/subst.conf.in:2:SED                        @SED@

It would depend on how the command is executed in the source. It looks like e2fsprogs does not hard-code the path in a binary but it might still need a full path to execute it. I'd have to look deeper into the code.

lets say the command is being executed with execl. Then it would have to have a full path. But execlp will search your PATH for the binary. The default PATH for execlp is ':/bin:/usr/bin', but do we really want to rely on just that if PATH isn't set properly?