Opened 7 years ago

Closed 2 years ago

#42728 closed defect (fixed)

autogen @5.17.4_0: autoopts-config produces a stray -R flag, breaks gnutls @3.1.22_0 build

Reported by: jwhowse4 Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: ryandesign (Ryan Schmidt), larryv (Lawrence Velázquez), jeremyhu (Jeremy Huddleston Sequoia), cooljeanius (Eric Gallager), dbevans (David B. Evans), Schamschula (Marius Schamschula), ballapete (Peter Dyballa)
Port: autogen gnutls

Description

I am using an Intel Mac Pro running Mac OS 10.8.5 (Mountain Lion) with XCode 5.0.2. When I try to upgrade to version 3.1.22 the build fails with the attached error log. Glancing through the log file I am not even sure why the build is failing. Any suggestions?

Attachments (11)

gnutls_main.log (621.4 KB) - added by jwhowse4 7 years ago.
gnutls build log
main.log (680.2 KB) - added by cooljeanius (Eric Gallager) 7 years ago.
diff between OP's main.log and my main.log for this build failure
gnutls_main.log.diff (935.4 KB) - added by cooljeanius (Eric Gallager) 7 years ago.
This one is actually the diff I thought I was uploading last time, the previous one was just my log
gnutls-3.3.3-main.log (314.8 KB) - added by dbevans (David B. Evans) 6 years ago.
Log showing build failure of gnutls 3.3.3 on 10.8.5.
Portfile-gnutls.diff (858 bytes) - added by Schamschula (Marius Schamschula) 6 years ago.
patch-gnutls-3.3.3.diff (963 bytes) - added by dbevans (David B. Evans) 6 years ago.
Patch to build correctly even if autogen is installed
patch-gnutls-3.3.3-rev1.diff (1.9 KB) - added by dbevans (David B. Evans) 6 years ago.
Revised Portfile based on comments plus a few more fixes
Portfile-gnutls.2.diff (2.2 KB) - added by Schamschula (Marius Schamschula) 6 years ago.
Portfile-gnutls.3.diff (2.6 KB) - added by Schamschula (Marius Schamschula) 6 years ago.
Portfile-gnutls.4.diff (2.6 KB) - added by Schamschula (Marius Schamschula) 6 years ago.
autogen-5.18.3.diff (1.5 KB) - added by ryandesign (Ryan Schmidt) 6 years ago.

Change History (56)

Changed 7 years ago by jwhowse4

Attachment: gnutls_main.log added

gnutls build log

comment:1 Changed 7 years ago by neverpanic (Clemens Lang)

:info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang  -pipe -Os -arch x86_64  -L/Volumes/User_Disk/opt/macports/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-certtool.la  libcmd_certtool_la-certtool-args.lo libcmd_certtool_la-certtool-cfg.lo ../gl/libgnu.la ../lib/libgnutls.la -R -L/Volumes/User_Disk/opt/macports/lib -lopts -L/Volumes/User_Disk/opt/macports/lib -lintl -R/Volumes/User_Disk/opt/macports/lib -Wl,-framework -Wl,CoreFoundation   -lintl 
:info:build mv -f .deps/serv.Tpo .deps/serv.Po
:info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang  -pipe -Os -arch x86_64  -L/Volumes/User_Disk/opt/macports/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-danetool.la  libcmd_danetool_la-danetool-args.lo libcmd_danetool_la-certtool-cfg.lo ../gl/libgnu.la ../lib/libgnutls.la -R -L/Volumes/User_Disk/opt/macports/lib -lopts -L/Volumes/User_Disk/opt/macports/lib -lintl -R/Volumes/User_Disk/opt/macports/lib -Wl,-framework -Wl,CoreFoundation   -lintl 
:info:build libtool: link: only absolute run-paths are allowed
:info:build make[4]: *** [libcmd-certtool.la] Error 1
:info:build make[4]: *** Waiting for unfinished jobs....
:info:build libtool: link: only absolute run-paths are allowed
:info:build make[4]: *** [libcmd-danetool.la] Error 1

Seems like there's a stray -R without an argument there that breaks the build.

comment:2 Changed 7 years ago by larryv (Lawrence Velázquez)

Keywords: mountainlion added
Owner: changed from macports-tickets@… to larryv@…
Status: newassigned
Summary: gnutls build failsgnutls @3.1.22_0: stray -R flags during build

I don’t currently have a Mountain Lion system to debug this on; if anyone submits a patch, I’ll be glad to apply it.

comment:3 Changed 7 years ago by wiml@…

I just hit this as well, on SnowLeopard. I think the underlying problem may be with autogen rather than gnutls:

  • The stray '-R' in gnutls' link command comes from LIBOPTS_LDADD
  • According to config.log, that variable was derived from autooopts-config:
configure:55587: checking whether autoopts-config can be found
configure:55594: checking whether autoopts-config is specified
configure:55605: result: autoopts-config
configure:55631: result:  -R -L/opt/local/lib -lopts

And in fact /opt/local/bin/autoopts-config ldopts or ldflags produces flags with the bogus '-R'. autoopts-config is part of the autogen package.

It looks like the gnutls port does not list autogen as a dependency; instead it contains its own copy which it uses iff there isn't an installed copy. So probably what's going on is that the macports autoopts-config is buggy, but the copy bundled with gnutls is not buggy. (Macports says my copy of autogen is autogen @5.17.4_0+universal.)

comment:4 Changed 7 years ago by jwhowse4

The autogen port is installed on my Mountain Lion system. When I deactivated autogen, the new gnutls builds and installs just fine. So on my system, wiml seems to have correctly diagnosed the problem.

comment:5 Changed 7 years ago by whcordis@…

Works for me as well.

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

Cc: ryandesign@… added
Keywords: mountainlion removed

I had the same problem on Mavericks; resolved by deactivating the autogen port.

comment:7 Changed 7 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… jeremyhu@… added
Owner: changed from larryv@… to mww@…
Port: autogen added
Status: assignednew
Summary: gnutls @3.1.22_0: stray -R flags during buildautogen @5.17.4_0: autoopts-config produces a stray -R flag, breaks gnutls @3.1.22_0 build

Has duplicate #42769.

comment:8 Changed 7 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

Changed 7 years ago by cooljeanius (Eric Gallager)

Attachment: main.log added

diff between OP's main.log and my main.log for this build failure

Changed 7 years ago by cooljeanius (Eric Gallager)

Attachment: gnutls_main.log.diff added

This one is actually the diff I thought I was uploading last time, the previous one was just my log

comment:9 Changed 7 years ago by cooljeanius (Eric Gallager)

So it looks like the short-term solution would be to use the conflicts_build 1.0 PortGroup to add "conflicts_build autogen" to the gnutls Portfile, while the long-term solution would be getting autogen upstream to fix their autoopts-config script. It may actually be fixed in a newer version if we update it:

Local-Admins-MacBook-Pro:dlcompat-20030629 ericgallager$ port -v livecheck autogen
autogen seems to have been updated (port version: 5.17.4, new version: 5.18.2)

but idk for sure about that... Edit: just tried updating the port myself; it fails to build, but the autoopts-config script still gets generated, and it still contains the stray -R flag. This can also be seen while running the configure script:

checking whether runtime library dirs can be specified... -R

which, more verbosely, looks like this in config.log:

configure:15979: checking whether runtime library dirs can be specified
configure:16001: result: -R

and ends up getting put in the following variables:

ag_cv_test_ldflags=-R
AG_LDFLAGS='-R'

The second one is subst'd into autoopts/autoopts-config.in here:

      ldopts="@AG_LDFLAGS@"

The conftest that substs it from the configure script comes from the AG_TEST_LDFLAGS macro in config/ag_macros.m4:

AC_DEFUN([AG_TEST_LDFLAGS],[
  AC_MSG_CHECKING([whether runtime library dirs can be specified])
  AC_CACHE_VAL([ag_cv_test_ldflags],[
    ag_cv_test_ldflags=`exec 2> /dev/null
echo 'int main() { return 0; }' > conftest.$ac_ext
libs="${LIBS}"
LIBS="${LIBS} -Wl,-R/tmp"
if (eval $ac_link) > /dev/null 2>&1
then echo '-Wl,-R${libdir}' ; rm -f conftest* ; exit 0 ; fi
LIBS="${libs} -R/tmp"
if (eval $ac_link) > /dev/null 2>&1
then echo '-R' ; rm -f conftest* ; exit 0 ; fi
rm -f conftest* ; exit 1`
    if test $? -ne 0 || test -z "$ag_cv_test_ldflags"
    then ag_cv_test_ldflags=no
    fi
  ]) # end of CACHE_VAL of ag_cv_test_ldflags
  AC_MSG_RESULT([${ag_cv_test_ldflags}])
  if test "X${ag_cv_test_ldflags}" != Xno
  then
    AG_LDFLAGS="@S|@{ag_cv_test_ldflags}"
  else
    AG_LDFLAGS=''
  fi
  AC_SUBST([AG_LDFLAGS])

]) # end of AC_DEFUN of AG_TEST_LDFLAGS

So the thing following the -R is supposed to be either ${libdir} or /tmp... I wonder why ${libdir} does not get used properly? Anyways I guess I will have to ask upstream...

Last edited 7 years ago by cooljeanius (Eric Gallager) (previous) (diff)

comment:10 Changed 7 years ago by cooljeanius (Eric Gallager)

Reported upstream: https://sourceforge.net/p/autogen/bugs/157/

Interestingly, while I was submitting the upstream bug report, I found that I had a manually-built copy of autogen installed in /usr/local, and it does not experience this problem:

Local-Admins-MacBook-Pro:autogen-5.18.2 ericgallager$ which -a autoopts-config
/opt/local/bin/autoopts-config
/usr/local/bin/autoopts-config
/opt/local/bin/autoopts-config
Local-Admins-MacBook-Pro:autogen-5.18.2 ericgallager$ autoopts-config --libs
 -R -L/opt/local/lib -lopts
Local-Admins-MacBook-Pro:autogen-5.18.2 ericgallager$ /usr/local/bin/autoopts-config --libs
 -R/usr/local/lib -L/usr/local/lib -lopts

So I am guessing that I must have specified libdir manually when I built my other copy...

comment:11 Changed 7 years ago by bkorb@…

if (eval $ac_link) > /dev/null 2>&1
then echo '-R' ; rm -f conftest* ; exit 0 ; fi

That's what looks dodgy to me. I think that should be:

if (eval $ac_link) > /dev/null 2>&1
then echo '-R${libdir}' ; rm -f conftest* ; exit 0 ; fi

I guess I don't use linkers that use that syntax. If that fix works, it will be in the next release. Thanks!

comment:12 Changed 7 years ago by basmac

Having same or similar problem with 10.8.5 build ?

  593  port clean gnutls

  594  port -d upgrade gnutls


info:build libtool: link: ( cd ".libs" && rm -f "libcmd-ocsp.la" && ln -s "../libcmd-ocsp.la" "libcmd-ocsp.la" )
:info:build libtool: link: ar cru .libs/libcmd-cli-debug.a .libs/libcmd_cli_debug_la-cli-debug-args.o
:info:build libtool: link: ( cd ".libs" && rm -f "libcmd-serv.la" && ln -s "../libcmd-serv.la" "libcmd-serv.la" )
:info:build libtool: link: ( cd ".libs" && rm -f "libcmd-psk.la" && ln -s "../libcmd-psk.la" "libcmd-psk.la" )
:info:build libtool: link: ranlib .libs/libcmd-cli.a
:info:build libtool: link: ranlib .libs/libcmd-cli-debug.a
:info:build libtool: link: ( cd ".libs" && rm -f "libcmd-cli-debug.la" && ln -s "../libcmd-cli-debug.la" "libcmd-cli-debug.la" )
:info:build libtool: link: ( cd ".libs" && rm -f "libcmd-cli.la" && ln -s "../libcmd-cli.la" "libcmd-cli.la" )
:info:build make[4]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64/src'
:info:build make[3]: *** [all-recursive] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64/src'
:info:build make[2]: *** [all] Error 2
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64/src'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/work/gnutls-3.1.22-x86_64" && /usr/bin/make -j8 -w all
:info:build Exit code: 2
:error:build org.macports.build for port gnutls returned: command execution failed
:debug:build Error code: NONE
:debug:build Backtrace: command execution failed
    while executing
"$procedure $targetname"
:info:build Warning: targets not executed for gnutls: org.macports.install org.macports.build org.macports.destroot
:notice:build Please see the log file for port gnutls for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gnutls/gnutls/main.log
bash-3.2#
Last edited 7 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:13 in reply to:  11 Changed 7 years ago by cooljeanius (Eric Gallager)

Replying to bkorb@…:

if (eval $ac_link) > /dev/null 2>&1
then echo '-R' ; rm -f conftest* ; exit 0 ; fi

That's what looks dodgy to me. I think that should be:

if (eval $ac_link) > /dev/null 2>&1
then echo '-R${libdir}' ; rm -f conftest* ; exit 0 ; fi

I guess I don't use linkers that use that syntax. If that fix works, it will be in the next release. Thanks!

Yup, it worked for me. Thanks!

(I would attach a patch, but I made some other changes to the file that might be irrelevant...)

comment:14 Changed 7 years ago by ryandesign (Ryan Schmidt)

Has duplicate #43212.

comment:15 Changed 6 years ago by neverpanic (Clemens Lang)

I assume this still happens with gnutls 3.3.3 as well?

comment:16 Changed 6 years ago by dbevans (David B. Evans)

Yes, build fails as follows with OS X 10.8.5, Xcode 5.1.1:

libtool: link: ( cd ".libs" && rm -f "libcmd-ocsp.la" && ln -s "../libcmd-ocsp.la" "libcmd-ocsp.la" )
/bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang   -pipe -Os -arch x86_64  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-certtool.la  certtool-args.lo certtool-cfg.lo ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la -R -L/opt/local/lib -lopts -L/opt/local/lib -lintl -R/opt/local/lib -Wl,-framework -Wl,CoreFoundation  gl/libgnu_gpl.la   -lintl 
/bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang   -pipe -Os -arch x86_64  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-danetool.la  danetool-args.lo certtool-cfg.lo ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la -R -L/opt/local/lib -lopts -L/opt/local/lib -lintl -R/opt/local/lib -Wl,-framework -Wl,CoreFoundation    -lintl 
libtool: link: only absolute run-paths are allowed
make[4]: *** [libcmd-certtool.la] Error 1
make[4]: *** Waiting for unfinished jobs....
libtool: link: only absolute run-paths are allowed
make[4]: *** [libcmd-danetool.la] Error 1

Full log attached.

Changed 6 years ago by dbevans (David B. Evans)

Attachment: gnutls-3.3.3-main.log added

Log showing build failure of gnutls 3.3.3 on 10.8.5.

comment:17 Changed 6 years ago by dbevans (David B. Evans)

Cc: devans@… mschamschula@… added

CCing myself and new gnutls maintainer

comment:18 Changed 6 years ago by dbevans (David B. Evans)

See also #43866.

comment:19 Changed 6 years ago by jwhowse4

I get essentially the same error log with a different installation directory. Deactivating autogen allows me to install gnutls 3.3.3 successfully.

Last edited 6 years ago by jwhowse4 (previous) (diff)

comment:20 in reply to:  19 Changed 6 years ago by Schamschula (Marius Schamschula)

Replying to jwhowse4@…:

I get essentially the same error log with a different installation directory. Deactivating autogen allows me to install gnutls 3.3.3 successfully.

I think this may be the problem.

I have built gnutls 3.3.3 on my my non-MacPorts build systems under 10.7.5 and 10.8.5. I don't recall ever using autoconf. I will have to research where and why autoconf was inserted into the Portfile.

Last edited 6 years ago by Schamschula (Marius Schamschula) (previous) (diff)

comment:21 Changed 6 years ago by Schamschula (Marius Schamschula)

I just built gnutls 3.3.3 without the autogen under Mavericks 10.9.3. I also noticed a missing dependency from my non-MacPorts systems: unbound. Please test the attached Portfile patch on Lion and Mountain Lion (I don't have access to MacPorts systems with these OSs).

Changed 6 years ago by Schamschula (Marius Schamschula)

Attachment: Portfile-gnutls.diff added

comment:22 Changed 6 years ago by dbevans (David B. Evans)

Note that although gnutls builds using autotools (autoconf, automake, etc), it does not depend on the package autogen but apparently tries to use it if it is installed and it is when it just happens to be installed (say as a dependency of some other port) that the build fails. For instance, anjuta requires autogen.

So the question seems to be how to disable the use of (external) autogen in gnutls or failing that how to fix autogen so it doesn't break the build.

comment:23 Changed 6 years ago by dbevans (David B. Evans)

By the way, the reason the port uses autoreconf (to rebuild the configuration files) is contained in this commit

r110322 | jeremyhu@macports.org | 2013-08-29 15:32:59 -0700 (Thu, 29 Aug 2013) | 2 lines

gnutls: autoreconf to get glibtool to know how to handle -stdlib

Copying jeremyhu for any further comments.

comment:24 Changed 6 years ago by dbevans (David B. Evans)

Attached is an alternate patch that fixes the build with port autogen installed and active (or at least works for me on 10.8.5).

It uses --enable-local-libopts to ask gnutls to use it's private (local) version of libopts rather than looking for the version supplied by autogen. This is the default behavior when autogen is not active so it provides uniform behavior in both cases.

Have also added the dependency on unbound which enables DNSSEC, DANE support.

Changed 6 years ago by dbevans (David B. Evans)

Attachment: patch-gnutls-3.3.3.diff added

Patch to build correctly even if autogen is installed

comment:25 Changed 6 years ago by neverpanic (Clemens Lang)

While that looks good to me, shouldn't we still fix the stray -R in the output of autoopts-config?

I'm also wondering whether adding the unbound dependency by default is a good idea, since it increases the dependency footprint of gnutls (and a lot of ports that use it).

comment:26 in reply to:  25 Changed 6 years ago by dbevans (David B. Evans)

Replying to cal@…:

While that looks good to me, shouldn't we still fix the stray -R in the output of autoopts-config?

Indeed (oops, that's this ticket). However, if this course is relied upon then perhaps a dependency on autogen should be added so that the same library is used in all installations. The libopts library is static only and not installed by gnutls by default so there is no activation conflict between the two. Note that the -R problem is not limited to autoopts-config but also occurs in autoopts.pc. My suggested approach decouples gnutls from the autogen problem.

I'm also wondering whether adding the unbound dependency by default is a good idea, since it increases the dependency footprint of gnutls (and a lot of ports that use it).

If it isn't added then a means to disable DNSSEC support needs to be added so that opportunistic configuration doesn't occur. A +dnssec variant could then be added to enable DNSSEC support for those that want it (e.g. me).

Last edited 6 years ago by dbevans (David B. Evans) (previous) (diff)

Changed 6 years ago by dbevans (David B. Evans)

Revised Portfile based on comments plus a few more fixes

comment:27 Changed 6 years ago by dbevans (David B. Evans)

Attached is a revised version of my patch file that addresses some of cal's comments as well as a few more fixes.

I've left the port configured to use the local instance of libopts rather than port autogen for the following reasons:

  • in most instances (since the only dependent of autogen is anjuta) this is the default configuration
  • therefore, the configuration uses the same instance of libopts for all installations
  • makes the solution of gnutls problem independent of the autogen one (which still needs to be fixed)
  • fewer dependencies

I've disabled the building of libdane by default in favor of a +dane variant which enables this support using unbound.

While testing, I saw that the output of configure concludes as follows:

configure: System files:

  Trust store pkcs11:
  Trust store file:
  Blacklist file:
  CRL file:
  Priority file:        /etc/gnutls/default-priorities
  DNSSEC root key file: /etc/unbound/root.key

configure: WARNING:
***
*** The DNSSEC root key file in /etc/unbound/root.key was not found.
*** This file is needed for the verification of DNSSEC responses.
*** Use the command: unbound-anchor -a "/etc/unbound/root.key"
*** to generate or update it.
***

The revised port includes configuration items that properly set the defaults for the priority file and the DNSSEC root key file to use the MacPorts prefix. In addition, notes are added if the +dane variant is selected and the default DNSSEC root key file does not exist, explaining how to create it using the command 'unbound-anchor'. This is just the text from the end of configure which is generally invisible to the end user.

Port unbound currently does not create this key file during installation or when running the unbound daemon (#43881).

Finally, I note that there is no default path for the following files:

 Trust store pkcs11
 Trust store file
 Blacklist file
 CRL file

This doesn't necessarily break gnutls, it just means that the dependent package needs to specify these file paths programmatically when needed. There are corresponding configuration items for these defaults which might be set to something reasonable for a default configuration but I'm not sure at the moment what these might be and whether that is really necessary or not.

comment:28 Changed 6 years ago by neverpanic (Clemens Lang)

Double checking I think it is a good idea to provide a +dane variant, since (a) DANE is (unfortunately) still not very widely used and (b) unbound depends on openssl, which would lead to the ironic situation of gnutls depending on openssl. Of course, this is the new maintainer's call in the end.

I agree with your handling of the autogen dependency (i.e., using the local libopts).

As for the trust store file, should we set that to the path of curl-ca-bundle or the file generated by certsync, i.e. $prefix/etc/openssl/cert.pem? Is the trust store format expected by GnuTLS compatible with the one used by OpenSSL? Pending further work on the followup to certsync we don't have a PKCS11 module, so that should stay empty for now.

comment:29 in reply to:  28 ; Changed 6 years ago by Schamschula (Marius Schamschula)

Replying to cal@…:

Double checking I think it is a good idea to provide a +dane variant, since (a) DANE is (unfortunately) still not very widely used and (b) unbound depends on openssl, which would lead to the ironic situation of gnutls depending on openssl. Of course, this is the new maintainer's call in the end.

I just checked the dependencies for unbound, and indeed unbound depends on openssl (and expat). I think we may want to move unbound into a variant, making it an optional install.

I agree with your handling of the autogen dependency (i.e., using the local lib opts).

Same here.

As for the trust store file, should we set that to the path of curl-ca-bundle or the file generated by certsync, i.e. $prefix/etc/openssl/cert.pem? Is the trust store format expected by GnuTLS compatible with the one used by OpenSSL? Pending further work on the followup to certsync we don't have a PKCS11 module, so that should stay empty for now.

I think using the curl-ca-bundle is a good idea, however, this makes for another dependency.

comment:30 in reply to:  29 Changed 6 years ago by dbevans (David B. Evans)

Replying to mschamschula@…:

Replying to cal@…:

Double checking I think it is a good idea to provide a +dane variant, since (a) DANE is (unfortunately) still not very widely used and (b) unbound depends on openssl, which would lead to the ironic situation of gnutls depending on openssl. Of course, this is the new maintainer's call in the end.

I just checked the dependencies for unbound, and indeed unbound depends on openssl (and expat). I think we may want to move unbound into a variant, making it an optional install.

Done in my most recent patch, +dane variant, since it is only necessary for DANE functionality. Default build does not depend on unbound.

I agree with your handling of the autogen dependency (i.e., using the local lib opts).

Same here.

As for the trust store file, should we set that to the path of curl-ca-bundle or the file generated by certsync, i.e. $prefix/etc/openssl/cert.pem? Is the trust store format expected by GnuTLS compatible with the one used by OpenSSL? Pending further work on the followup to certsync we don't have a PKCS11 module, so that should stay empty for now.

I think using the curl-ca-bundle is a good idea, however, this makes for another dependency.

I wouldn't worry about dependencies too much. I think the primary goal is full functionality without the user having to make too many technical decisions. Will leave this part to you as maintainer, see

./configure --help 

in ${worksrcpath} for the appropriate configuration options. Again this is only a default and will be over-ridden if the calling application desires to do so. So may not be terribly important. A review of how the various dependents handle this might be useful down the road. Let me or cal know when you think things are ready to commit.

comment:31 Changed 6 years ago by dbevans (David B. Evans)

Now about autogen ...

comment:32 in reply to:  1 ; Changed 6 years ago by ballapete (Peter Dyballa)

Replying to cal@…:

:info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang  -pipe -Os -arch x86_64  -L/Volumes/User_Disk/opt/macports/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-certtool.la  libcmd_certtool_la-certtool-args.lo libcmd_certtool_la-certtool-cfg.lo ../gl/libgnu.la ../lib/libgnutls.la -R -L/Volumes/User_Disk/opt/macports/lib -lopts -L/Volumes/User_Disk/opt/macports/lib -lintl -R/Volumes/User_Disk/opt/macports/lib -Wl,-framework -Wl,CoreFoundation   -lintl 
:info:build mv -f .deps/serv.Tpo .deps/serv.Po
:info:build /bin/sh ../libtool  --tag=CC   --mode=link /usr/bin/clang  -pipe -Os -arch x86_64  -L/Volumes/User_Disk/opt/macports/lib -Wl,-headerpad_max_install_names -arch x86_64 -o libcmd-danetool.la  libcmd_danetool_la-danetool-args.lo libcmd_danetool_la-certtool-cfg.lo ../gl/libgnu.la ../lib/libgnutls.la -R -L/Volumes/User_Disk/opt/macports/lib -lopts -L/Volumes/User_Disk/opt/macports/lib -lintl -R/Volumes/User_Disk/opt/macports/lib -Wl,-framework -Wl,CoreFoundation   -lintl 
:info:build libtool: link: only absolute run-paths are allowed
:info:build make[4]: *** [libcmd-certtool.la] Error 1
:info:build make[4]: *** Waiting for unfinished jobs....
:info:build libtool: link: only absolute run-paths are allowed
:info:build make[4]: *** [libcmd-danetool.la] Error 1

I see a similar failure on PPC Tiger, Mac OS X 10.4.11:

libtool: compile:  /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I.. -I./gl -I./../gl -I./gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libdane/includes -I./../extra/includes -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -MT certtool-cfg.lo -MD -MP -MF .deps/certtool-cfg.Tpo -c certtool-cfg.c  -fno-common -DPIC -o .libs/certtool-cfg.o
certtool-cfg.c: In function 'get_rand_int_value':
certtool-cfg.c:1104: warning: right shift count >= width of type
/bin/sh ../libtool  --tag=CC   --mode=link /opt/local/bin/gcc-apple-4.2   -pipe -Os -arch ppc  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -o libcmd-certtool.la  certtool-args.lo certtool-cfg.lo ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la -R -L/opt/local/lib -lopts -L/opt/local/lib -lintl -R/opt/local/lib -Wl,-framework -Wl,CoreFoundation  gl/libgnu_gpl.la   -lintl 
libtool: link: only absolute run-paths are allowed
make[4]: *** [libcmd-certtool.la] Error 1

comment:33 Changed 6 years ago by ballapete (Peter Dyballa)

Cc: Peter_Dyballa@… added

Cc Me!

comment:34 in reply to:  32 Changed 6 years ago by dbevans (David B. Evans)

Replying to Peter_Dyballa@…:

Replying to cal@…: I see a similar failure on PPC Tiger, Mac OS X 10.4.11:

libtool: compile:  /opt/local/bin/gcc-apple-4.2 -DHAVE_CONFIG_H -I. -I.. -I./gl -I./../gl -I./gl -I./../gl -I./../lib/includes -I./../lib/includes -I./../libdane/includes -I./../extra/includes -I/opt/local/include -I/opt/local/include -pipe -Os -arch ppc -MT certtool-cfg.lo -MD -MP -MF .deps/certtool-cfg.Tpo -c certtool-cfg.c  -fno-common -DPIC -o .libs/certtool-cfg.o
certtool-cfg.c: In function 'get_rand_int_value':
certtool-cfg.c:1104: warning: right shift count >= width of type
/bin/sh ../libtool  --tag=CC   --mode=link /opt/local/bin/gcc-apple-4.2   -pipe -Os -arch ppc  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -o libcmd-certtool.la  certtool-args.lo certtool-cfg.lo ../lib/libgnutls.la gl/libgnu_gpl.la ../gl/libgnu.la -R -L/opt/local/lib -lopts -L/opt/local/lib -lintl -R/opt/local/lib -Wl,-framework -Wl,CoreFoundation  gl/libgnu_gpl.la   -lintl 
libtool: link: only absolute run-paths are allowed
make[4]: *** [libcmd-certtool.la] Error 1

Can you try the latest proposed patch for gnutls from this ticket and let us know if that fixes the problem?

Thanks

comment:35 Changed 6 years ago by dbevans (David B. Evans)

I see this morning that the latest version of gnutls is now 3.3.4.

comment:36 in reply to:  35 ; Changed 6 years ago by Schamschula (Marius Schamschula)

Replying to devans@…:

I see this morning that the latest version of gnutls is now 3.3.4.

I've merged patch-gnutls-3.3.3-rev1.diff​ with the version bump to 3.3.4, with some minor edits. I have only built the +unbound variant under Mavericks. Please test!

Last edited 6 years ago by Schamschula (Marius Schamschula) (previous) (diff)

Changed 6 years ago by Schamschula (Marius Schamschula)

Attachment: Portfile-gnutls.2.diff added

comment:37 in reply to:  36 ; Changed 6 years ago by dbevans (David B. Evans)

Replying to mschamschula@…:

Replying to devans@…:

I see this morning that the latest version of gnutls is now 3.3.4.

I've merged patch-gnutls-3.3.3-rev1.diff​ with the version bump to 3.3.4, with some minor edits. I have only built the +unbound variant under Mavericks. Please test!

gnutls, gnutls +dane both build successfully on 10.8, 10.9. 10.7 should build as well since it uses a similar version of clang. I was also able to build successfully using the apple-gcc-4.2 compiler to simulate compilation on 10.6.

A trivial confidence test using danetool from the +dane build also works successfully.

danetool --check www.freebsd.org --proto tcp --port 443
Querying www.freebsd.org (tcp:443)...
_443._tcp.www.freebsd.org. IN TLSA ( 03 00 01 3f86a1fa85f6e5169cb27bf25c863805ebfd3225a16aadb75587804680992096 )
Certificate usage: Local end-entity (03)
Certificate type:  X.509 (00)
Contents:          SHA2-256 hash (01)
Data:              3f86a1fa85f6e5169cb27bf25c863805ebfd3225a16aadb75587804680992096

$ danetool --check www.fedoraproject.org --proto tcp --port 443
Querying www.fedoraproject.org (tcp:443)...
_443._tcp.www.fedoraproject.org. IN TLSA ( 00 00 01 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0 )
Certificate usage: CA (00)
Certificate type:  X.509 (00)
Contents:          SHA2-256 hash (01)
Data:              19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0

Based on this, I think the updated port could be committed as is unless you want to add a default trust store file to configure.args as suggested by cal.

--with-default-trust-store-file="${prefix}/etc/openssl/cert.pem"

in which case you would also need a dependency something like this

depends_run  path:etc/openssl/cert.pem:certsync

comment:38 in reply to:  37 Changed 6 years ago by Schamschula (Marius Schamschula)

Replying to devans@…:

Replying to mschamschula@…:

Replying to devans@…:

I see this morning that the latest version of gnutls is now 3.3.4.

I've merged patch-gnutls-3.3.3-rev1.diff​ with the version bump to 3.3.4, with some minor edits. I have only built the +unbound variant under Mavericks. Please test!

gnutls, gnutls +dane both build successfully on 10.8, 10.9. 10.7 should build as well since it uses a similar version of clang. I was also able to build successfully using the apple-gcc-4.2 compiler to simulate compilation on 10.6.

A trivial confidence test using danetool from the +dane build also works successfully.

danetool --check www.freebsd.org --proto tcp --port 443
Querying www.freebsd.org (tcp:443)...
_443._tcp.www.freebsd.org. IN TLSA ( 03 00 01 3f86a1fa85f6e5169cb27bf25c863805ebfd3225a16aadb75587804680992096 )
Certificate usage: Local end-entity (03)
Certificate type:  X.509 (00)
Contents:          SHA2-256 hash (01)
Data:              3f86a1fa85f6e5169cb27bf25c863805ebfd3225a16aadb75587804680992096

$ danetool --check www.fedoraproject.org --proto tcp --port 443
Querying www.fedoraproject.org (tcp:443)...
_443._tcp.www.fedoraproject.org. IN TLSA ( 00 00 01 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0 )
Certificate usage: CA (00)
Certificate type:  X.509 (00)
Contents:          SHA2-256 hash (01)
Data:              19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0

Based on this, I think the updated port could be committed as is unless you want to add a default trust store file to configure.args as suggested by cal.

--with-default-trust-store-file="${prefix}/etc/openssl/cert.pem"

in which case you would also need a dependency something like this

depends_run  path:etc/openssl/cert.pem:certsync

It turns out that the trust store file is in the .crt format provided by the curl-ca-bundle. I've added this to the .3.diff file.

Changed 6 years ago by Schamschula (Marius Schamschula)

Attachment: Portfile-gnutls.3.diff added

comment:39 Changed 6 years ago by dbevans (David B. Evans)

OK but the /opt/local part of the file name needs to be replaced with ${prefix} as not all installations use /opt/local for the prefix. Shall I commit it with that modification? The gnutls part of the issue of this ticket has been fixed.

comment:40 in reply to:  39 Changed 6 years ago by Schamschula (Marius Schamschula)

Replying to devans@…:

OK but the /opt/local part of the file name needs to be replaced with ${prefix} as not all installations use /opt/local for the prefix. Shall I commit it with that modification? The gnutls part of the issue of this ticket has been fixed.

Yup! It occurred to me after I got to bed last night...

Revised version, .4.diff uploaded.

Last edited 6 years ago by Schamschula (Marius Schamschula) (previous) (diff)

Changed 6 years ago by Schamschula (Marius Schamschula)

Attachment: Portfile-gnutls.4.diff added

comment:41 Changed 6 years ago by dbevans (David B. Evans)

gnutls 3.3.4 update committed in r120701 with a few modifications:

  • reset revision to 0 since this is the first commit of 3.3.4
  • change default path to unbound root key file to conform to recent changes in unbound (r120660 #43881)
  • update related comments, notes

Any further gnutls issues should be handled in a separate ticket.

The remaining issue of this ticket is that autogen @5.17.4_0 autoopts-config, autoopts.pc add a -R flag to ldflags that may break other ports.

comment:42 Changed 6 years ago by neverpanic (Clemens Lang)

We should probably update autogen to get rid of this: http://sourceforge.net/p/autogen/bugs/157/.

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

Here is a patch to update the autogen port to 5.18.3. It does not build for me:

In file included from ag.c:7:
In file included from ./autogen.h:60:
In file included from /opt/local/include/libguile.h:33:
In file included from /opt/local/include/libguile/async.h:26:
In file included from /opt/local/include/libguile/root.h:27:
/opt/local/include/libguile/throw.h:94:47: error: '_Noreturn' can only appear on functions
extern SCM scm_ithrow (SCM key, SCM args, int _Noreturn);
                                              ^

The problem seems to be that guile's headers use noreturn as an argument name in a function, but autogen #defines noreturn to something else. Perhaps autogen 5.18.3 is designed for a newer version of guile. Our ticket to update the guile port is #29307.

Changed 6 years ago by ryandesign (Ryan Schmidt)

Attachment: autogen-5.18.3.diff added

comment:44 Changed 4 years ago by mf2k (Frank Schima)

Owner: mww@… deleted
Status: newassigned

See #53012.

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

Resolution: fixed
Status: assignedclosed

autogen was updated to 5.18.4 in r129638. See #42749.

Note: See TracTickets for help on using tickets.