| Summary: | Trouble with multiarch-dispatch.h: #include nested too deeply | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Denis Bitouzé <dbitouze> |
| Component: | RPM Packages | Assignee: | All Packagers <pkg-bugs> |
| Status: | REOPENED --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia |
| Version: | Cauldron | Keywords: | Triaged |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | MGA5TOO | ||
| Source RPM: | multiarch-utils-1.0.13-3.mga4.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Denis Bitouzé
2013-09-22 18:13:16 CEST
Manuel Hiebel
2013-09-27 21:33:32 CEST
Keywords:
(none) =>
Triaged Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad Status:
NEW =>
RESOLVED This bug is still alive in Mageia 4: Description of problem: Whereas I don't encounter any trouble with another Linux distributions, with Mageia 4 and its multiarch-utils distribution, I stumbled upon the following error: multiarch-dispatch.h:74:56: error: #include nested too deeply when running the Plone unified installer Plone-4.3.4-UnifiedInstaller (Plone isn't packaged by Mageia and using the unified installer is the recommended way of doing). Version-Release number of selected component (if applicable): multiarch-utils-1.0.13-3 How reproducible: Every time I attempt to install Plone via the Plone-4.3.4-UnifiedInstaller Steps to Reproduce: As a normal (non-root) user, run (as recommended in http://plone.org/documentation/manual/installing-plone/installing-on-linux-unix-bsd/running-the-unified-installer): ######################################################################################### wget https://launchpad.net/plone/4.3/4.3.4/+download/Plone-4.3.4-UnifiedInstaller.tgz tar xfz Plone-4.3.4-UnifiedInstaller.tgz cd Plone-4.3.4-UnifiedInstaller/ ./install.sh standalone ######################################################################################### You'll see the following messages (with, of course, another installation directories than /home/bitouze/Plone and /home/bitouze/InstallationsLocales): ######################################################################################### Testing /usr/bin/python2.7 for Zope/Plone requirements.... /usr/bin/python2.7 looks OK. We'll try to use it. Rootless install method chosen. Will install for use by system user bitouze Detailed installation log being written to /home/bitouze/InstallationsLocales/Plone-4.3.4-UnifiedInstaller/install.log Installing Plone 4.3.4 at /home/bitouze/Plone Creating python virtual environment, no site packages. New python executable in /home/bitouze/Plone/Python-2.7/bin/python2.7 Also creating executable in /home/bitouze/Plone/Python-2.7/bin/python Installing Setuptools....................................................................................................................................................................done. Installing Pip...............................................................................................................................................................................................................................................done. Skipping libjpeg build Unpacking buildout cache to /home/bitouze/Plone/buildout-cache Copying Plone-docs Copying buildout skeleton Fixing up bin/buildout Building Zope/Plone; this takes a while... Buildout returned an error code: 1; Aborting. Buildout failed. Unable to continue Installation has failed. See the detailed installation log at /home/bitouze/InstallationsLocales/Plone-4.3.4-UnifiedInstaller/install.log to determine the cause. ######################################################################################### Looking at the (long) install.log file, you'll see the following message (in your language): 1. at line 303 (among others): ######################################################################################### /usr/include/multiarch-dispatch.h:74:56: error: #include nested too deeply ######################################################################################### 2. at line 1111 (among others): ######################################################################################### /home/bitouze/Plone/Python-2.7/include/multiarch-i386-linux/python2.7/pyconfig.h:2:32: error: #include nested too deeply ######################################################################################### and another errors I don't know if they are related to this trouble: libImaging/ImPlatform.h:14:2: erreur: #error Sorry, this library requires support for ANSI prototypes. libImaging/ImPlatform.h:17:2: erreur: #error Sorry, this library requires ANSI header files. libImaging/ImPlatform.h:55:2: erreur: #error Cannot find required 32-bit integer type In file included from _imaging.c:77:0: libImaging/Imaging.h:90:5: erreur: unknown type name âINT32â libImaging/Imaging.h:264:16: erreur: unknown type name âINT32â libImaging/Imaging.h:264:16: erreur: unknown type name âINT32â libImaging/Imaging.h:395:15: erreur: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âImagingCRC32â _imaging.c: In function âgetlistâ: _imaging.c:406:10: erreur: âINT32â undeclared (first use in this function) _imaging.c:406:10: note: each undeclared identifier is reported only once for each function it appears in _imaging.c:411:25: erreur: expected expression before â)â token _imaging.c:418:25: erreur: expected expression before â)â token _imaging.c: In function âgetpixelâ: _imaging.c:470:7: erreur: unknown type name âINT32â _imaging.c: In function âgetinkâ: _imaging.c:558:11: erreur: âINT32â undeclared (first use in this function) _imaging.c:558:17: erreur: expected expression before â)â token _imaging.c: In function â_histogramâ: _imaging.c:989:9: erreur: unknown type name âINT32â _imaging.c: In function â_pointâ: _imaging.c:1152:9: erreur: unknown type name âINT32â _imaging.c:1164:48: erreur: âINT32â undeclared (first use in this function) _imaging.c: In function â_putdataâ: _imaging.c:1295:22: erreur: âINT32â undeclared (first use in this function) _imaging.c:1322:49: erreur: expected expression before â)â token _imaging.c: In function â_getextremaâ: _imaging.c:1822:9: erreur: unknown type name âINT32â _imaging.c: In function â_draw_inkâ: _imaging.c:2266:5: erreur: unknown type name âINT32â _imaging.c: In function â_crc32â: _imaging.c:2797:12: erreur: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âcrcâ _imaging.c:2797:12: erreur: âcrcâ undeclared (first use in this function) _imaging.c:2804:13: erreur: expected â)â before âINT32â error: Setup script exited with error: command 'gcc' failed with exit status 1 Reproducible: Steps to Reproduce: Status:
RESOLVED =>
REOPENED Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/ This bug is still alive in Mageia 5 with exactly the same errors. Version:
4 =>
5 Assigning to all packagers collectively since the multiarch-utils has no registered maintainer. Version:
5 =>
Cauldron |