(
Jump to the original submission)
Fri 10 Feb 2017 04:27:35 PM UTC, comment #8:
Thanks for all your work and feedback !
Just pushed a commit to fix this.
|
Fri 10 Feb 2017 11:53:51 AM UTC, comment #7:
Yes, using LIB<NAME> instead of LTLIB<NAME> worked. And indeed, according to the gnulib manual, the LTLIB<NAME> was intended for linking with libtool.
https://www.gnu.org/software/gnulib/manual/html_node/Searching-for-Libraries.html
|
Fri 10 Feb 2017 09:04:24 AM UTC, comment #6:
Please explain what makes you think it was that commit.
If it is, could you change
$(LTLIBICONV) $(LTLIBINTL) $(LTLIBTHREAD)
into
$(LIBICONV) $(LIBINTL) $(LIBTHREAD)
and test again ?
The LT prefix should be no harm when not using libtool, but who knows...
|
Fri 10 Feb 2017 07:00:10 AM UTC, comment #5:
Digging further, this was probably caused by the commit adding LTLIBICONV to LDADD for wget
|
Fri 10 Feb 2017 05:13:29 AM UTC, comment #4:
The error happened with wget-1.19 vanilla tarball.
The -R option was probably from m4/lib-link.m4 (search for "-R$found_dir" in that file) and according from the comment there, it was intended for libtool.
That macro in m4/lib-link.m4 was imported by the AM_ICONV macro in configure.ac
Below is the related snippet in the generated src/Makefile after configure run
Note that I have those wget dependency libs including libiconv-1.14 in a non-standard location ~/.usr/
This should be reproducible with the following steps
- clone the build-scripts git repo
- remove the do_patch func in build-wget.sh
- remove the PKG_AUTOCONF_FIXUP=1 in build-wget.sh
- "make wget/install/test" will build do the download, compile, install is test_dir/ without polluting system-level settings.
|
Thu 09 Feb 2017 11:32:02 AM UTC, comment #3:
Wget does/should not use libtool.
The -R option seems to be a linker (ld) option, the whole issue is not reproducible here (also GNU/Linux).
Please attach config.log and all the exact steps (tarball/git, bootstrap, configure, etc) plus the output.
|
Thu 09 Feb 2017 07:07:33 AM UTC, comment #2:
Patching configure.ac to use libtool with AC_PROG_LIBTOOL fixed the link issue for me, though I had to also patch the m4/po.m4 file to workaround the gettext version check.
The patch hunks are available at https://github.com/yousong/build-scripts/blob/683ff79878665fd1a422c4f9a8fddf2fd30be718/build-wget.sh. Feel free to pick them if they suit your needs ;)
|
Thu 09 Feb 2017 03:16:35 AM UTC, comment #1:
Sorry, 1.17.1 was intended as a comparison instead of 1.18.
|
Thu 09 Feb 2017 03:14:16 AM UTC, original submission:
With 1.19
With 1.18
The problem is that I build my own copy of wget and its dependencies and install them into a non-standard location. The build system of wget incorrectly thought that libtool was used and specified the library location with -R which gcc did not understand and erred.
The script I am using is available at https://github.com/yousong/build-scripts/blob/master/build-wget.sh
|
(Note: upload size limit is set to 16384 kB, after insertion of the required
escape characters.)
Attach File(s):
Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Follow 4 latest changes.