Opened 4 years ago

Closed 3 years ago

#60798 closed defect (fixed)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: haspatch Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), kencu (Ken)
Port: gwenhywfar5, legacy-support

Description (last modified by 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

     
    6666        depends_lib-delete path:lib/libMacportsLegacySupport.dylib:legacy-support
    6767        depends_lib-append path:lib/libMacportsLegacySupport.dylib:legacy-support
    6868
    69         configure.ldflags-delete    [option legacysupport.library_name]
    70         configure.ldflags-append    [option legacysupport.library_name]
     69        configure.ldflags-delete    -Wl,[option legacysupport.library_name]
     70        configure.ldflags-append    -Wl,[option legacysupport.library_name]
    7171
    7272        if {![option compiler.limit_flags]} {
    7373            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.

Change History (9)

comment:1 Changed 4 years ago by 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

     
    1212#
    1313#   legacysupport.header_search: preprocessor flag used to locate header directory
    1414#
    15 #   legacysupport.library_name: linker flag used to add library
     15#   legacysupport.ldflags: linker flag used to add library
    1616#
    1717#   legacysupport.use_static: allow static linking of legacysupport if preferred (e.g. for compilers)
    1818#
     
    2626options legacysupport.header_search
    2727default legacysupport.header_search     {-isystem${prefix}/include/LegacySupport}
    2828
    29 options legacysupport.library_name
    30 default legacysupport.library_name      {[legacysupport::get_library_name]}
     29options legacysupport.ldflags
     30default legacysupport.ldflags           {[legacysupport::get_ldflags]}
    3131
    3232options legacysupport.use_static
    3333default legacysupport.use_static        no
     
    4545namespace eval legacysupport {
    4646}
    4747
    48 proc legacysupport::get_library_name {} {
     48proc legacysupport::get_ldflags {} {
    4949    global prefix
    5050    if {[option legacysupport.use_static]} {
    51         return ${prefix}/lib/libMacportsLegacySupport.a
     51        return -Wl,${prefix}/lib/libMacportsLegacySupport.a
    5252    } else {
    53         return ${prefix}/lib/libMacportsLegacySupport.dylib
     53        return -Wl,${prefix}/lib/libMacportsLegacySupport.dylib
    5454    }
    5555}
    5656
     
    6666        depends_lib-delete path:lib/libMacportsLegacySupport.dylib:legacy-support
    6767        depends_lib-append path:lib/libMacportsLegacySupport.dylib:legacy-support
    6868
    69         configure.ldflags-delete    [option legacysupport.library_name]
    70         configure.ldflags-append    [option legacysupport.library_name]
     69        configure.ldflags-delete    [option legacysupport.ldflags]
     70        configure.ldflags-append    [option legacysupport.ldflags]
    7171
    7272        if {![option compiler.limit_flags]} {
    7373            configure.cppflags-delete   [option legacysupport.header_search]

Is that agreeable?

comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)

comment:3 Changed 4 years ago by 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.

comment:4 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Port: legacy-support added; legacysupport removed
Summary: gwenhywfar5: Undefined symbols _strnduplegacy-support needs to use -Wl, when adding library name to LDFLAGS

Has duplicate #61325.

comment:5 Changed 3 years ago by 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

comment:6 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

comment:7 Changed 3 years ago by 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.

comment:8 in reply to:  7 Changed 3 years ago by 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).

comment:9 Changed 3 years ago by kencu (Ken)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.