slibtoolize fails on macOS in slbt_realpath #83

New issue

Open

opened 2025-08-23 13:44:07 +00:00 by alebcay · 0 comments

alebcay commented 2025-08-23 13:44:07 +00:00

Copy link

Building and running slibtoolize 0.7.3 on a macOS system results in the following error:

$ slibtoolize
slibtoolize: error logged in slbt_st_get_stoolie_ctx(), line 95: path not found: ..
slibtoolize: < returned to > slbt_exec_stoolie(), line 565.

This was compiled on a macOS system using:

$ CFLAGS=-D_USE_EXTENDED_LOCALES_ ./configure
$ make install

(On macOS, it appears that -D_XOPEN_SOURCE=700 is not sufficient to make strftime_l available, -D_USE_EXTENDED_LOCALES_ is needed.)

I think the error in slibtoolize is due to /proc filesystem not being present in macOS, which the slbt_realpath implementation assumes is present. I confirmed I was able to work around this after adding an early return using POSIX realpath(3).

--- a/src/internal/slibtool_realpath_impl.c
+++ b/src/internal/slibtool_realpath_impl.c
@@ -58,6 +58,10 @@ slbt_hidden int slbt_realpath(
        return syscall(SYS___realpathat,fdat,path,buf,buflen,0);
 #endif

+#ifdef __APPLE__
+       return realpath(path,buf) ? 0 : -1;
+#endif
+
        /* buflen */
        if (buflen < PATH_MAX) {
                errno = ENOBUFS;

After recompiling, execution seems to work:

$ slibtoolize
slibtoolize: install: ln -s <slibtool install prefix>/share/slibtool/ltmain.sh <cwd>/ltmain.sh
slibtoolize: install: ln -s <slibtool install prefix>/share/slibtool/ar-lib <cwd>/ar-lib

The seemingly obvious (to me) fix is to use POSIX realpath when it's available, but I'm wondering if there's some reason that this would not be suitable.

Building and running slibtoolize 0.7.3 on a macOS system results in the following error: ``` $ slibtoolize slibtoolize: error logged in slbt_st_get_stoolie_ctx(), line 95: path not found: .. slibtoolize: < returned to > slbt_exec_stoolie(), line 565. ``` This was compiled on a macOS system using: ``` $ CFLAGS=-D_USE_EXTENDED_LOCALES_ ./configure $ make install ``` (On macOS, it appears that `-D_XOPEN_SOURCE=700` is not sufficient to make `strftime_l` available, `-D_USE_EXTENDED_LOCALES_` is needed.) I think the error in `slibtoolize` is due to `/proc` filesystem not being present in macOS, which the `slbt_realpath` implementation assumes is present. I confirmed I was able to work around this after adding an early return using POSIX `realpath(3)`. ``` --- a/src/internal/slibtool_realpath_impl.c +++ b/src/internal/slibtool_realpath_impl.c @@ -58,6 +58,10 @@ slbt_hidden int slbt_realpath( return syscall(SYS___realpathat,fdat,path,buf,buflen,0); #endif +#ifdef __APPLE__ + return realpath(path,buf) ? 0 : -1; +#endif + /* buflen */ if (buflen < PATH_MAX) { errno = ENOBUFS; ``` After recompiling, execution seems to work: ``` $ slibtoolize slibtoolize: install: ln -s <slibtool install prefix>/share/slibtool/ltmain.sh <cwd>/ltmain.sh slibtoolize: install: ln -s <slibtool install prefix>/share/slibtool/ar-lib <cwd>/ar-lib ``` The seemingly obvious (to me) fix is to use POSIX realpath when it's available, but I'm wondering if there's some reason that this would not be suitable.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

cross/slibtool#83

No description provided.