On Sun, Nov 16, 2025 at 09:49:10AM -0600, G. Branden Robinson wrote: > At 2025-11-11T19:16:05-0500, Thomas Dickey wrote: > > Your build failed because there's nothing to force the loader to find > > the shared library in the build-tree. > > It sure seems like the `-L ../../lib` flag to gcc should be > accomplishing this.
I'd like it to do that, but haven't found it to be 100% reliable :-( I recall various platforms where the -L option works for the actual file referenced, but doesn't pick up any of the dependencies in the same directory. (I also have cases where the problem is compiler-specific, e.g., clang vs gcc) > The workaround I came up with is this, run from the build directory. > > $ mkdir -p ~/ncurses-HEAD/lib && cp -v ./lib/libtinfotw.* ~/ncurses-HEAD/lib/ > > In other words, I copy the library pieces to my _installation_ > directory. > > I can then type "make", the build resumes and runs to completion. > > "$HOME/ncurses-HEAD/lib" also needs to be in my (exported) > `LD_LIBRARY_PATH` environment variable. I reckon this accomplishes more > or less what your "misc/shlib" script does. yes. Initially I made shlib to allow running the test-programs without installing them, and then incorporated it into some parts of the build to work around linker quirks. > But I wonder why it's _necessary_, given that `-L ../../lib` should be > making the already constructed library files impossible to miss. If it were all gcc, I'd suggest the verbose option "-v", but gnatmake has a different use for "-v". -- Thomas E. Dickey <[email protected]> https://invisible-island.net
signature.asc
Description: PGP signature
