nedit @5.7: Symbol not found: _vendorShellWidgetClass

[obspyyale]

Trying to use the nedit program on my new iMac M3, after installing MacPorts for Sonoma

Searching the internet suggests that the libraries Xm.a and Xt.a were loaded in the wrong order in the nedit compilation, but I cannot verify this.

--> nedit .cshrc 
 dyld[93664]: Symbol not found: _vendorShellWidgetClass
  Referenced from: <B0C176D5-4F1E-316E-A53A-2EA6B4F48FBA> /opt/local/bin/nedit
  Expected in:     <C5BDACE7-B18C-3905-8915-706615092114> /opt/local/lib/libXm.4.dylib

[obspyyale]

I am new to this process. Apologies for my clumsy usage of the system!

[ryandesign (Ryan Carsten Schmidt)]

Could you give a URL to where you found the suggestion about the incorrect order of the libraries?

[obspyyale]

Thanks for responding to my ticket! Here is the web page of which I spoke (shoulda listed it!)

​https://stackoverflow.com/questions/32373700/no-realize-class-procedure-defined

[ryandesign (Ryan Carsten Schmidt)]

I can reproduce the problem on my own (macOS 12 x86_64) system if I receive a binary of nedit compiled on our build servers last year. However if I rebuild it from source (sudo port -ns upgrade --force nedit) then it works. Does that work for you too?

According to the ​LessTif FAQ entry referenced by an answer of that Stack Overflow question, the libraries must be linked in the order -lXm -lXt -lX11. Building nedit from source on my system, the log says:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_nedit/nedit/work/compwrap/cc/usr/bin/clang -O -no-cpp-precomp -mdynamic-no-pic -DNO_XMIM -I/opt/local/include -DUSE_DIRENT -DUSE_LPR_PRINT_CMD -DBUILD_UNTESTED_NEDIT nedit.o file.o menu.o window.o selection.o search.o undo.o shift.o help.o preferences.o tags.o userCmds.o shell.o regularExp.o macro.o text.o textSel.o textDisp.o textBuf.o textDrag.o server.o highlight.o highlightData.o interpret.o parse.o smartIndent.o regexConvert.o windowTitle.o calltips.o server_common.o rangeset.o linkdate.o ../Microline/XmL/libXmL.a \
	 ../Xlt/libXlt.a ../util/libNUtil.a -bind_at_load -L/opt/local/lib -Wl,-headerpad_max_install_names -lXm -lXp -lXpm -lXext -lXt -lSM -lICE -lX11 -o nedit
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_nedit/nedit/work/compwrap/cc/usr/bin/clang -c -I../Microline -I../Xlt -O -no-cpp-precomp -mdynamic-no-pic -DNO_XMIM -I/opt/local/include -DUSE_DIRENT -DUSE_LPR_PRINT_CMD -DBUILD_UNTESTED_NEDIT -o nc.o nc.c
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_nedit/nedit/work/compwrap/cc/usr/bin/clang -O -no-cpp-precomp -mdynamic-no-pic -DNO_XMIM -I/opt/local/include -DUSE_DIRENT -DUSE_LPR_PRINT_CMD -DBUILD_UNTESTED_NEDIT nc.o server_common.o ../util/libNUtil.a -bind_at_load -L/opt/local/lib -Wl,-headerpad_max_install_names -lXm -lXp -lXpm -lXext -lXt -lSM -lICE -lX11 -o nc

In other words, -lXm already precedes -lXt which precedes -lX11. But this is from a build that works and our buildbot logs from the builds that created last year's binaries that are failing to work for me have already expired so I cannot compare them.

I'm not sure that the order of libraries is what's significant though. The LessTif FAQ explains the importance of the library order when using a static linker and when linking with ELF shared libraries. We're doing neither in MacPorts; we're using Mach-O dynamic libraries. I'm aware that the order of library flags on the command line is important on ELF but is not something I've ever had to concern myself with on macOS because presumably Mach-O just doesn't work that way.

Motif definitely does things weird. We've definitely had other Motif-using ports that fail to run for inexplicable reasons relating to Motif design choices that don't work well on macOS. However, the issue with ddd that I was trying to remember was fixed last week by changing the order of linking, as you said. But in the ​upstream bug report about that Mohamed explains that on macOS with its two-level namespace for Mach-O dynamic libraries the rules for which library must go first are reversed from what it must be on Linux with ELF shared libraries.

There was also a fix to openmotif last week. Maybe that is what makes nedit work now after a rebuild. Maybe it means all ports linking with openmotif should be revbumped to rebuild them?

[obspyyale]

The command that you suggested that forces macports to rebuild nedit from source was successful on my system. Thank you so much for your help. I read through your sleuthing the files and servers and build commands to discover the ultimate source problem. It is a challenge to track this stuff down, I agree. This experience teaches me that solutions are indeed possible when a complex software package fails.

[mohd-akram (Mohamed Akram)]

In 0c8cd81f7302ba598b080d5f9522c3d396aed35c/macports-ports (master):

nedit: rev-bump for openmotif

Fixes: #70049

[mohd-akram (Mohamed Akram)]

With my recent change to openmotif, linking order shouldn't matter on macOS as long as only one widget set (i.e. one library providing a vendor shell) is used. It seems some ports were getting this symbol from Motif rather than Xt so they'll need to be rev-bumped after this change.

[mohd-akram (Mohamed Akram)]

It seems there might be a simpler patch for Xm, Xaw and Xt that would make them behave like on other platforms. Rather than using __attribute__((constructor)), I did a quick test with __attribute__((weak)) and if set on a variable in multiple libraries, they will coalesce onto the first one found, even when using two-level namespaces, like on Linux. That could potentially be used for vendorShellWidgetClass and we wouldn't have to change linking order.

[obspyyale]

Thanks again for the updates. It seems as though my problem has inspired a welcome update of the software and library structure. I do recall that Motif is very old. I have been using nedit for nearly 25 years, as well. It is very spartan, but also convenient.