[MacPorts] #70049: nedit @5.7: Symbol not found: _vendorShellWidgetClass

[MacPorts]

#70049: nedit @5.7: Symbol not found: _vendorShellWidgetClass
------------------------+--------------------
  Reporter:  obspyyale  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.9.3
Resolution:             |   Keywords:  sonoma
      Port:  nedit      |
------------------------+--------------------
Changes (by ryandesign):

 * cc: mohd-akram (added)


Comment:

 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 [https://lesstif.sourceforge.net/FAQ.html#QU3.0 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 [ticket:50463 issue
 with ddd] that I was trying to remember was
 [changeset:c60fdb09972630414a82f2d349f7cad445c7d088/macports-ports fixed
 last week] by changing the order of linking, as you said. But in the
 [https://savannah.gnu.org/bugs/?65738 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 [changeset:27c5047377cbbd41827637c940a91cd1b6197612
 /macports-ports 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?

-- 
Ticket URL: <https://trac.macports.org/ticket/70049#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS