gv @3.7.4 does not launch because symbol _yylex is not found in flat namespace

[ballapete (Peter "Pete" Dyballa)]

pete 225 /\ gv --help
dyld[70056]: symbol not found in flat namespace (_yylex)
Abort
Exit 134

  gv @3.7.4_4 (active) requested_variants='' platform='darwin 21' archs='x86_64' date='2022-11-09T17:45:25+0100'

pete 251 /\  otool -L `which gv`
/opt/local/bin/gv:
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	/opt/local/lib/libXinerama.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libXaw3d.8.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)
	/opt/local/lib/libXmu.6.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0)
	/opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libfl.2.dylib (compatibility version 3.0.0, current version 3.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)

Do you need more input?

[ryandesign (Ryan Carsten Schmidt)]

Did you build from source or get a binary from our server? On Monterey, when I install the binary from the server it works fine but when I build from source I get the same problem you got. To ensure you have the binary version, run:

sudo port -nb upgr --force gv

I fixed a handful of yylex-related issues earlier this year (in ​magicpoint, ​grok, ​flow-tools, ​dict, ​micropolis) but those were implicit declaration of function problems, not symbol not found problems.

However it does sound exactly like a problem we found with the cscope port in #64448. The cause seemed to be an apparent change in macOS Monterey (maybe the dyld dynamic loader) with regard to programs that have been stripped. The cscope Portfile had been manually running strip on the cscope executable, which had been fine prior to Monterey, but as of Monterey such a program failed to run—even a program that had been compiled and stripped on Big Sur and was working on Big Sur.

For gv I can't see anywhere that the program is being stripped so it might not be the same cause here. As I noted in the cscope bug report, I didn't understand why not stripping fixed the problem, and I suspected some deeper issue like an OS bug, but Apple was unhelpful in my bug report to them and since we found a workaround at the time I stopped pursuing it.

The cscope issue was originally filed as #63793 which I attempted to fix by declaring a dependency on the flex and bison ports, since they would be used anyway if found. That didn't seem to affect the situation there, but it does for gv: I do have MacPorts bison and flex installed on the machine where I see the problem, and I see that the gv executable does end up linked with flex's libfl.2.dylib. If I rebuild in trace mode (sudo port -nst upgrade --force gv) then gv won't find MacPorts flex or bison (since they're not declared as dependencies) and the problem goes away. Perhaps this indicates a problem with the flex port.

My machine where I can confirm the gv issue is a little out of date, running macOS 12.3.1 with command line tools 13.2.0.0.1.1638488800. What versions do you have? The binary was built on January 23, 2022, at which time our Monterey build machine was still running macOS 12.0.1 with a corresponding version of the CLT. The cscope bug was reported on macOS 12.1.

[ballapete (Peter "Pete" Dyballa)]

I built from source today. I do not remember which version was installed before. It failed too, so I upgraded all, also the Xcode command line tools, and then built gv again, assumimg the binary package could be faulty.

Upgrading gv from the binary package makes it work. Thank you!

[ballapete (Peter "Pete" Dyballa)]

I am using Monterey 12.6 and I am thinking of installing version 12.6.1 before switching to Ventura. The Command Line Tools for Xcode seem to be of Version 14.1. They were of version 13.2 when I installed gv previously. port -qv installed reports approximately gv @3.7.4_4 (active) platform='darwin 21' date='2022-01-23T10:50:26+0100' which does not seem to tell whether from source or from binary package – the source archive is from 2021-11-10 and its directory from the same ISO date…

[ebellm (Eric Bellm)]

I see the same error with arm64 Ventura 13.1 (gv @3.7.4_4 (active) requested_variants='' platform='darwin 22' archs='arm64' date='2023-01-04T12:14:22-0800') and the latest command-line tools (Xcode 14.2 Build version 14C18). There's no binary build, unfortunately.

[andrewathome]

I see the same error with gv 3.7.4 and Ventura 13.1 on arm64. So I did a bit of digging and came up with the below hack that seems to work around the issue. I've added this update in case someone else finds it useful.

---

Looks like the undefined symbol _yylex is not in gv itself, but in a dynamic library: /opt/local/lib/libfl.2.dylib

It's not clear why this library is included, since it only provides two symbols: _main (already provided in gv itself), and _yywrap (not used in gv or in any of the other dynamic libraries).

So I created an (almost) empty dynamic library and installed it as /opt/local/lib/fake.dylib, and replaced the reference to the offending libfl.2 by using this command:

install_name_tool -change /opt/local/lib/libfl.2.dylib /opt/local/lib/fake.dylib /opt/local/bin/gv

Now my gv no longer aborts with the unresolved symbol error, and I am able to view postscript docs.

Of course the usual caveats apply: it's a hack/workaround, not a solution; it's unlikely to be futureproof; I haven't tested the patched gv exhausatively, so there could well be gotyas that I haven't yet stumbled upon.

[kwolcott]

I can confirm that installing the binary port works fine. I prefer to install from source whenever possible (purist?).

Thanks, Ken Wolcott