AWESOME response! :-) Thank you so much for the education! <GRIN> Ken Wolcott
On Mon, Aug 18, 2025 at 12:20 PM Ryan Carsten Schmidt <[email protected]> wrote: > > On Aug 18, 2025, at 12:50, Kenneth Wolcott wrote: > > > > Hi; > > > > <https://rosettacode.org/wiki/Hamming_numbers#C> > > > > Rosetta Code "Hamming numbers" task written in C (version 2) fails for > > me on MacOS (M1) when using the following command: > > > > clang -lm -lgmp -o ./hamming_numbers ./hamming_numbers.c > > > > failure message: > > Undefined symbols for architecture arm64: > > "__eq", referenced from: > > _get_ham in hamming_numbers-af6ba2.o > > "__setv", referenced from: > > _get_ham in hamming_numbers-af6ba2.o > > _main in hamming_numbers-af6ba2.o > > ld: symbol(s) not found for architecture arm64 > > clang: error: linker command failed with exit code 1 (use -v to see > > invocation) > > > > My LD_LIBRARY_PATH env variable does not exist or is blank. > > > > Should I use this env var? > > > > If so, what should it be set to? > > > > What am I missing in my compiler+linker command? > > Hi Ken, > > Short answer: > > Add the compiler flag "-std=gnu89" or remove the two instances of the keyword > "inline" from the code. > > Long answer: > > There are two versions of the code at that URL and I see you're using the > second "alternative" one that uses gmp and the math library. > > Note that the "-lm" flag is always unnecessary on macOS because the math > library is part of the standard library. > > This code was written to GNU89 inline semantics where the "inline" keyword > means "inline this function" but clang defaults to GNU99 inline semantics > where the "inline" keyword means "when the compiler chooses to inline this > function, use this code, and when the compiler chooses not to inline this > function, use other code". The problem is that clang chose not to inline the > function and no non-inline version of the function was provided hence the > symbols were undefined. > > LD_LIBRARY_PATH is for Linux. The nearest equivalent on macOS is > DYLD_LIBRARY_PATH but macOS dynamic libraries do not work like Linux shared > libraries and the reasons why you would set LD_LIBRARY_PATH on Linux do not > apply to DYLD_LIBRARY_PATH on macOS. Users should not need to set > DYLD_LIBRARY_PATH. (Build systems might need to set it as part of the build, > e.g. if as part of the build they want to run a program that was just built > against a library that was just built and not yet installed.) > >
