Opened 4 years ago
Closed 4 years ago
#62412 closed defect (fixed)
libidn2 configure fails: "autoreconf failure: command execution failed"
Reported by: | Wowfunhappy (Jonathan) | Owned by: | Schamschula (Marius Schamschula) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.4 |
Keywords: | Cc: | ||
Port: | libidn2 autoconf |
Description (last modified by Wowfunhappy (Jonathan))
Related to #62411? Maybe even the same fix?
:info:configure autoreconf: running: /opt/local/bin/gtkdocize --copy :info:configure Can't exec "/opt/local/bin/gtkdocize": No such file or directory at /opt/local/share/autoconf/Autom4te/FileUtils.pm line 293. :info:configure autoreconf: error: /opt/local/bin/gtkdocize failed with exit status: 1
Attachments (1)
Change History (13)
Changed 4 years ago by Wowfunhappy (Jonathan)
comment:1 Changed 4 years ago by Wowfunhappy (Jonathan)
Description: | modified (diff) |
---|
comment:2 Changed 4 years ago by kencu (Ken)
comment:3 Changed 4 years ago by kencu (Ken)
BTW, nothing to do with Leopard. Same error happens on BigSur:
glibtoolize: copying file 'm4/lt~obsolete.m4' autoreconf: configure.ac: not using Intltool autoreconf: running: /opt/local/bin/gtkdocize --copy Can't exec "/opt/local/bin/gtkdocize": No such file or directory at /opt/local/share/autoconf/Autom4te/FileUtils.pm line 293. autoreconf: error: /opt/local/bin/gtkdocize failed with exit status: 2 Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_mail_libidn2/libidn2/work/libidn2-2.3.0" && autoreconf -fvi Exit code: 2
comment:4 Changed 4 years ago by kencu (Ken)
Summary: | Configuring libidn2 fails on Leopard Intel: "autoreconf failure: command execution failed" → libidn2 configure fails: "autoreconf failure: command execution failed" |
---|
comment:6 Changed 4 years ago by kencu (Ken)
ah it is this 62405#comment:9
I guess we better get started adding a gtk-doc build dep to 1000 ports -- or add it as a run dep to autoconf, if the dep loops work out -- or change autoconf to the way it worked before.
One of those.
comment:7 follow-up: 8 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
gtk-doc depends on glib2 which depends on autoconf, therefore we can't have autoconf depend on gtk-doc. If we update glib2 to a newer version that builds with meson instead of autoconf (like glib2-devel already has been) then we could have autoconf depend gtk-doc. If autoconf will invoke gtkdocize all or most or much of the time, then we would probably want to add the dependency to autoconf.
comment:8 Changed 4 years ago by jmroot (Joshua Root)
Replying to ryandesign:
If autoconf will invoke gtkdocize all or most or much of the time, then we would probably want to add the dependency to autoconf.
It won't, only when the build system uses the relevant gtk-doc macros.
comment:9 follow-up: 11 Changed 4 years ago by jmroot (Joshua Root)
Owner: | set to Schamschula |
---|---|
Status: | new → assigned |
Why is this port running autoreconf in the first place?
comment:10 Changed 4 years ago by Wowfunhappy (Jonathan)
Just confirming that installing gtk-doc did indeed fix the issue on my own machine. :)
comment:11 Changed 4 years ago by Schamschula (Marius Schamschula)
Replying to jmroot:
Why is this port running autoreconf in the first place?
Simple: it was added with the initial commit by D. Evans. Apparently, no one ever tested it again (including myself).
I just did. On my Mojave machine I got a clean build.
comment:12 Changed 4 years ago by Schamschula (Marius Schamschula)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
clue:
I am not sure why this is showing up lately. There was another port recently with the same problem. Obviously something to be sorted out with autoreconf and gtk-doc.