Bug 1530 - apiscan fails using gcc 4.7
apiscan fails using gcc 4.7
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: python bindings
ns-3-dev
PC Linux
: P2 critical
Assigned To: Gustavo J. A. M. Carneiro
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-13 19:56 EST by alina
Modified: 2013-10-13 11:24 EDT (History)
3 users (show)

See Also:


Attachments
error output from ./waf --apiscan=all (253.60 KB, application/octet-stream)
2012-11-13 19:56 EST, alina
Details
output from ./waf --apiscan=all for Ubuntu 11.10 + gcc 4.6 (271.21 KB, application/octet-stream)
2012-11-14 14:02 EST, alina
Details
apiscan using lastest gccxml sources and gcc 4.7 (255.80 KB, application/octet-stream)
2012-11-20 10:11 EST, alina
Details
apiscan output from point-to-point module for latest git tip of gccxml (May 2, 2013) (50.51 KB, text/plain)
2013-05-05 17:16 EDT, Tom Henderson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description alina 2012-11-13 19:56:03 EST
Created attachment 1466 [details]
error output from ./waf --apiscan=all

Scanning python bindings fails for ns-3-dev on Debian Wheezy with gcc 4.7.
The error output from the waf apiscan command is attached.
Please let me know how can I help to debug this.


steps to reproduce the problem:

$ hg clone http://code.nsnam.org/ns-3-allinone ns-3-allinone-bind
$ cd ns-3-allinone-bind/
$ ./download.py -n ns-3-dev
$ ./build.py
$ ./waf --apiscan=all


system information:

$ cat /etc/issue
Debian GNU/Linux wheezy/sid \n \l

$ uname -a
Linux casandra 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux

$ python --version
Python 2.7.3rc2

$ gcc --version
gcc (Debian 4.7.1-7) 4.7.1

$ gccxml --version
GCC-XML version 0.9.0
Comment 1 alina 2012-11-14 14:02:58 EST
Created attachment 1467 [details]
output from ./waf --apiscan=all for Ubuntu 11.10 + gcc 4.6
Comment 2 alina 2012-11-14 14:05:57 EST
I did some more testing and apiscan also fails with gcc 4.6.1 under Ubuntu 11.10 (output file attached). However it seems to work with gcc 4.5.1 under Fedora 14.

So I am guessing I ran into pitfall [1], and this bug is related to the unmaintained gccxml and not to a bug introduced in ns-3/pybindgen. If this is the case, please close this bug report.

[1]  http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings#GCC-XML_on_newer_systems
Comment 3 Tom Henderson 2012-11-20 01:12:00 EST
there seems to be some activity in gccxml project recently:
https://github.com/gccxml/gccxml/commits/master

would you mind having a look whether their git repo is any better for us, using gcc-4.7?
Comment 4 alina 2012-11-20 10:11:27 EST
Created attachment 1474 [details]
apiscan using lastest gccxml sources and gcc 4.7
Comment 5 alina 2012-11-20 10:13:18 EST
(In reply to comment #3)
> there seems to be some activity in gccxml project recently:
> https://github.com/gccxml/gccxml/commits/master
> 
> would you mind having a look whether their git repo is any better for us,
> using gcc-4.7?

I tested the problem with the latest gccxml sources from the repo (git clone git://github.com/gccxml/gccxml.git) and I get the same errors than with the package distributed in debian (the version is still 0.9.0 in both).
Attachment 3 [details] contains the output of the apiscan.
Comment 6 alina 2012-11-20 10:14:28 EST
Sorry, it is attachment 1474 [details].
Comment 7 Vedran Miletić 2013-05-05 11:37:30 EDT
Recent changes mention support for GCC 4.8:

commit 567213ac765c99d5dfd23b14000b3c7b76274fcb
Author: Brad King <brad.king@kitware.com>
Date:   Thu May 2 09:43:43 2013 -0400

    Update GCC 4.8 headers to work with gccxml's GCC 4.2 parser
    
    Port changes from commit 16190d39 (Update GCC 4.7 headers...,
    2012-03-09) to GCC 4.8 headers:
    
    * In (|e|x)mmintrin.h remove the function bodies that use builtins not
      provided by the GCC 4.2 parser.  The declarations are sufficient for
      our needs anyway.
    
    * In <complex> remove assignment operator implementations that use
      conversions the older GCC parser does not recognize.
    
    * In <iomanip> remove use of initializer lists.
    
    * In <bits/stl_*> remove use of decltype.
    
    * In <ext/atomicity.h> replace use of atomic builtins with older GCC
      names.
    
    Inspired-by: Mattias Ellert <mattias.ellert@fysast.uu.se>

commit 875b2c14f309fa254f531584a62c1bd01e84ce58
Author: Brad King <brad.king@kitware.com>
Date:   Thu May 2 09:35:33 2013 -0400

    Add GCC 4.8 original headers

commit c77c7a96b650081d17d2c91869fcd21cfbceb769
Author: Brad King <brad.king@kitware.com>
Date:   Thu May 2 09:32:59 2013 -0400

    Override GCC 4.8 <bits/c++config.h> to disable __int128

commit 5755031e3f899b329802b93c30fcd86cf9a0e417
Author: Brad King <brad.king@kitware.com>
Date:   Thu May 2 09:28:55 2013 -0400

    Add gccxml_builtins.h for GCC 4.8 starting with 4.7 version

commit 0edc4e4c9398bcda51c5f6c0f46323cb7ae8011a
Author: Brad King <brad.king@kitware.com>
Date:   Thu May 2 09:35:02 2013 -0400

    Tell Git to skip whitespace checks in GCC_XML/Support/GCC
    
    This directory contains third-party code so add a .gitattributes file to
    tell Git not to check it for whitespace style.

Can anyone test this?
Comment 8 Tom Henderson 2013-05-05 17:13:29 EDT
(In reply to comment #7)
> Recent changes mention support for GCC 4.8:
> 
<snip>
> 
> Can anyone test this?

I tested this today on Ubuntu 13.04 64-bit machine.

I am observing the following, which is the same behavior as from before this newest git changeset:

(1) there are still some errors similar to what Alina previously reported (will upload a new attachment), but it is sometimes able to make progress afterwards (unlike apiscan_task failure in Alina's output), and can rescan the 64-bit bindings successfully

(2) it does not create both 64- and 32-bit bindings; it deletes both upon start, but only restores the 64-bit version.

I removed a few modulegen__gcc_LP64.py files (e.g. csma, point-to-point, antenna) and it was able to recreate them successfully before hanging, when only that module was selected; e.g.
./waf --apiscan=csma

However, I then removed all instances of modulegen__gcc_LP64.py in src/ and did a
./waf --apiscan=all

and I got a failure similar to Alina's:

Build failed
 -> task in '' failed (exit status 1): 
	{task 'apiscan_task': 55396624 }
''
 -> task in '' failed (exit status 1): 
	{task 'apiscan_task': 55396816 }
''
 -> task in '' failed (exit status 1): 
	{task 'apiscan_task': 55396688 }
''
 -> task in '' failed (exit status 1): 
	{task 'apiscan_task': 55396752 }
Comment 9 Tom Henderson 2013-05-05 17:16:48 EDT
Created attachment 1589 [details]
apiscan output from point-to-point module for latest git tip of gccxml (May 2, 2013)

Ubuntu 13-04 64-bit, gcc-4.7.3
Comment 10 Tom Henderson 2013-05-10 02:19:17 EDT
moving to p2 critical; needs fixing
Comment 11 Gustavo J. A. M. Carneiro 2013-10-13 11:24:14 EDT
I can confirm that API scanning works again on a modern Ubuntu system.  Steps:

  1. Grab and install gccxml from github master: https://github.com/gccxml/gccxml

  2. If you are running ubuntu 64-bits, you need to install these packages: gcc-4.7-multilib g++-4.7-multilib

Then scanning works (apart from the issue of not terminating waf cleanly).

The reason why Tom got that error was due to the missing multilib support in gcc (see step 2).

I am going to update the wiki page with this information.

Then the only other issue was a small bug in pybindgen for handling the "bool const &" type, fixed in pybindgen trunk revno 834.