legacy-support needs to use -Wl, when adding library name to LDFLAGS

[ryandesign (Ryan Carsten Schmidt)]

​gwenhywfar5 fails to build on 10.6:

/bin/sh ../libtool  --tag=CC   --mode=link /opt/local/bin/clang-mp-9.0   -pipe -Os -arch x86_64 -Wall -Wall -Wall -no-undefined   -version-info 82:0:3 -L/opt/local/lib -Wl,-headerpad_max_install_names /opt/local/lib/libMacportsLegacySupport.dylib -arch x86_64 -o libgwenhywfar.la -rpath /opt/local/lib binreloc.lo gwenhywfar.lo base/libbase.la crypt3/libcrypt3.la crypttoken/libcrypttoken.la cryptmsg/libcryptmsg.la sio/libsio.la os/libos.la parser/libparser.la html/libgwenhtml.la gui/libgui.la sar/libsar.la test_framework/libtestframework.la -lintl  -liconv -L/opt/local/lib -lgcrypt -lgpg-error -L/opt/local/lib -lgnutls   
libtool: link: /opt/local/bin/clang-mp-9.0 -dynamiclib  -o .libs/libgwenhywfar.79.dylib  .libs/binreloc.o .libs/gwenhywfar.o   -Wl,-force_load,base/.libs/libbase.a -Wl,-force_load,crypt3/.libs/libcrypt3.a -Wl,-force_load,crypttoken/.libs/libcrypttoken.a -Wl,-force_load,cryptmsg/.libs/libcryptmsg.a -Wl,-force_load,sio/.libs/libsio.a -Wl,-force_load,os/.libs/libos.a -Wl,-force_load,parser/.libs/libparser.a -Wl,-force_load,html/.libs/libgwenhtml.a -Wl,-force_load,gui/.libs/libgui.a -Wl,-force_load,sar/.libs/libsar.a -Wl,-force_load,test_framework/.libs/libtestframework.a  -L/opt/local/lib /opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib /opt/local/lib/libgcrypt.dylib /opt/local/lib/libgpg-error.dylib /opt/local/lib/libgnutls.dylib  -Os -arch x86_64 -Wl,-headerpad_max_install_names -arch x86_64   -framework Security -framework CoreFoundation -install_name  /opt/local/lib/libgwenhywfar.79.dylib -compatibility_version 83 -current_version 83.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "_strndup", referenced from:
      _GWEN_Text_strndup in libparser.a(text.o)
     (maybe you meant: _GWEN_Text_strndup)
ld: symbol(s) not found for architecture x86_64

I already added the legacysupport 1.1 portgroup which should have taken care of this but didn't. On the /bin/sh ../libtool line we can see that /opt/local/lib/libMacportsLegacySupport.dylib is specified. That should invoke libtool and it should pass that on to clang when it invokes it but on the libtool: link: line legacysupport is not mentioned.

Is this fix to the legacysupport 1.1 portgroup the correct fix?

legacysupport-1.1.tcl

@@ -66 +66 @@
         depends_lib-delete path:lib/libMacportsLegacySupport.dylib:legacy-support
         depends_lib-append path:lib/libMacportsLegacySupport.dylib:legacy-support
 
-        configure.ldflags-delete    [option legacysupport.library_name]
-        configure.ldflags-append    [option legacysupport.library_name]
+        configure.ldflags-delete    -Wl,[option legacysupport.library_name]
+        configure.ldflags-append    -Wl,[option legacysupport.library_name]
 
         if {![option compiler.limit_flags]} {
             configure.cppflags-delete   [option legacysupport.header_search]

I think this works for this case, but I don't know if it messes up any other use cases.

[ryandesign (Ryan Carsten Schmidt)]

The description of the option in the portgroup is:

#   legacysupport.library_name: linker flag used to add library

If that's what the option is intended to contain, then I suggest instead that legacysupport.library_name is the wrong name for the option; it should be legacysupport.ldflags instead. Similarly, legacysupport::get_library_name should be renamed to legacysupport::get_ldflags. And then legacysupport::get_ldflags would be changed to return the -Wl, prefix.

legacysupport-1.1.tcl

@@ -12 +12 @@
 #
 #   legacysupport.header_search: preprocessor flag used to locate header directory
 #
-#   legacysupport.library_name: linker flag used to add library
+#   legacysupport.ldflags: linker flag used to add library
 #
 #   legacysupport.use_static: allow static linking of legacysupport if preferred (e.g. for compilers)
 #
@@ -26 +26 @@
 options legacysupport.header_search
 default legacysupport.header_search     {-isystem${prefix}/include/LegacySupport}
 
-options legacysupport.library_name
-default legacysupport.library_name      {[legacysupport::get_library_name]}
+options legacysupport.ldflags
+default legacysupport.ldflags           {[legacysupport::get_ldflags]}
 
 options legacysupport.use_static
 default legacysupport.use_static        no
@@ -45 +45 @@
 namespace eval legacysupport {
 }
 
-proc legacysupport::get_library_name {} {
+proc legacysupport::get_ldflags {} {
     global prefix
     if {[option legacysupport.use_static]} {
-        return ${prefix}/lib/libMacportsLegacySupport.a
+        return -Wl,${prefix}/lib/libMacportsLegacySupport.a
     } else {
-        return ${prefix}/lib/libMacportsLegacySupport.dylib
+        return -Wl,${prefix}/lib/libMacportsLegacySupport.dylib
     }
 }
 
@@ -66 +66 @@
         depends_lib-delete path:lib/libMacportsLegacySupport.dylib:legacy-support
         depends_lib-append path:lib/libMacportsLegacySupport.dylib:legacy-support
 
-        configure.ldflags-delete    [option legacysupport.library_name]
-        configure.ldflags-append    [option legacysupport.library_name]
+        configure.ldflags-delete    [option legacysupport.ldflags]
+        configure.ldflags-append    [option legacysupport.ldflags]
 
         if {![option compiler.limit_flags]} {
             configure.cppflags-delete   [option legacysupport.header_search]

Is that agreeable?

[kencu (Ken)]

renaming the options aside, you'd like to prefix the library name with "-Wl," as libtool isn't handling the full name with path correctly.

Sounds reasonable -- maybe explains why qemu wouldn't accept legacysupport easily too, come to think of it.

If any software builds call ld directly, that will error out I think, if it goes to the link line. But they are not supposed to call ld directly anyway.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #61325.

[kencu (Ken)]

In 7bded6b45234445ad5cc49a5f56b404ef3d8a38d/macports-ports (master):

legacysupport 1.1 PG: use tranditional libname

it turns out that libtool does not pass along
dylibs for linking when the name is a full-specified
pathname.

However, libtool does pass along static libs for linking
when the name is a fully-specified pathname.

the changes the dylib name back to the traditional one
that works, and has been used for some years in legacysupport 1.0.

Hopefully this is the simplest, least-invasive, and most tested
method of restoring the proper link behaviour when using
legacysupport and libtool.

see: #60798

[ryandesign (Ryan Carsten Schmidt)]

See ​https://github.com/macports/macports-ports/pull/8780#issuecomment-709366092 for why this change will break ports.

[kencu (Ken)]

I believe this is the proper fix.

poppler should not be deleting -L${prefix}/lib from the link line.

It should be forcing DYLD_LIBRARY_PATH to the in-tree build instead.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

I believe this is the proper fix.

poppler should not be deleting -L${prefix}/lib from the link line.

Well hopefully the folks who added that can provide some clarity on why they did it and can find an alternate solution.

It should be forcing DYLD_LIBRARY_PATH to the in-tree build instead.

DYLD_LIBRARY_PATH isn't related. The usual reason why one removes MacPorts -L or -I flags is if the build system puts them in the wrong place on the compile line (before the project's own -L or -I flags instead of after them where they belong).