Opened 16 years ago

Last modified 12 years ago

#102 new task

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

Reported by: chris@… Owned by: clfs-commits@…
Priority: major Milestone: CLFS Sysroot 1.0.0
Component: BOOK Version: CLFS Sysroot GIT
Keywords: Cc:


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?

Change History (7)

comment:1 Changed 16 years ago by 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

comment:2 Changed 16 years ago by chris@…

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

comment:3 Changed 16 years ago by 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...

comment:4 Changed 16 years ago by 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...).

comment:5 Changed 16 years ago by 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/ = @SED@
util/                        @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?

comment:6 Changed 16 years ago by Joe Ciccone

Milestone: CLFS Sysroot 1.0.0

comment:7 Changed 12 years ago by Joe Ciccone

Version: CLFS Sysroot 1.0.0CLFS Sysroot GIT
Note: See TracTickets for help on using tickets.