#57652 closed defect (fixed)
squid4 @4.4 +kerberos does not compile on macOS 10.13 (darwin/17.7.0) with linker error
Reported by: | TP75 | Owned by: | jmroot (Joshua Root) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.5.4 |
Keywords: | Cc: | ||
Port: | squid4 |
Description
Unfortunately, squid4 @4.4 +kerberos +openssl does not compile on macOS 10.13 (darwin/17.7.0) with a linker symbol(s) not found for architecture x86_64 error. However, the default squid4 @4.4 i.e. squid4 @4.4 +openssl compiles.
Local MacPorts 2.5.4 test environment /opt/macports-test1 with certain active ports:
- kerberos5 @1.16.2_0
- libedit @20180525-3.1_1
- openssl @1.0.2p_0
Find below an excerpt of the log file /opt/macports-test1/var/macports/logs/_opt_macports-test1_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_squid4/squid4/main.log
[...] :debug:sysinfo macOS 10.13 (darwin/17.7.0) arch i386 :debug:sysinfo MacPorts 2.5.4 :debug:sysinfo Xcode 10.1 :debug:sysinfo SDK 10.13 :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.13 [...] /bin/sh ../../../../libtool --tag=CXX --mode=link ccache /usr/bin/clang++ -Wno-deprecated-register -D_REENTRANT -pipe -Os -stdlib=libc++ -arch x86_64 -std=c++11 -L/opt/macports-test1/lib -Wl,-headerpad_max_install_names -arch x86_64 -o ext_kerberos_ldap_group_acl kerberos_ldap_group.o support_group.o support_netbios.o support_member.o support_krb5.o support_ldap.o support_sasl.o support_resolv.o support_lserver.o support_log.o ../../../../lib/libmiscencoding.la ../../../../compat/libcompatsquid.la -lldap -llber -lsasl2 -L/opt/macports-test1/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err libtool: link: ccache /usr/bin/clang++ -Wno-deprecated-register -D_REENTRANT -pipe -Os -stdlib=libc++ -arch x86_64 -std=c++11 -Wl,-headerpad_max_install_names -arch x86_64 -o ext_kerberos_ldap_group_acl kerberos_ldap_group.o support_group.o support_netbios.o support_member.o support_krb5.o support_ldap.o support_sasl.o support_resolv.o support_lserver.o support_log.o -L/opt/macports-test1/lib ../../../../lib/.libs/libmiscencoding.a ../../../../compat/.libs/libcompatsquid.a -lldap -llber -lsasl2 -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err Undefined symbols for architecture x86_64: "_res_9_dn_expand", referenced from: get_ldap_hostname_list(main_args*, hstruct**, unsigned long, char*) in support_resolv.o "_res_9_search", referenced from: get_ldap_hostname_list(main_args*, hstruct**, unsigned long, char*) in support_resolv.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[5]: *** [ext_kerberos_ldap_group_acl] Error 1 make[5]: Leaving directory `/opt/macports-test1/var/macports/build/_opt_macports-test1_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_squid4/squid4/work/squid-4.4/src/acl/external/kerberos_ldap_group' [...]
Thanks for the good work. Please do not hesitate to request me for more details at your convenience.
Change History (13)
comment:1 Changed 6 years ago by mf2k (Frank Schima)
Keywords: | squid squid4 kerberos ldap removed |
---|
comment:2 follow-up: 3 Changed 6 years ago by jmroot (Joshua Root)
comment:3 Changed 6 years ago by TP75
Replying to jmroot:
Thank you very much for checking the build phase and naturally a good idea. Maybe I get motivated and should contribute to that forum also as I made some experimental changes to both the squid3 and squid4 Portfiles including e.g., libressl-devel successful compiles.
comment:4 follow-up: 5 Changed 6 years ago by TP75
The following workaround compiles without error.
Refering to https://bugs.squid-cache.org/show_bug.cgi?id=4903#c5
For now you can probably work around this by using LDFLAGS in your build options, like so:
./configure LDFLAGS="-lresolv"
Adding the configure.ldflags-append "-lresolv" parameter to the kerberos variant section in the squid4 Portfile helps.
Thanks for the support. One may refer to the MacPorts Guide 5.3.7. Configure Phase Keywords and 4.6. Local Portfile Repositories for learning how to apply these changes locally.
comment:5 Changed 6 years ago by TP75
Replying to TP75:
Adding the configure.ldflags-append "-lresolv" parameter to the kerberos variant section in the squid4 Portfile helps.
See https://github.com/macports/macports-ports/pull/3063
A build and install is successful. However, both port test and port -vst install fail.
The command port test fails with error:
Error: Failed to test squid4: squid4 has no tests turned on. see 'test.run' in portfile(7)
as there seem to be no tests available.
Although port -v install succeeds a port -vst install fails with an error:
:info:destroot /opt/macports-test1/bin/gmkdir -p '/opt/macports-test1/var/macports/build/_usr_local_macports-test1_ports_net_squid4/squid4/work/destroot/opt/macports-test1/share/squid/icons/silk' :info:destroot /bin/sh: /opt/macports-test1/bin/gmkdir: No such file or directory :info:destroot make[2]: *** [install-iconDATA] Error 1
I am unsure why there is such a difference between port -v install and port -vst install.
comment:6 Changed 6 years ago by kencu (Ken)
port -vst
hides any ports that are not specifically listed as dependencies in the Portfile. So it's failing because the port is using gmkdir
but not declaring a dependency on coreutils
:
$ port provides /opt/local/bin/gmkdir /opt/local/bin/gmkdir is provided by: coreutils
comment:7 Changed 6 years ago by TP75
Thank you for the explanation. Good to know and shows the importance of the port -vst install
check.
So the squid4 Portfile lacks a depends_run port:coreutils parameter line if I understand this correctly and according to the MacPorts Guide 5.4. Dependencies on dependencies to check before phases destroot and install.
I would presume this a general task to all maintainers.
comment:8 Changed 6 years ago by kencu (Ken)
it's more a build dep than a run dep AFAIK, so it should be added to the depends_build
list.
and then don't forget, try again, and see what comes next.
always clean between attempts.
comment:10 follow-up: 13 Changed 6 years ago by jmroot (Joshua Root)
@TP75 off-topic: your email setup seems to be strangely configured and is sending me a copy of all the notifications you receive from this ticket. So I end up getting two copies of everything, one directly from Trac and one from you.
comment:11 Changed 6 years ago by kencu (Ken)
I'll admit I just looked at this:
:info:destroot /bin/sh: /opt/macports-test1/bin/gmkdir: No such file or directory :info:destroot make[2]: *** [install-iconDATA] Error 1
looks like it needs actual sorting out I guess.
comment:12 Changed 6 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:13 Changed 6 years ago by TP75
Replying to jmroot:
@TP75 off-topic: your email setup seems to be strangely configured and is sending me a copy of all the notifications you receive from this ticket. So I end up getting two copies of everything, one directly from Trac and one from you.
Distribution of copies is the task of the mailing list, I presume?
The addresses of emails from the ticket system copied to my address look like:
From: MacPorts <noreply@macports.org> Cc: jmr@macports.org, macports-tickets@lists.macports.org, tp75-macports@vosdav.de Reply-To: macports-dev@lists.macports.org
Maybe you should update your subscription rules?
AFAIK my Trac Preferences on Notifications are just the default this forum provides to new users. However, I am sorry and being a newbie I may have overlooked something.
If instead you truly receive copies from my email server I would highly appreciate if you could send me directly a copy including all the headers.
https://bugs.squid-cache.org/show_bug.cgi?id=4903