Summary: | app-text/enchant-1.6.1-r1: libtool: error: specify a tag with '--tag' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | alexander, anton.gubarkov, base-system, chris, dev, dwjwilson, ivan, lssndrbarbieri, marc_heimann, qa, sam, StormByte, toolchain, zbox |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 243502, 408963 | ||
Attachments: |
app-text:enchant-1.6.1:20170906-102914.log
Add "--tag=CC" to LIBTOOL in configure script Adds tag to libtool link build.log |
Description
Michał Górny
2017-09-06 10:33:29 UTC
(CC-ing libtool maintainers since this looks crazy) configure: loading site script /usr/local/share/config.site maybe ? Nope, fails just the same. Actually, it seems to be unhappy about CC: ./configure CC=x86_64-pc-linux-gnu-gcc-5.4.0 -> FAIL ./configure CC=x86_64-pc-linux-gnu-gcc -> FAIL ./configure CC=gcc -> PASS ./configure --host=x86_64-pc-linux-gnu -> PASS So my guess is that hyphens in ${CC} (but not implicitly derived CC) confuse the hell out of it. (In reply to Michał Górny from comment #4) > Actually, it seems to be unhappy about CC: > ./configure CC=x86_64-pc-linux-gnu-gcc -> FAIL yep, and: ./configure CC=x86_64-pc-linux-gnu-gcc OBJC=x86_64-pc-linux-gnu-gcc -> PASS there is a .m file in src/, libtool then links in objective-c mode; my guess would be that you either need to set matching OBJC/CXX/CC or rely on --host and not set anything Does this mean that building Enchant requires an objective C compiler even though we never use the ObjC sources? (In reply to Michał Górny from comment #6) > Does this mean that building Enchant requires an objective C compiler even > though we never use the ObjC sources? I hit this problem and, although I didn't figure out how to fix it properly, I found that after the build failed initially I could then edit the Makefile in the src sub-directory as per: # diff -u src/Makefile.dist src/Makefile --- src/Makefile.dist 2017-09-06 22:14:18.419237710 +0100 +++ src/Makefile 2017-09-06 22:15:23.812305807 +0100 @@ -150,7 +150,7 @@ am__v_lt_ = $(am__v_lt_$(AM_DEFAULT_VERBOSITY)) am__v_lt_0 = --silent am__v_lt_1 = -libenchant_la_LINK = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \ +libenchant_la_LINK = $(LIBTOOL) $(AM_V_lt) --tag=cxx $(AM_LIBTOOLFLAGS) \ $(LIBTOOLFLAGS) --mode=link $(OBJCLD) $(AM_OBJCFLAGS) \ $(OBJCFLAGS) $(libenchant_la_LDFLAGS) $(LDFLAGS) -o $@ AM_V_P = $(am__v_P_$(V)) and then finish things manually with the usual ebuild command and appropriate arguments. Interestingly, the compile would run to completion after 'ebuild enchant-1.6.1.ebuild unpack'ing the code and then running ./configure and make manually, i.e. without the portage-configured baggage. (In reply to Michał Górny from comment #6) > Does this mean that building Enchant requires an objective C compiler even > though we never use the ObjC sources? That's what AC_PROG_OBJC in configure.ac does, yes. If we're going to leave it this way, I suppose we need to extend our documentation and eclasses for OBJC. It's certainly not a variable most of the people would set, and it's not supported by toolchain-funcs.eclass. (In reply to Michał Górny from comment #9) > If we're going to leave it this way, I suppose we need to extend our > documentation and eclasses for OBJC. It's certainly not a variable most of > the people would set, I don't think CC/CXX is a variable most people would set either. It can cause issues in various places. It appears as yellow in vim when I set it in make.conf, vs light blue for standard variables. > and it's not supported by toolchain-funcs.eclass. that's tc-getCC you should probably look at what gnustep is doing, it's a known heavy consumer of objective c. (In reply to Alexis Ballier from comment #10) > (In reply to Michał Górny from comment #9) > > If we're going to leave it this way, I suppose we need to extend our > > documentation and eclasses for OBJC. It's certainly not a variable most of > > the people would set, > > I don't think CC/CXX is a variable most people would set either. It can > cause issues in various places. It appears as yellow in vim when I set it in > make.conf, vs light blue for standard variables. Not setting it causes even more issues, you just choose to ignore them. Light blue is for variables known to be Portage stuff. Yellow is everything else. > > > and it's not supported by toolchain-funcs.eclass. > > that's tc-getCC Nope. tc-getCC doesn't respect OBJC. 'tc-export CC' does not export OBJC. Created attachment 510562 [details, diff]
Add "--tag=CC" to LIBTOOL in configure script
I just encountered this issue in my last sync/update cycle. I can add my emerge --info, make.conf, etc, if someone thinks it would be relevant.
After some searching with google, and some testing, I found that adding "--tag=CC" to $LIBTOOL in the configure script makes the problem go away.
I'm not sure how helpful that is given the previous discussion in these comments, but it seemed to work for me.
I've attached a patch to the bug, in case someone finds it helpful.
If I read this right, settings CC only on a project using OBJC is a user bug and there's nothing we can do as maintainers here, right ? @D. Wilson, that patch helped a lot, thanks. This should be fixed since enchant 1.x is pulled by e.g. Plasma Desktop/KDE. I installed a new system and compilation of this continuously failed, while it shouldn't. I don't know if this --tag=CC is only necessary under certain contitions, e.g. with a specific version of GCC or anything else. If so, this patch should only be added when the contitions are present, otherwise... Why not include this patch and add --tag=CC? I think that the ebuild should be fixed in the regard that it shouldn't fail on many users when a known fix is already available. As a sidenote I have to add that I see two contraditory pieces of information. 1) [ebuild R ] app-text/enchant-1.6.1::gentoo USE="aspell* hunspell -static-libs {-test} (-zemberek)" 0 KiB (-zemberek) indicates that zemberek isn't used, right? 2) build.log enchant-1.6.1 prefix: /usr compiler: gcc Build Aspell backend: yes Build Ispell backend: no Build Uspell backend: no Build Hspell backend: no Build Myspell/Hunspell backend: yes Build Voikko backend (Linux only): no Build Zemberek backend: yes Build Apple Spell backend (OS X only): no Build a relocatable library: no clearly states "Zemberek backend: yes" How is that possible? (In reply to Andreas Thalhammer from comment #14) > > clearly states "Zemberek backend: yes" > > How is that possible? I guess the use flag is masked, but configure is not called with that option explicitly disabled but it enabled it just because it found a functioning zemberek on your system. Is zemberek actually installed for some other reason? (In reply to Andreas Thalhammer from comment #14) > clearly states "Zemberek backend: yes" > > How is that possible? See bug 662484 gcc-8.2.0-r6 enchant-1.6.1-r1 Patch from comment 12 fixes the problem for me. (In reply to D. Wilson from comment #12) > Created attachment 510562 [details, diff] [details, diff] > Add "--tag=CC" to LIBTOOL in configure script > > I just encountered this issue in my last sync/update cycle. I can add my > emerge --info, make.conf, etc, if someone thinks it would be relevant. > > After some searching with google, and some testing, I found that adding > "--tag=CC" to $LIBTOOL in the configure script makes the problem go away. > > I'm not sure how helpful that is given the previous discussion in these > comments, but it seemed to work for me. > > I've attached a patch to the bug, in case someone finds it helpful. That fixes the problem for me too. Thanks. Created attachment 597946 [details, diff]
Adds tag to libtool link
This patch affects only Makefile.in to specify tag to libtool when linking libenchant.la, no other part of building is affected by this patch.
Workaround without code modifications: explicitly set variables CC and OBJC for 32-bit CC=i686-pc-linux-gnu-gcc OBJC=i686-pc-linux-gnu-gcc emerge -va1 app-text/enchant for 64-bit CC=x86_64-pc-linux-gnu-gcc OBJC=x86_64-pc-linux-gnu-gcc emerge -va1 app-text/enchant Variables CC and OBJC may be saved in files as described in https://wiki.gentoo.org/wiki/Debugging cat /etc/portage/tag # workaround libtool build bug https://bugs.gentoo.org/630072 # for 32-bit #CC=i686-pc-linux-gnu-gcc #OBJC=i686-pc-linux-gnu-gcc # for 64-bit CC=x86_64-pc-linux-gnu-gcc OBJC=x86_64-pc-linux-gnu-gcc cat /etc/portage/package.env/enchant # https://bugs.gentoo.org/630072 app-text/enchant tag sorry my mistake, in last comment replace "cat /etc/portage/tag" to "cat /etc/portage/env/tag" (In reply to David Carlos Manuelda from comment #19) > Created attachment 597946 [details, diff] [details, diff] > Adds tag to libtool link > > This patch affects only Makefile.in to specify tag to libtool when linking > libenchant.la, no other part of building is affected by this patch. That's a much better solution than the patch I provided. I have updated the enchant-1.6.1 ebuild I maintain in my overlay to use it instead of my original patch. Thank you for providing it. Interestingly, in 2017-12 enchant-1.6.1 failed to merge on all three of my gentoo systems because of this issue. Today, only one of them still needs it to be patched for this linking problem. I'm not sure what changed on the other two that makes the problem disappear, they all run the same hardened profile and more or less the same make.conf and use flags. The patched ebuild also works fine on all three. So whjat do I need to do to reproduce this? Set CC for some reason somewhere? *** Bug 669162 has been marked as a duplicate of this bug. *** I can still reproduce this issue on 1.6.1-r1. I have CC set in my make.conf. Following on comment #20, I think updating portage.env and create a special environment for this package is the simplest solution to work around this issue. I still don't really know how to reproduce the issue, but 1.6 should go away soon now, I hope. Created attachment 633870 [details]
build.log
build.log
@Mart Raudsepp just set CC in your make.conf e.g.: grep "CC" /etc/portage/make.conf CC="x86_64-pc-linux-gnu-gcc-9.3.0" I done this for distcc purpose, but if you compile on local machine, its also reproduce issue. tinderbox has reproduced this issue with version 1.6.1-r1 - Updating summary. Reproduced with app-text/enchant-1.6.1-r2. |