#189 giflib 6.1.1: Missing symbol

[Marius Schamschula]

Actually, there are two problems:

1) the source file is not proerly versioned and lacks an extention.

2) the Makefile is missing a file. I get a missing symbol

/opt/local/var/macports/build/giflib6-9a26c042/work/compwrap/cc/usr/bin/clang -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch arm64 -std=gnu99 -fPIC -Wall -Os -dynamiclib -current_version 7.2.0 qprintf.o getarg.o -o libutil.dylib
Undefined symbols for architecture arm64:
  "_GifErrorString", referenced from:
      _PrintGifError in qprintf.o
ld: symbol(s) not found for architecture arm64

until I add gif_err.c to USOURCES

USOURCES = qprintf.c getarg.c gif_err.c

[Eric S. Raymond]

Which "source file" are you referring to? Can you suggest a specific change to fix the problem you're seeing? And what werer you tryong to build?

Pleae show me the command sequence,

[Michael Cho]

As another data point, in Homebrew we also saw undefined symbols error in 6.1.2 release. This is specific to macOS builds and can be reproduced with a make all in a fresh download of release tarball. Or isolated to specific problem target via make libutil.dylib, e.g.

❯ curl https://downloads.sourceforge.net/project/giflib/giflib-6.x/giflib-6.1.2.tar.gz -sL | tar x

❯ make -C giflib-6.1.2 libutil.dylib
cc -std=gnu99 -fPIC -Wall -O2   -c -o qprintf.o qprintf.c
cc -std=gnu99 -fPIC -Wall -O2   -c -o getarg.o getarg.c
cc -std=gnu99 -fPIC -Wall -O2 -dynamiclib -current_version 7.2.0 qprintf.o getarg.o -o libutil.dylib
Undefined symbols for architecture arm64:
  "_GifErrorString", referenced from:
      _PrintGifError in qprintf.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libutil.dylib] Error 1

---

Error is macOS ld default behavior. Original post mentioned one way of resolving, which was to provide symbol by duplicating object file in libutil.

An alternative is to change the default behavior by -Wl,-undefined,dynamic_lookup or a more fine-grain -Wl,-U,_GifErrorString, e.g. with

-       $(CC) $(CFLAGS) -dynamiclib -current_version $(LIBVER) $(UOBJECTS) -o $(LIBUTILSO)
+       $(CC) $(CFLAGS) -dynamiclib -current_version $(LIBVER) $(UOBJECTS) -o $(LIBUTILSO) -Wl,-undefined,dynamic_lookup

or

-       $(CC) $(CFLAGS) -dynamiclib -current_version $(LIBVER) $(UOBJECTS) -o $(LIBUTILSO)
+       $(CC) $(CFLAGS) -dynamiclib -current_version $(LIBVER) $(UOBJECTS) -o $(LIBUTILSO) -Wl,-U,_GifErrorString

binary symbol table and linkage looks like:

❯ nm -g libutil.dylib | grep _GifErrorString
                 U _GifErrorString

❯ nm -g libgif.dylib | grep _GifErrorString
0000000000004c54 T _GifErrorString

❯ otool -L libutil.dylib
libutil.dylib:
    libutil.dylib (compatibility version 0.0.0, current version 7.2.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)

---

A 3rd option is to link in $(LIBGIFSO) instead:

-$(LIBUTILSO): $(UOBJECTS) $(UHEADERS)
+$(LIBUTILSO): $(UOBJECTS) $(UHEADERS) $(LIBGIFSO)
 ifeq ($(UNAME), Darwin)

-   $(CC) $(CFLAGS) -dynamiclib -current_version $(LIBVER) $(UOBJECTS) -o $(LIBUTILSO)
+   $(CC) $(CFLAGS) -dynamiclib -current_version $(LIBVER) $(UOBJECTS) -o $(LIBUTILSO) $(LIBGIFSO)

---

It is also possible to just not build $(LIBUTILSO) given it isn't linked to any binaries or installed. So, in the current release, a workaround via Make variable override is make all LIBUTILSO=

[Eric S. Raymond]

No, the real problem is you have a crappy single-pass linker. The library builds just fine on systems without broken toolchains.