Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ksh cannot be successfully built with macOS Command Line Tools 14.2 #596

Closed
posguy99 opened this issue Jan 10, 2023 · 46 comments
Closed

ksh cannot be successfully built with macOS Command Line Tools 14.2 #596

posguy99 opened this issue Jan 10, 2023 · 46 comments
Labels
buildfail Does not compile

Comments

@posguy99
Copy link

posguy99 commented Jan 10, 2023

Fails with the below even on a clean checkout. macOS 12.6.2 (not 12.6.1), on Intel and M1.

+ mamake -C cmd/builtin install
+ iffe -v -c 'cc  -Os ' ref -I/Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/include/ast -I/Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/include /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libast.a -liconv /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libcmd.a -lmd -lutil /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libast.a -liconv -liconv : run /Users/mwilson/src/ksh-test/ksh/src/cmd/builtin/features/pty
iffe: test: is sys/types.h a header ... yes
iffe: test: is -liconv a library ... yes
iffe: test: is /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libast.a a library ... yes
iffe: test: is -lutil a library ... yes
iffe: test: is -lmd a library ... yes
iffe: test: is /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libcmd.a a library ... yes
iffe: test: is pty.h a header ... no
iffe: test: is libutil.h a header ... no
iffe: test: is sys/pty.h a header ... no
iffe: test: is sys/ptyio.h a header ... no
iffe: test: is sys/vty.h a header ... no
iffe: test: is sys/ioctl.h a header ... yes
iffe: test: is stropts.h a header ... no
iffe: test: is openpty a library function ... yes
iffe: test: is _getpty a library function ... no
iffe: test: is ptsname a library function ... yes
iffe: test: is stdlib.h a header ... yes
iffe: test: is grantpt a library function ... yes
iffe: test: is unlockpt a library function ... yes
iffe: test: is posix_openpt a library function ... yes
iffe: test: is termios.h a header ... yes
iffe: test: is cfmakeraw a library function ... yes
iffe: test: is -lm a library ... yes
iffe: test: output{ ... }end ... 
iffe: test: output{ ... }end ... 
iffe: Output block failed to compile. Export IFFEFLAGS=-d1 to debug.
mamake [cmd/builtin]: *** exit code 1 making FEATURE/pty
mamake: *** exit code 1 making cmd/builtin
mamake: *** exit code 1 making all
package: make failed at Mon Jan  9 19:36:06 PST 2023 in /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64
[729] mbp13 $ 

With IFFEFLAGS=-d1

+ mamake -C cmd/builtin install
+ iffe -d1 -v -c 'cc  -Os ' ref -I/Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/include/ast -I/Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/include /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libast.a -liconv /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libcmd.a -lmd -lutil /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libast.a -liconv -liconv : run /Users/mwilson/src/ksh-test/ksh/src/cmd/builtin/features/pty
./20560.c:1:2: error: expected identifier or '('
(;
 ^
./20560.c:1:2: error: expected ')'
./20560.c:1:1: note: to match this '('
(;
^
2 errors generated.
iffe: test: is sys/types.h a header ...
iffe: ... yes
iffe: test: is -liconv a library ...
iffe: ... yes
iffe: test: is /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libast.a a library ...
iffe: ... yes
iffe: test: is -lutil a library ...
iffe: ... yes
iffe: test: is -lmd a library ...
iffe: ... yes
iffe: test: is /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libcmd.a a library ...
iffe: ... yes
iffe: test: is pty.h a header ...
iffe: ... no
iffe: test: is libutil.h a header ...
iffe: ... no
iffe: test: is sys/pty.h a header ...
iffe: ... no
iffe: test: is sys/ptyio.h a header ...
iffe: ... no
iffe: test: is sys/vty.h a header ...
iffe: ... no
iffe: test: is sys/ioctl.h a header ...
iffe: ... yes
iffe: test: is stropts.h a header ...
iffe: ... no
./20560.c:31:46: warning: cast to smaller integer type 'unsigned int' from 'char *' [-Wpointer-to-int-cast]
int main(){char* i = (char*)&FoobaR; return ((unsigned int)i)^0xaaaa;}
                                             ^~~~~~~~~~~~~~~
1 warning generated.
Undefined symbols for architecture arm64:
  "_FoobaR", referenced from:
      _main in 20560-e9ecd6.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
iffe: test: is openpty a library function ...
./20560.c:39:31: error: use of undeclared identifier 'openpty'
static _IFFE_fun i=(_IFFE_fun)openpty;int main(){return ((unsigned int)i)^0xaaaa;}
                              ^
./20560.c:39:58: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)openpty;int main(){return ((unsigned int)i)^0xaaaa;}
                                                         ^~~~~~~~~~~~~~~
1 warning and 1 error generated.
./20560.c:39:58: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)openpty;int main(){return ((unsigned int)i)^0xaaaa;}
                                                         ^~~~~~~~~~~~~~~
1 warning generated.
iffe: ... yes
iffe: test: is _getpty a library function ...
./20560.c:40:31: error: use of undeclared identifier '_getpty'
static _IFFE_fun i=(_IFFE_fun)_getpty;int main(){return ((unsigned int)i)^0xaaaa;}
                              ^
./20560.c:40:58: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)_getpty;int main(){return ((unsigned int)i)^0xaaaa;}
                                                         ^~~~~~~~~~~~~~~
1 warning and 1 error generated.
./20560.c:40:58: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)_getpty;int main(){return ((unsigned int)i)^0xaaaa;}
                                                         ^~~~~~~~~~~~~~~
1 warning generated.
Undefined symbols for architecture arm64:
  "__getpty", referenced from:
      _main in 20560.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
iffe: ... no
iffe: test: is ptsname a library function ...
./20560.c:40:58: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)ptsname;int main(){return ((unsigned int)i)^0xaaaa;}
                                                         ^~~~~~~~~~~~~~~
1 warning generated.
iffe: ... yes
iffe: test: is stdlib.h a header ...
iffe: ... yes
iffe: test: is grantpt a library function ...
./20560.c:43:58: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)grantpt;int main(){return ((unsigned int)i)^0xaaaa;}
                                                         ^~~~~~~~~~~~~~~
1 warning generated.
iffe: ... yes
iffe: test: is unlockpt a library function ...
./20560.c:44:59: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)unlockpt;int main(){return ((unsigned int)i)^0xaaaa;}
                                                          ^~~~~~~~~~~~~~~
1 warning generated.
iffe: ... yes
iffe: test: is posix_openpt a library function ...
./20560.c:45:63: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)posix_openpt;int main(){return ((unsigned int)i)^0xaaaa;}
                                                              ^~~~~~~~~~~~~~~
1 warning generated.
iffe: ... yes
iffe: test: is termios.h a header ...
iffe: ... yes
iffe: test: is cfmakeraw a library function ...
./20560.c:47:60: warning: cast to smaller integer type 'unsigned int' from '_IFFE_fun' (aka 'int (*)()') [-Wpointer-to-int-cast]
static _IFFE_fun i=(_IFFE_fun)cfmakeraw;int main(){return ((unsigned int)i)^0xaaaa;}
                                                           ^~~~~~~~~~~~~~~
1 warning generated.
iffe: ... yes
iffe: test: is -lm a library ...
iffe: ... yes
iffe: test: output{ ... }end ...
dyld[20744]: Library not loaded: '/usr/lib/libmd.dylib'
  Referenced from: '/Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/src/cmd/builtin/20560.exe'
  Reason: tried: '/usr/lib/libmd.dylib' (no such file), '/usr/local/lib/libmd.dylib' (no such file)
iffe: line 496: 20744: Abort
iffe: ... 
iffe: test: output{ ... }end ...
dyld[20758]: Library not loaded: '/usr/lib/libmd.dylib'
  Referenced from: '/Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/src/cmd/builtin/20560.exe'
  Reason: tried: '/usr/lib/libmd.dylib' (no such file), '/usr/local/lib/libmd.dylib' (no such file)
iffe: line 496: 20758: Abort
iffe: ... 
iffe: Output block failed to compile. Export IFFEFLAGS=-d1 to debug.
mamake [cmd/builtin]: *** exit code 1 making FEATURE/pty
mamake: *** exit code 1 making cmd/builtin
mamake: *** exit code 1 making all
package: make failed at Mon Jan  9 19:39:17 PST 2023 in /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64

[731] mbp13 $ 
@posguy99
Copy link
Author

posguy99 commented Jan 10, 2023

Something is definitely weird here, I can't build @4ec93745 either, but that's the commit that's RUNNING right now...

$ echo $KSH_VERSION
Version AJM 93u+m/1.1.0-alpha+4ec93745 2022-10-31

@posguy99
Copy link
Author

Ok, is #567 related?

@posguy99
Copy link
Author

The compiler works, I can build other non-trivial things, like qemacs. Xcode has never been on this laptop, only the CLT, but I reinstalled the CLT anyway with no change.

@McDutchie
Copy link

Cannot reproduce. Everything builds correctly on my end.

I have no idea what /usr/local/lib/libmd.dylib is or why your system wants to load it, but this looks like some sort of local system configuration problem to me.

Do you have Homebrew installed by any chance?

@posguy99
Copy link
Author

Homebrew? Ugh. No. Definitely not.

I do have MacPorts, but I've always had MacPorts.

@posguy99
Copy link
Author

I had not tried to build u+m on 12.6.2 before opening this ticket. The last time I built u+m was 10/31, which would have been on 12.6.1 or maybe 12.6, I don't remember exactly when I installed 12.6.1. There's been some churn on the M1 machine, but other than installing OS updates and re-running xcode-select --install, the Intel machine has been static.

@posguy99
Copy link
Author

posguy99 commented Jan 11, 2023

The iffe invocation calls for libmd, what builds that line?

  • iffe -v -c 'cc -Os ' ref -I/Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/include/ast -I/Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/include /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libast.a -liconv /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libcmd.a -lmd -lutil /Users/mwilson/src/ksh-test/ksh/arch/darwin.arm64-64/lib/libast.a -liconv -liconv : run /Users/mwilson/src/ksh-test/ksh/src/cmd/builtin/features/pty

@posguy99
Copy link
Author

posguy99 commented Jan 15, 2023

When compiling on Debian Linux, the iffe invocation for mamake -C cmd/builtin install does not include -lmd. What is triggering package to include that in the invocation?

I can spin up an Intel macOS VM, but I don't have an easy way to spin up an arm64 VM for testing.

@posguy99
Copy link
Author

The iffe invocation for mamake -C lib/libsum install detects libmd as being present on macOS and not present on Debian Linux, despite it not being present on either one.

How does one get iffe to show the details of the test it is running to determine whether the library is present? Obviously there's something about the current state of macOS on both my macOS machines that make the test incorrectly report presence.

@posguy99
Copy link
Author

posguy99 commented Jan 15, 2023

I have no idea what /usr/local/lib/libmd.dylib is or why your system wants to load it, but this looks like some sort of local system configuration problem to me.

libmd is message digest functions from https://www.hadrons.org/software/libmd/

EDIT: BSD message digest functions, is that why macOS thinks it's there?

@hyenias
Copy link

hyenias commented Jan 15, 2023

FYI, I successfully compiled and tested current HEAD on all of my ARM based Unix boxes without any errors which include Debian, Ubuntu, and FreeBSD. I also tested my macOS 10.13.6 x86_64 laptop as well with success. Sorry, I just do not have an Apple M1 to test with.

@posguy99
Copy link
Author

posguy99 commented Jan 15, 2023

@hyenias If you would, could you check a representative sampling of them and see how many of them (if any of them) have an affirmative detection for libmd (search for -lmd in make.out)?

Thanks.

EDIT: You may have to set IFFEFLAGS to -d1 or -d2 in order to see the test.

@hyenias
Copy link

hyenias commented Jan 16, 2023

Since your referenced library libmd is for BSD systems, I checked my two BSD type systems. I did not have to include IFFEFLAGS=-d1 in my environment to see the test. The test first appears for the libsum library right after the main libast library is built using standard compile command bin/package make. See below for results for test line -lmd a library string. Intel macOS does not detect the library but FreeBSD does.

macOS Intel 10.13.6:

+ mamake -C lib/libsum install
+ iffe -v -c 'cc -fPIC -Os ' ref -I/tmp/git/ksh93/ksh/arch/darwin.i386-64/include/ast -I/tmp/git/ksh93/ksh/arch/darwin.i386-64/include /tmp/git/ksh93/ksh/arch/darwin.i386-64/lib/libast.a -liconv : run /tmp/git/ksh93/ksh/src/lib/libsum/features/sum
iffe: test: is sys/types.h a header ... yes
iffe: test: is -liconv a library ... yes
iffe: test: is /tmp/git/ksh93/ksh/arch/darwin.i386-64/lib/libast.a a library ... yes
iffe: test: is md4.h a header ... no
iffe: test: is -lmd a library ... no
iffe: test: is MD4Init a library function ... no
iffe: test: is md5.h a header ... no
iffe: test: is MD5Init a library function ... no
iffe: test: is sha1.h a header ... no
iffe: test: is SHA1Init a library function ... no
iffe: test: is sha2.h a header ... no
iffe: test: is SHA2Init a library function ... no
+ cc -fPIC -Os -I. -I/tmp/git/ksh93/ksh/src/lib/libsum -I/tmp/git/ksh93/ksh/arch/darwin.i386-64/include/ast -D_PACKAGE_ast -c /tmp/git/ksh93/ksh/src/lib/libsum/sumlib.c

FreeBSD 13.1 arm64:

+ mamake -C lib/libsum install
+ iffe -v -c 'cc -fPIC -Os ' ref -L/tmp/ksh/arch/freebsd13.arm64-64/lib -I/tmp/ksh/arch/freebsd13.arm64-64/include/ast -I/tmp/ksh/arch/freebsd13.arm64-64/include /tmp/ksh/arch/freebsd13.arm64-64/lib/libast.a -lm : run /tmp/ksh/src/lib/libsum/features/sum
iffe: test: is sys/types.h a header ... yes
iffe: test: is -lm a library ... yes
iffe: test: is /tmp/ksh/arch/freebsd13.arm64-64/lib/libast.a a library ... yes
iffe: test: is md4.h a header ... yes
iffe: test: is -lmd a library ... yes
iffe: test: is MD4Init a library function ... yes
iffe: test: is md5.h a header ... yes
iffe: test: is MD5Init a library function ... yes
iffe: test: is sha1.h a header ... no
iffe: test: is SHA1Init a library function ... no
iffe: test: is sha2.h a header ... no
iffe: test: is SHA2Init a library function ... no
+ cc -fPIC -Os -I. -I/tmp/ksh/src/lib/libsum -I/tmp/ksh/arch/freebsd13.arm64-64/include/ast -D_PACKAGE_ast -c /tmp/ksh/src/lib/libsum/sumlib.c

@posguy99
Copy link
Author

Since your referenced library libmd is for BSD systems, I checked my two BSD type systems. I did not have to include IFFEFLAGS=-d1 in my environment to see the test. The test only exists for the libsum library right after the main libast library is built using standard compile command bin/package make.

I see that one of yours tests for it and apparently doesn't find it, and the other tests for it and finds it.

On macOS here, it tests for it twice, and apparently finds it twice despite it not being there, which causes the failure when it tries to link against it. I didn't think iffe learned (meaning that the libsum test would condition the later test) but maybe it does.

If you use IFFEFLAGS=-d2 bin/package make, what is the actual test it performs at libsum ?

@hyenias
Copy link

hyenias commented Jan 16, 2023

That was a harder file to read. Here you go for what it is worth because it does not make any sense to me.

+ [1.329967s|P63611,S0,bin/iffe,L1,e0] _hdr_md4=1
+ [1.330128s|P63611,S0,bin/iffe,L2476,e0] hdr=' md4.h'
+ [1.330328s|P63611,S0,bin/iffe,L2484,e0] z=''
+ [1.330500s|P63611,S0,bin/iffe,L2486,e0] z='-lmd '
+ [1.330657s|P63611,S0,bin/iffe,L2488,e0] lib=''
+ [1.330785s|P63611,S0,bin/iffe,L2489,e0] p=''
+ [1.330922s|P63611,S0,bin/iffe,L2490,e0] hit=0
+ [1.331054s|P63611,S0,bin/iffe,L2491,e0] echo 'int main(){return(0);}'
+ [1.331184s|P63611,S0,bin/iffe,L2491,e0] 1> ./63611.c
+ [1.331619s|P63611,S0,bin/iffe,L2493,e0] p=-lmd
+ [1.332028s|P63611,S0,bin/iffe,L2503,e0] rm -f ./63611.exe
+ [1.337502s|P63611,S0,bin/iffe,L2504,e0] is LIB -lmd
+ [1.337800s|P63611,S0,bin/iffe,is,L189,e0] oo=LIB
+ [1.338001s|P63611,S0,bin/iffe,is,L190,e0] shift
+ [1.338151s|P63611,S0,bin/iffe,is,L192,e0] yy=is
+ [1.338299s|P63611,S0,bin/iffe,is,L193,e0] ii=-lmd
+ [1.338445s|P63611,S0,bin/iffe,is,L194,e0] complete=1
+ [1.338619s|P63611,S0,bin/iffe,is,L206,e0] mm='a library'
+ [1.338868s|P63611,S0,bin/iffe,is,L230,e0] show_test is -lmd a library
+ [1.339016s|P63611,S0,bin/iffe,show_test,L180,e0] 1>& 6
+ [1.339277s|P63611,S0,bin/iffe,show_test,L174,e0] print -n - 'iffe: test: is -lmd a library ...'
iffe: test: is -lmd a library ...+ [1.339522s|P63611,S0,bin/iffe,show_test,L179,e0] echo

+ [1.339694s|P63611,S0,bin/iffe,is,L231,e0] complete=1
+ [1.339887s|P63611,S0,bin/iffe,L2505,e0] compile cc -fPIC -Os -L/tmp/ksh/arch/freebsd13.arm64-64/lib -I/tmp/ksh/arch/free>
+ [1.340057s|P63611,S0,bin/iffe,L2505,e0] 0<& 7 1>& 8
+ [1.340389s|P63611,S0,bin/iffe,compile,L40,e0] cc -fPIC -Os -L/tmp/ksh/arch/freebsd13.arm64-64/lib -I/tmp/ksh/arch/freebs>
+ [1.340682s|P63611,S0,bin/iffe,compile,L40,e0] 2> ./63611.err
+ [1.625195s|P63611,S0,bin/iffe,compile,L41,e0] _compile_status=0
+ [1.625517s|P63611,S0,bin/iffe,compile,L42,e0] test -s ./63611.err
+ [1.625712s|P63611,S0,bin/iffe,compile,L45,e0] test 0 -gt 128
+ [1.625854s|P63611,S0,bin/iffe,compile,L56,e0] return 0
+ [1.626101s|P63611,S0,bin/iffe,L2506,e0] success
+ [1.626369s|P63611,S0,bin/iffe,success,L257,e0] complete=0
+ [1.626551s|P63611,S0,bin/iffe,success,L259,e0] mm=yes
+ [1.626744s|P63611,S0,bin/iffe,success,L264,e0] echo 'iffe: ... yes'
+ [1.626890s|P63611,S0,bin/iffe,success,L264,e0] 1>& 6
iffe: ... yes
+ [1.627172s|P63611,S0,bin/iffe,L2507,e0] gotlib=' + -lm + /tmp/ksh/arch/freebsd13.arm64-64/lib/libast.a + -lmd'
+ [1.627354s|P63611,S0,bin/iffe,L2508,e0] lib='-lmd '
+ [1.627511s|P63611,S0,bin/iffe,L2509,e0] e=0
+ [1.627745s|P63611,S0,bin/iffe,L2543,e0] y=''
+ [1.628077s|P63611,S0,bin/iffe,L2545,e0] c=md
+ [1.628448s|P63611,S0,bin/iffe,L2584,e0] y=_md
+ [1.628684s|P63611,S0,bin/iffe,L2587,e0] c=_LIB_md
+ [1.628955s|P63611,S0,bin/iffe,L2592,e0] q='a library'
+ [1.629185s|P63611,S0,bin/iffe,L2595,e0] can=$'#define _hdr_md4\t1\t/* #include <md4.h> ok */\n#define _LIB_md\t1\t/* -lm>
+ [1.629458s|P63611,S0,bin/iffe,L2596,e0] nan=_hdr_md4=$'1\n_LIB_md=1'
+ [1.629675s|P63611,S0,bin/iffe,L2597,e0] cansep=$'\n'
+ [1.629893s|P63611,S0,bin/iffe,L2598,e0] eval _LIB_md=1
+ [1.630192s|P63611,S0,bin/iffe,L1,e0] _LIB_md=1
+ [1.630388s|P63611,S0,bin/iffe,L2616,e0] p=''
+ [1.630671s|P63611,S0,bin/iffe,L2631,e0] IFS=' ,'
+ [1.630867s|P63611,S0,bin/iffe,L2632,e0] eval op='"lib"'

...

+ [1.638919s|P63611,S0,bin/iffe,L3053,e0] c=md
+ [1.639200s|P63611,S0,bin/iffe,L3060,e0] c=_LIB_md
+ [1.639520s|P63611,S0,bin/iffe,L3072,e0] putlib=' _LIB_ast _LIB_m _LIB_md'
+ [1.639736s|P63611,S0,bin/iffe,L3073,e0] usr=$'\n#define _LIB_ast 1\n#define _LIB_m 1\n#define _hdr_md4 1\n#define _LIB_md 1'
  • [1.398108s|P64229,S0,bin/iffe,show_test,L174,e0] print -n - 'iffe: test: is -lmd a library ...'
    iffe: test: is -lmd a library ...+ [1.398299s|P64229,S0,bin/iffe,show_test,L179,e0] echo

@posguy99
Copy link
Author

posguy99 commented Jan 20, 2023

On a brand new macOS 12.4 VM with no other software than the CLT installed:

CLT 13.4.0.0.1.1651278267 builds current HEAD successfully.
CLT 14.2.0.0.1.1668646533 does NOT build current HEAD successfully. It fails with the libmd error. I believe the presence detection for the library is in error, possibly facilitated by some bug in the compiler.

Compiling on the same VM, CLT 13.4 correctly determines that libmd is NOT present (iffe reports it is not a library), while CLT 14.2 reports that it is.

CLT 13.4 fails the link step in the iffe test when the cc invocation includes -lmd in both the libsum and pty tests and iffe marks that as not present at that point.

CLT 14.2 succeeds in the link step when including -lmd for both tests, but fails when you try to actually execute the result, producing the libmd.dylib error. It's not just ignoring errors, if you pass -lgarbage to the compiler, it correctly reports that it can't find garbage at link time. Perhaps some stub somewhere that fools the linker?

The libsum test does not try to execute the compiled binary from the iffe check, so there is no error reported, but the pty test does attempt to execute the compiled binary, producing the error and the abort of the build.

@pghvlaans Do you know what compiler was producing the error in #567 ?

Edit... all tests performed on M1Pro MacBookPro.

Edit2... CLT 13.4 doesn't actually perform the second test at pty at all, since the first one at libsum fails.

@posguy99
Copy link
Author

I removed CLT 14.2 from both of my production Mac and reinstalled 13.4, and HEAD builds without error on both without any other changes.

@posguy99 posguy99 changed the title Compile fails, HEAD @5c364ad2 ksh cannot be successfully built with macOS Command Line Tools 14.2 Jan 20, 2023
@McDutchie McDutchie added the buildfail Does not compile label Jan 26, 2023
@posguy99
Copy link
Author

@McDutchie Here are regular make.out and IFFEFLAGS=-d2 make.out for CLT 13.4 and 14.2.

make-out-134.tar.gz
make-out-142.tar.gz

@McDutchie
Copy link

Thanks. I'll try to get to this as soon as I can. Life has been getting in the way. :/

@tvalenta
Copy link

On my M1 with macOS 13 and CTL 14.2, I have /Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk/usr/lib/libmd.tbd with contents

--- !tapi-tbd
tbd-version:     4
targets:         [ x86_64-macos, arm64-macos, arm64e-macos ]
uuids:
  - target:          x86_64-macos
    value:           AA230746-02E1-332C-AC04-7D97C3965D58
  - target:          arm64-macos
    value:           00000000-0000-0000-0000-000000000000
  - target:          arm64e-macos
    value:           6D78CA2E-4C35-35B1-9DBD-149E050E9097
install-name:    '/usr/lib/libmd.dylib'
exports:
  - targets:         [ x86_64-macos, arm64-macos, arm64e-macos ]
    symbols:         [ _MD4Data, _MD4End, _MD4Fd, _MD4FdChunk, _MD4File, _MD4FileChunk,
                       _MD5Data, _MD5End, _MD5Fd, _MD5FdChunk, _MD5File, _MD5FileChunk,
                       _SHA1_Data, _SHA1_End, _SHA1_Fd, _SHA1_FdChunk, _SHA1_File,
                       _SHA1_FileChunk, _SHA224_Data, _SHA224_End, _SHA224_Fd, _SHA224_FdChunk,
                       _SHA224_File, _SHA224_FileChunk, _SHA256_Data, _SHA256_End,
                       _SHA256_Fd, _SHA256_FdChunk, _SHA256_File, _SHA256_FileChunk,
                       _SHA384_Data, _SHA384_End, _SHA384_Fd, _SHA384_FdChunk, _SHA384_File,
                       _SHA384_FileChunk, _SHA512_Data, _SHA512_End, _SHA512_Fd,
                       _SHA512_FdChunk, _SHA512_File, _SHA512_FileChunk, _SHA_Data,
                       _SHA_End, _SHA_Fd, _SHA_FdChunk, _SHA_File, _SHA_FileChunk,
                       _SHA_Final, _SHA_Init, _SHA_Update ]

I don't have CLT 13.4 handy to test, but was this file added with CLT 14? I still have my 2015 MacBook with 12.6 that I can pull out and see if I can reproduce it there.

@posguy99
Copy link
Author

posguy99 commented Jan 31, 2023

CLT 13.x does not ship the macOS 13 SDK, it was added in CLT 14. So in macOS 13.x, libmd must be in the dylib cache. I don't have a macOS 13 machine to be able to look.

You can build with CLT 14.2 on macOS 13?

@posguy99
Copy link
Author

posguy99 commented Feb 1, 2023

If you want to look, supposedly https://github.com/keith/dyld-shared-cache-extractor is the tool to use.

@posguy99
Copy link
Author

posguy99 commented Feb 4, 2023

@tvalenta For some reason, I can't create a macOS13.x VM. On my M1Pro, macOS 12 wants to download an update in order for UTM to create a macOS 13 VM. I think it wants to upgrade to 13.x, and I’m not about to do that.

@tvalenta
Copy link

tvalenta commented Feb 4, 2023

On my 2015 MacBook (with the way nicer keyboard), I'm running macOS 12.6.3. https://github.com/apple-oss-distributions/libmd shows activity for libmd that coincides with macOS 13.0. With installation of XCode CLT 14.2, the SDK defaults to SDK version 13.1, which includes the file MacOSX13.1.sdk/usr/lib/libmd.tbd. However, I find no evidence that libmd.dylib exists in macOS 12.6.3, and based on the history of the apple-oss-distributions/libmd repository, don't see anything to make me believe it's been included with macOS for years (the previous commit was 2008-05-03).

On my M1 MacBook running 13.x, I have no trouble building ksh93 with CLT 14.2, using the MacOS 13.1 SDK. I haven't dumped the dylib cache, but minimal tests indicate that libmd.dylib is indeed in the OS. I don't have an Intel MacBook that can run Ventura handy, but I can get my hands on one and will see if I can find the library there, too.

On my Intel MacBook with 12.6.3, I have some of the older SDKs (11.3 and 12.3). If I run
xcrun --sdk macosx12.3 sh bin/package make, the build doesn't detect libmd as being an available library and completes -- skipping over libsum and libcmd.

Running xcrun --sdk macosx13.1 sh bin/package make fails with libmd being linked to the test binary, but not actually existing.

Based on https://firefox-source-docs.mozilla.org/widget/cocoa/sdks.html, I tried xcrun --sdk macosx13.1 sh bin/package make CCFLAGS="-mmacosx-version-min=12.0" but it also failed. I couldn't find any magic sauce in usr/include/Availability*.h files that referenced libmd routines. In the 13.1 SDK, the only header files I found with references to the ksh routines from ksh93/ksh/src/lib/libsum/sum-lmd.c were in the SDK's include file CommonCrypto/CommonDigest.h.

Could it be entirely serendipitous that ksh compiles at all on macOS 13.0?

@posguy99
Copy link
Author

posguy99 commented Feb 5, 2023

OK, while I was not able to create a macOS 13.x VM cold, I created a 12.4 VM and upgraded it to 13.2, which worked.

And sure enough, on macOS 13.2, using CLT 14.2, I can confirm as well that ksh compiles without error.

@tvalenta
Copy link

tvalenta commented Feb 5, 2023 via email

@posguy99
Copy link
Author

@McDutchie Are the two Mamfile patches from here https://github.com/apple-oss-distributions/ksh/tree/ksh-30/patches relevant? I will have to spin a new 12.x VM with CLT 14.2, but I figured Apple had to get around this problem somehow since macOS 13 still distributes ksh.

Removing libmd completely as @pghvlaans pointed out isn't a general solution for all platforms, of course. 🤷‍♂️

@posguy99
Copy link
Author

posguy99 commented Feb 17, 2023

Ok, yes, applying both src__lib__libcmd__Mamfile.diff and src__lib__libsum__Mamfile.diff allows ksh to build on macOS 12.4 + CLT 14.2.

So that's how Apple must have gotten around the build failure.

@posguy99
Copy link
Author

Here are the two patches.

libsum_libcmd_mamfile.patch

@McDutchie
Copy link

Thanks for finding that. Now I just need to test that those patches don't break the build on any other system.

@posguy99
Copy link
Author

@hyenias You have at least one system that actually ships libmd, does Apple's patch break anything for you?

@McDutchie
Copy link

Applying the patch on FreeBSD doesn't break the build, but also produces a ksh binary that is not linked against libmd. I don't know what the ramifications of that are.

$ ldd arch*/*/bin/ksh
arch.orig/freebsd12.i386-64/bin/ksh:
        libm.so.5 => /lib/libm.so.5 (0x800373000)
        libmd.so.6 => /lib/libmd.so.6 (0x8003a9000)
        libutil.so.9 => /lib/libutil.so.9 (0x8003c7000)
        libc.so.7 => /lib/libc.so.7 (0x8003df000)
arch.patch/freebsd12.i386-64/bin/ksh:
        libm.so.5 => /lib/libm.so.5 (0x800373000)
        libutil.so.9 => /lib/libutil.so.9 (0x8003a9000)
        libc.so.7 => /lib/libc.so.7 (0x8003c1000)

@posguy99
Copy link
Author

libmd not being present isn't inherently fatal to ksh. Does said fBSD system have libmd and link libmd without the patch? Can iffe be smart enough to only apply the workaround on macOS?

I don't claim to know what ksh uses libmd for if it finds it.

@posguy99
Copy link
Author

@McDutchie Random question... why does the ksh build go looking for MD5 and related, anyway?

@McDutchie
Copy link

So, I don't understand: I have, in fact, been building on macOS 12.6.3 with Command Line Tools 14.2, without the patch, and it's always been building fine. I have no idea how to reproduce your failure.

I really don't want to blindly apply a patch without having a clue what's going on.

Perhaps seeing the exact compiler commands will provide some sort of clue. I've pushed a commit (8f37528) that makes iffe show these with IFFEFLAGS=-d1. Could you reproduce the failure with that commit and paste the debug output with the compiler command lines here?

@posguy99
Copy link
Author

posguy99 commented Feb 21, 2023

#596 (comment)

That's CLT 13.4 and CLT 14.2 building on macOS 12.4. Would the patch provide any more info than that? Do you want me to do both a build with 13.4 and with 14.2?

Edit... to be clear, while it happens with the production machines, every time I test, I re-spin the VM(s), and the only thing in the VM(s) is the CLT. No other software is installed.

And @tvalenta gets the same results.

@McDutchie
Copy link

After installing the incredible bloatware that is the XCode graphical interface, I can now reproduce the build error.

@McDutchie
Copy link

After installing XCode.app, I can reproduce it even with a simple test program:

$ echo 'int main(void) { return 0; }' >test.c 
$ cc test.c -lmd
$ ./a.out
dyld[63517]: Library not loaded: '/usr/lib/libmd.dylib'
  Referenced from: '/usr/local/src/ksh93/ksh/a.out'
  Reason: tried: '/usr/lib/libmd.dylib' (no such file), '/usr/local/lib/libmd.dylib' (no such file)
Abort

So, this is not our bug. XCode breaks the system.

@posguy99
Copy link
Author

After installing the incredible bloatware that is the XCode graphical interface, I can now reproduce the build error.

Which is weird since I have never had XCode installed on my M1, and never had it installed in any of the VMs I've been testing in.

@posguy99
Copy link
Author

So, this is not our bug. XCode breaks the system.

Agreed. As @tvalenta pointed out, the stub that the macOS 13 SDK installs fools the lazy linker into thinking the library is there, but it isn't in the dylib cache on macOS 12, so at runtime it goes looking for it and fails.

Can it be worked around, though? Can iffe actually try to execute the resulting executable, and trap on the error that would be generated? I could swear that some other iffe test does that. Doing that would not be fatal to any other platform, and would work on macOS.

@McDutchie
Copy link

McDutchie commented Feb 21, 2023

The workaround should be in the same Mamfiles that Apple patched, but I'm not happy with simply deleting the test for libmd. It should do what you say -- actually attempt to execute the test programs, instead of being satisfied with just being able to compile them.

The patch below should accomplish this (by adding && ./1.${COTEMP}.x to execute the test binary, which should do nothing but return 0).

Patch v1
diff --git a/src/lib/libcmd/Mamfile b/src/lib/libcmd/Mamfile
index 5aa4e2478..540dbab63 100644
--- a/src/lib/libcmd/Mamfile
+++ b/src/lib/libcmd/Mamfile
@@ -39,8 +39,8 @@ make install
 				exec - esac
 				exec - continue
 				exec - elif test ! -f ${INSTALLROOT}/lib/lib$i.a
-				exec - then case `{ ${CC} ${mam_cc_FLAGS} ${CCFLAGS} -L${INSTALLROOT}/lib ${LDFLAGS} -o 1.${COTEMP}.x 1.${COTEMP}.o -l$i 2>&1 || echo '' "$x" ;} | sed -e 's/[][()+@?]/#/g' || :` in
-				exec - *$x*) case `{ ${CC} ${mam_cc_FLAGS} ${CCFLAGS} ${LDFLAGS} -o 1.${COTEMP}.x 1.${COTEMP}.o -l$i 2>&1 || echo '' "$x" ;} | sed -e 's/[][()+@?]/#/g' || :` in
+				exec - then case `{ ${CC} ${mam_cc_FLAGS} ${CCFLAGS} -L${INSTALLROOT}/lib ${LDFLAGS} -o 1.${COTEMP}.x 1.${COTEMP}.o -l$i 2>&1 && ./1.${COTEMP}.x || echo '' "$x" ;} | sed -e 's/[][()+@?]/#/g' || :` in
+				exec - *$x*) case `{ ${CC} ${mam_cc_FLAGS} ${CCFLAGS} ${LDFLAGS} -o 1.${COTEMP}.x 1.${COTEMP}.o -l$i 2>&1 && ./1.${COTEMP}.x || echo '' "$x" ;} | sed -e 's/[][()+@?]/#/g' || :` in
 				exec - *$x*) continue ;;
 				exec - esac
 				exec - ;;
diff --git a/src/lib/libsum/Mamfile b/src/lib/libsum/Mamfile
index ed011c588..27048ef66 100644
--- a/src/lib/libsum/Mamfile
+++ b/src/lib/libsum/Mamfile
@@ -39,8 +39,8 @@ make install
 				exec - esac
 				exec - continue
 				exec - elif test ! -f ${INSTALLROOT}/lib/lib$i.a
-				exec - then case `{ ${CC} ${mam_cc_FLAGS} ${CCFLAGS} -L${INSTALLROOT}/lib ${LDFLAGS} -o 1.${COTEMP}.x 1.${COTEMP}.o -l$i 2>&1 || echo '' "$x" ;} | sed -e 's/[][()+@?]/#/g' || :` in
-				exec - *$x*) case `{ ${CC} ${mam_cc_FLAGS} ${CCFLAGS} ${LDFLAGS} -o 1.${COTEMP}.x 1.${COTEMP}.o -l$i 2>&1 || echo '' "$x" ;} | sed -e 's/[][()+@?]/#/g' || :` in
+				exec - then case `{ ${CC} ${mam_cc_FLAGS} ${CCFLAGS} -L${INSTALLROOT}/lib ${LDFLAGS} -o 1.${COTEMP}.x 1.${COTEMP}.o -l$i 2>&1 && ./1.${COTEMP}.x || echo '' "$x" ;} | sed -e 's/[][()+@?]/#/g' || :` in
+				exec - *$x*) case `{ ${CC} ${mam_cc_FLAGS} ${CCFLAGS} ${LDFLAGS} -o 1.${COTEMP}.x 1.${COTEMP}.o -l$i 2>&1 && ./1.${COTEMP}.x || echo '' "$x" ;} | sed -e 's/[][()+@?]/#/g' || :` in
 				exec - *$x*) continue ;;
 				exec - esac
 				exec - ;;

@McDutchie
Copy link

Ok, is #567 related?

Yes – it is the same issue.

@McDutchie
Copy link

This makes me suspect that, for at least the past decade, macOS builds haven't uhh included libcmd and libsum,

They are statically linked in the stock 93u+ build. E.g., /bin/ksh -c 'builtin' will include various libcmd path-bound builtins, the ones with /opt/ast/bin paths.

McDutchie added a commit that referenced this issue Feb 22, 2023
The macOS 13 SDK that comes with Xcode.app includes a libmd stub
that fools the linker into thinking the md (message digest) library
is actually installed, though this is not the case. Consequently,
after installing Xcode.app, compiling programs with -lmd
incorrectly succeeds, but executing them fails:

$ echo 'int main(void) { return 0; }' >test.c
$ cc test.c -lmd
$ ./a.out
dyld[63517]: Library not loaded: '/usr/lib/libmd.dylib'
  Referenced from: '/usr/local/src/ksh93/ksh/a.out'
  Reason: tried: '/usr/lib/libmd.dylib' (no such file), '/usr/local/lib/libmd.dylib' (no such file)
Abort

This fools the probes for libmd in lib{cmd,sub}/Mamfile as they
only try to compile the program, not run it. A false positive
result for libmd results, and the build fails at a later (seemingly
unrelated) stage.

Clearly, this is Apple's bug and not ours. As a workaround for
their 93u+ 2012-08-01 build, Apple patched lib{cmd,sum}/Mamfile to
simply remove probing for libmd. But that is not an acceptable
multi-platform solution. A better workaround is almost as simple:
the test program should actually be run as part of the probe.

On Apple systems with this bug, a dyld Abort crash like the above
will now show up in the compile log four times as the test program
fails to run. I'm okay with this.

src/lib/libcmd/Mamfile,
src/lib/libsum/Mamfile:
- When generating cmd.req and sum.req, actually attempt to run the
  test program as part of the link test. This is done by adding
  '&& ./1.${COTEMP}.x' where appropriate.
- Reformat the probe code (originally generated by nmake) for
  legibility and manual maintenance.

Thanks to @tvalenta and @posguy99 for their help finding the cause
of the problem.

Resolves: #567
Resolves: #596
@McDutchie
Copy link

Note: if you still get the build error after pulling the fix, delete arch and start over.

@posguy99
Copy link
Author

Confirming that CLT 14.2 can now be used to build ksh on macOS 12.4.

@tvalenta
Copy link

tvalenta commented Mar 3, 2023

@McDutchie Are the two Mamfile patches from here https://github.com/apple-oss-distributions/ksh/tree/ksh-30/patches relevant? I will have to spin a new 12.x VM with CLT 14.2, but I figured Apple had to get around this problem somehow since macOS 13 still distributes ksh.

Removing libmd completely as @pghvlaans pointed out isn't a general solution for all platforms, of course. 🤷‍♂️

FYI - I went back and looked at the version of ksh apple distributes. If I understand correctly, the ast-ksh.2012-08-01.tgz content attempted to compile cksum and md5sum and sum which required libmd. So the difference here appears to be that code in this repo would check for the ability of libmd and potentially use it if available. I only got it to be consumed if I set SHOPT ALL_LIBCMD=1 in ./src/cmd/ksh93/SHOPT.sh, thereby getting as a builtin /opt/ast/bin/md5sum. Comparatively (where I admittedly haven't validated) , the code apple uses expects libmd to be available.

And for any of those, I finally realize I wouldn't have ever noticed the difference b/c I don't have /opt/ast/bin/ in my PATH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
buildfail Does not compile
Projects
None yet
Development

No branches or pull requests

4 participants