| Summary: | app-emulation/wine-1.7.15 - configure:12922: In file included from conftest.c:184: /usr/include/jconfig.h:13:3: error: #error "abi_x86_32 not supported by the package." | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jamir Thapa <jbdrthapa> |
| Component: | Current packages | Assignee: | Wine Maintainers <wine> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arfrever.fta, disp.reg.bugs.gentoo, ivanhoe, mitaspiotr, multilib+disabled |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
Build amd64 log Build x86 log emerge info epatch log libjpeg links config.log emul-linux-x86.eclass.patch |
||
|
Description
Jamir Thapa
2014-05-04 16:34:11 UTC
Created attachment 376344 [details]
build.log
Created attachment 376346 [details]
Build amd64 log
Created attachment 376348 [details]
Build x86 log
Created attachment 376350 [details]
emerge info
Created attachment 376352 [details]
epatch log
Created attachment 376354 [details]
libjpeg links
Same here, but with different USE flags. Wine got flagged as a necessary rebuild when the app-emulation/emul-linux-x86-* upgraded to 20140406. However, it won't rebuild because it dies during configuration complaining about development files. In my case it couldn't find the libsane files due to the scanner USE flag. If I disable that, it dies because it can't find the v4l development files, and so on and so forth. Upgrading wine to the unstable 1.6.2 version gives the same config errors. OK, let's try to figure out in what way exactly this is invalid (cause most likely it is). Attach config.log mentioned in the build log. Created attachment 376380 [details]
config.log
Comment on attachment 376346 [details]
Build amd64 log
Why is this attached?
(In reply to Jamir Thapa from comment #9) > Created attachment 376380 [details] > x86 Config log /usr/include/jconfig.h:13:3: error: #error "abi_x86_32 not supported by the package." This looks like a mixup. Make sure abi_x86_32 is set on package providing virtual/jpeg (most likely libjpeg-turbo). Right, it seems that you didn't emerge some of wine's dependencies with ABI_X86="32 64". Please provide the output of the following command: # emerge -pv virtual/jpeg $(equery b -ne /usr/include/jconfig.h) (if you don't have equery, you will need to install app-portage/gentoolkit first) From your comment I was able to emerge wine successfully. Below is what I did. emerge -C emul* packages USE="abi_x86_32 abi_x86_64" emerge -avuDN world emerge wine (In reply to Alexandre Rostovtsev from comment #12) > Right, it seems that you didn't emerge some of wine's dependencies with > ABI_X86="32 64". Please provide the output of the following command: > > # emerge -pv virtual/jpeg $(equery b -ne /usr/include/jconfig.h) > > (if you don't have equery, you will need to install app-portage/gentoolkit > first) @multilib team, could it be that if libjpeg-turbo was installed with -abi_x86_32, then due wrapped headers, the 32-bit libjpeg from emul-linux-x86-baselibs becomes unusable for building? In this case, the baselibs package would need to override the wrapped header somehow... Jamir, to diagnose this, could you please explain - what version of libjpeg-turbo or media-libs/jpeg did you have originally when you encountered the problem, what version of emul-linux-x86-baselibs, and with what USE flags? (In reply to Alexandre Rostovtsev from comment #14) > @multilib team, could it be that if libjpeg-turbo was installed with > -abi_x86_32, then due wrapped headers, the 32-bit libjpeg from > emul-linux-x86-baselibs becomes unusable for building? In this case, the > baselibs package would need to override the wrapped header somehow... > > Jamir, to diagnose this, could you please explain - what version of > libjpeg-turbo or media-libs/jpeg did you have originally when you > encountered the problem, what version of emul-linux-x86-baselibs, and with > what USE flags? media-libs/libjpeg-turbo-1.3.1 USE="-java -static-libs" ABI_X86="(64) -32 (-x32)" media-libs/jpeg-8d-r1 USE="-static-libs" ABI_X86="(64) -32 (-x32)" app-emulation/emul-linux-x86-baselibs-20140406-r1 USE="development" ABI_X86="-32" Oh yes, that's one case I didn't think of when enabling wrapping globally. Though it proves that emul-linux had one more persistent breakage. One possible solution would be to, temporarily: 1. always force #include rather than #error for x86 -- then missing emul-linux/abi_x86_32 package would result in 'file not found', 2. supply wrapped headers in emul-linux. @Pacho, do you think that would be feasible? (In reply to Michał Górny from comment #16) > Oh yes, that's one case I didn't think of when enabling wrapping globally. > Though it proves that emul-linux had one more persistent breakage. > > One possible solution would be to, temporarily: > > 1. always force #include rather than #error for x86 -- then missing > emul-linux/abi_x86_32 package would result in 'file not found', > > 2. supply wrapped headers in emul-linux. > > @Pacho, do you think that would be feasible? Sorry but I don't follow the problem quite well (I am a bit lose in all this headers playing :( ) From what I understand: 1. Old style emul packages don't install headers (only a few exceptions). 2. I don't see how could we overwrite /usr/include/jconfig.h as it's provided by libjpeg-turbo ebuild 3. How /usr/include/jconfig.h was modified by wrapping on a setup running the old-style emul packages? Or is the wrapping needed in both cases? Thanks for the help :) Well, let's start the tale with some basics. Some packages tend to do ABI-specific substitutions in header files, like selecting types of certain length. As a result, header created on 32-bit system is different from header created on 64-bit system. To accommodate building packages for multilib, we need to have headers suitable for both systems. So whenever we know that headers are going to differ per ABI, we wrap them. Wrapping specifically involves moving the original files to ABI-specific locations, and replacing them with generic wrapper template. The template recognizes ABI used by compiler and #includes proper header, or #errors out if there's no header file for specific ABI. Now, what has changed. In the past, we were enabling wrapping only if more than 1 ABI was enabled. Now, we enable it unconditionally when it's supported by the architecture. This was meant to increase consistency. Take the following as an example. You're running a multilib system and building some package. In the past, if you built it: 1. ABI_X86=64, you get one un-wrapped header file that gets used by -m64, -m32 and -mx32 (although it is unsuited for the two latter and may result in runtime failures), 2. ABI_X86="32 64", you get two wrapped headers, -m64 and -m32 works, -mx32 errors out. After the change, case 1. only works with -m64, and errors out with -m32 and -mx32 consistently to case 2. Now, the problem is that emul-linux never cared about header wrapping. So even if x86 headers were different than amd64, it assumed that compiling with amd64 headers will work. With the late change in wrapping, the -m32 builds fail since there is no x86 header around. Now, I'd rather avoid reverting the whole change. I see a few possible work-arounds: 1. with ABI_X86='64 -32', make packages use amd64 header temporarily, 2. with ABI_X86='64 -32', install template like for ABI_X86='64 32' but without the header, and install the header in emul-linux. (1) requires change to the eclass, and rebuild of affected packages. (2) requires both + update of emul-linux to install /usr/include/i686-pc-linux-gnu/*.h (possibly copied from ABI_X86=32 system). As a note, after the change non-multilib x86 should also have that directory for consistency and easier profile switching. Ah, thanks a lot for the info. Then, what option do you prefer? :) (In reply to Pacho Ramos from comment #19) > Ah, thanks a lot for the info. > > Then, what option do you prefer? :) I would prefer the proper i686* approach requiring re-release of emul-linux. Although I should note that stable is affected, so you'd need to add the headers to all stable ebuilds. The other approach will work without touching stable stuff. I can try to simply bump the set and we can fast stabilize it (as will still take some fixes from current x86 stable that will surely help in other areas too). Let me try. I have just included this in 20140506 emul set. It's still hardmasked because I cannot finish all the work today (I am too tired now), anyway, you can play with headers from emul eclass as the new tarballs simply include headers in usr/include and, later, the eclass moves them to the dir we want (allowing more flexibility as it won't require to regenerate tarballs every time we need to change the headers location and so) Well, this certainly will take more than time than expected. For now, I've applied the other fix. Sorry that it took so long. + 07 May 2014; Michał Górny <mgorny@gentoo.org> multilib-build.eclass: + Use amd64 headers for i686 when USE=-abi_x86_32 to maintain compatibility + with current state of emul-linux. Fixes bug #509556. Code in emul-linux-x86.eclass now causes: >>> Install emul-linux-x86-baselibs-20140506 into /var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image/ category app-emulation mv: cannot move '/var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image//usr/include/i686-pc-linux-gnu' to a subdirectory of itself, '/var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image//usr/include/i686-pc-linux-gnu/./i686-pc-linux-gnu' >>> Completed installing emul-linux-x86-baselibs-20140506 into /var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image/ (In reply to Arfrever Frehtes Taifersar Arahesis from comment #24) > Code in emul-linux-x86.eclass now causes: > > >>> Install emul-linux-x86-baselibs-20140506 into /var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image/ category app-emulation > mv: cannot move > '/var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image//usr/ > include/i686-pc-linux-gnu' to a subdirectory of itself, > '/var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image//usr/ > include/i686-pc-linux-gnu/./i686-pc-linux-gnu' > >>> Completed installing emul-linux-x86-baselibs-20140506 into /var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image/ But the stuff that needs to be moved (everything but that subdir) is moved anyway. Other option would be to make two moves... but I guess will be worse for performance :/ Another problem: emul-linux-x86-medialibs-20140506.tar.xz contains usr/include/cdio and usr/include/i686-pc-linux-gnu/cdio directories. usr/include/cdio/cdio_config.h and usr/include/cdio/version.h are multilib wrappers. usr/include/i686-pc-linux-gnu/cdio/cdio_config.h and usr/include/i686-pc-linux-gnu/cdio/version.h contain target data. Error during src_install(): mv: cannot move '/var/tmp/portage/app-emulation/emul-linux-x86-medialibs-20140506/image//usr/include/cdio' to '/var/tmp/portage/app-emulation/emul-linux-x86-medialibs-20140506/image//usr/include/i686-pc-linux-gnu/cdio': Directory not empty Next app-emulation/emul-linux-x86-medialibs-20140506 fails due to collision with dev-libs/libcdio: * package app-emulation/emul-linux-x86-medialibs-20140506 NOT merged * * Detected file collision(s): * * /usr/include/cdio/udf.h * /usr/include/cdio/audio.h * /usr/include/cdio/ecma_167.h * /usr/include/cdio/sector.h * /usr/include/cdio/udf_file.h * /usr/include/cdio/cdio_config.h * /usr/include/cdio/device.h * /usr/include/cdio/posix.h * /usr/include/cdio/cdtext.h * /usr/include/cdio/ds.h * /usr/include/cdio/iso9660.h * /usr/include/cdio/types.h * /usr/include/cdio/mmc_ll_cmds.h * /usr/include/cdio/version.h * /usr/include/cdio/disc.h * /usr/include/cdio/dvd.h * /usr/include/cdio/bytesex_asm.h * /usr/include/cdio/utf8.h * /usr/include/cdio/mmc_cmds.h * /usr/include/cdio/cd_types.h * /usr/include/cdio/logging.h * /usr/include/cdio/rock.h * /usr/include/cdio/xa.h * /usr/include/cdio/udf_time.h * /usr/include/cdio/mmc.h * /usr/include/cdio/mmc_hl_cmds.h * /usr/include/cdio/mmc_util.h * /usr/include/cdio/bytesex.h * /usr/include/cdio/cdio.h * /usr/include/cdio/util.h * /usr/include/cdio/track.h * /usr/include/cdio/read.h * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * dev-libs/libcdio-0.92:0::gentoo * /usr/include/cdio/audio.h * /usr/include/cdio/bytesex_asm.h * /usr/include/cdio/cd_types.h * /usr/include/cdio/cdio_config.h * /usr/include/cdio/cdtext.h * /usr/include/cdio/device.h * /usr/include/cdio/disc.h * /usr/include/cdio/ds.h * /usr/include/cdio/dvd.h * /usr/include/cdio/ecma_167.h * /usr/include/cdio/iso9660.h * /usr/include/cdio/mmc_cmds.h * /usr/include/cdio/mmc_ll_cmds.h * /usr/include/cdio/posix.h * /usr/include/cdio/sector.h * /usr/include/cdio/types.h * /usr/include/cdio/udf.h * /usr/include/cdio/udf_file.h * /usr/include/cdio/utf8.h * /usr/include/cdio/version.h * * Package 'app-emulation/emul-linux-x86-medialibs-20140506' NOT merged * due to file collisions. If necessary, refer to your elog messages for * the whole content of the above message. That is known, it's due the removal of the "rm -Rf" command, but I am working on it now on a new set Created attachment 376562 [details, diff] emul-linux-x86.eclass.patch (In reply to Pacho Ramos from comment #25) > (In reply to Arfrever Frehtes Taifersar Arahesis from comment #24) > > Code in emul-linux-x86.eclass now causes: > > > > >>> Install emul-linux-x86-baselibs-20140506 into /var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image/ category app-emulation > > mv: cannot move > > '/var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image//usr/ > > include/i686-pc-linux-gnu' to a subdirectory of itself, > > '/var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image//usr/ > > include/i686-pc-linux-gnu/./i686-pc-linux-gnu' > > >>> Completed installing emul-linux-x86-baselibs-20140506 into /var/tmp/portage/app-emulation/emul-linux-x86-baselibs-20140506/image/ > > But the stuff that needs to be moved (everything but that subdir) is moved > anyway. Other option would be to make two moves... but I guess will be worse > for performance :/ The attached patch fixes "subdirectory of itself" problem by using only one move. Please move the discussion about the issues with new emul- set somewhere else. *** Bug 511614 has been marked as a duplicate of this bug. *** *** Bug 513474 has been marked as a duplicate of this bug. *** |
