If I don't pass a filename to --heuristics then it looks up the directory tree for a libtool. If I pass a filename it is assumed to be absolute and the same tree recursion does not happen.
libtool
I suggest that the tree recursion should happen if the filename doesn't start with /.
/
(background: we have a patched libtool which writes the generated libtool script to $host_os-libtool to ensure the host libtool isn't used accidentally)
$host_os-libtool
Good point, we just never had a use-case like that before:-)
Implemented in b26b227bc (branch wip) -- please test and let me know whether it is ready for merging into main.
My local attempt was a little different, basically:
@@ -45,15 +45,13 @@ static int slbt_lconf_open( - if (lconf) - return ((fdlconf = openat(fdcwd,lconf,O_RDONLY,0)) < 0) - ? SLBT_CUSTOM_ERROR(dctx,SLBT_ERR_LCONF_OPEN) - : fdlconf; + if (!lconf) + lconf = "libtool"; - fdlconf = openat(fdlconfdir,"libtool",O_RDONLY,0); + fdlconf = openat(fdlconfdir,lconf,O_RDONLY,0); @@ -81,7 +79,7 @@ static int slbt_lconf_open( - fdlconf = openat(fdlconfdir,"libtool",O_RDONLY,0); + fdlconf = openat(fdlconfdir,lconf,O_RDONLY,0);
(patch trimmed for conciseness)
The main issue I have with the above is that you might end-up finding the generated script in a neighboring folder rather than in the build-tree of your own project. This means that even b26b227 is incomplete in guarding against that, as it still allows for things like "../foo/libtool" or "foo/libtool". The real check, then, shouldn't be (lconf[0] == '/'), but rather (strchr(lconf,'/')).
(lconf[0] == '/')
(strchr(lconf,'/'))
Finalized in d70e376.
Metadata Update from @midipix: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.