GNOME Bugzilla – Bug 635662
Failed to parse project: Malformed project
Last modified: 2010-11-26 21:16:59 UTC
Whenever trying to open or create a new project, I get the following error dialog: "Failed to parse project (the project is opened, but there will be no project view) ....../anjuta/foobar-cpp: Malformed project" The project itself is created/opened, and I can continue as normal. The main issue is all items in the Project menu are now unavailable (as Anjuta does not think a project is open), so I am unable to access the project properties to do things such as add a library, ie. libwnck. I am trying to move from python to C++, so am still not very familiar with configure and makefiles etc. to add the dependency manually. Running from a terminal and creating a project produces the following output: "** (anjuta:5317): WARNING **: Child process returned no data (anjuta:5317): libanjuta-symbol-db-WARNING **: SQL select exec failed: SELECT symbol.symbol_id, symbol.name, symbol.file_position, symbol.scope_definition_id, symbol.signature, symbol.returntype, symbol.type_type, symbol.type_name, file.file_path, sym_access.access_name, sym_kind.is_container FROM symbol LEFT JOIN file ON (symbol.file_defined_id = file.file_id) LEFT JOIN sym_access ON (symbol.access_kind_id = sym_access.access_kind_id) LEFT JOIN sym_kind ON (symbol.kind_id = sym_kind.sym_kind_id) WHERE ((symbol.scope_id = 0) AND (symbol.kind_id IN (SELECT sym_kind_id FROM sym_kind WHERE ((0 = 0) AND (sym_kind.kind_name IN ('class', 'struct', 'union', 'enum'))) OR ((0 != 0) AND (sym_kind.kind_name != 'namespace'))))) OR (symbol.symbol_id IN (SELECT symbol_id FROM symbol WHERE (symbol.scope_id = 0) AND (symbol.kind_id IN (SELECT sym_kind_id FROM sym_kind WHERE sym_kind.kind_name = 'namespace')) GROUP BY symbol.scope_definition_id)) ORDER BY symbol.name ASC LIMIT 2147483647 OFFSET 0, no such table: symbol (anjuta:5317): libanjuta-project-manager-CRITICAL **: iproject_manager_get_elements: assertion `IANJUTA_IS_PROJECT (plugin->project)' failed (anjuta:5317): libanjuta-symbol-db-CRITICAL **: No sources found within this project" Cheers.
Which version of anjuta are you using? (2.3.x is unlikely, should be 2.32.x or 2.30.x). It would also be interesting what kind of project you are creating using the project wizard and if the project was created successfully. Please also check that you have the "autogen" utility installed. Thanks!
My apologies. I am using V 2.32.1. I have autogen 5.9.9 installed on an Arch linux system. I have tried creating a generic C++ project, a generic C project and a generic python project. All generate the same error. The project itself is created. I can edit all the files and even build and run the project. See the following link for a screenshot: http://imagebin.org/124778 (image available online until 8 Dec 2010) As you can see, the error dialog is there, but you can also see the project files in the file browser window. In the project window, no projects are listed, and as you can see from the screenshot, the project menu is completely unavailable. Cheers.
Thanks for your feedback! I have no real idea why this happens. Two things that come into my mind: * The project directory you are using is somewhat non-standard (like a NFS directory, using non-ASCII characters, etc.). But I don't think that's the case. * Something in your perl installation is missin. The (old) project-parser uses perl scripts to parse the project which might fail if you haven't installed certain perl modules. Have you seen the dialog where you can choose between different project backends? It should come up when you first create a project at least. If yes, which backend die you choose. Could you attach a tar.gz of the project created? Thanks!
Created attachment 175291 [details] Default project files generated via Anjuta
To address your points: The project directory is local to the pc, definitely not nfs, but you knew that already :) and the path/file name is standards compliant (no spaces or special chars) Searching for installed perl packages on my system generates a huge list, so it seems unlikely a missing module is the cause (of course it is still possible, but I would need further info on what modules are required before I can rule this out) I have not seen the project backend dialog before, but playing around today, when I try to import a project, I do get that dialog (I selected autotools - and checked for this choice to be remembered). The import generates the same error, but autotools is now permanently selected in the preferred plugins tab of Anjuta preferences. I removed autotools from my preferred plugins, and tried again, this time selecting directory backend, and all worked perfectly (project is now listed and I have access to the project menu). After this success, I tried creating a new project, failed with the same error, so it appears I can work around the issue by creating a project, exiting and then importing it. As this happens with every project I try to create, I have attached a tar.gz (created from the Build > Build Tarball menu option) of the default "Helo World" C++ app that is generated. Cheers
(In reply to comment #5) > I removed autotools from my preferred plugins, and tried again, this time > selecting directory backend, and all worked perfectly (project is now listed > and I have access to the project menu). The directory backend is completely different. It doesn't read any project files but just list all files in the project directory then consider some of them as source based on their extensions. > As this happens with every project I try to create, I have attached a tar.gz > (created from the Build > Build Tarball menu option) of the default "Helo > World" C++ app that is generated. I have tried here with anjuta 2.32.1 and I have no problem to open your project. The project manager will be rewritten for the next version but I'm curious to know why you get such issue. The autotools project backend use a perl script to parse the project. You can run it directly. It is installed in the same directory than anjuta (/usr/local/bin typically). Could you attached the output of the following command here: gbf-am-parse -d -v --get _your_project_directory_ The output in a xml representation of the project which is then parsed by anjuta.
Running the command gbf-am-parse -d -v --get <project_directory> fails as below: [padfoot@******** ~]$ gbf-am-parse -d -v --get /mnt/data/Projects/anjuta/default/ Can't locate Locale/gettext.pm in @INC (@INC contains: /usr/share/anjuta /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl /usr/lib/perl5/site_perl/5.10.1 /usr/share/perl5/site_perl/5.10.1 /usr/lib/perl5/current /usr/lib/perl5/site_perl/current .) at /usr/bin/gbf-am-parse line 21. BEGIN failed--compilation aborted at /usr/bin/gbf-am-parse line 21. And checking I have gettext installed: [padfoot@******* ~]$ yaourt -Q perl-gettext community/perl-gettext 0.01-5 [padfoot@******* ~]$ yaourt -Q gettext core/gettext 0.18.1.1-1 (base) Of course, no xml output is generated.
(In reply to comment #7) > And checking I have gettext installed: > [padfoot@******* ~]$ yaourt -Q perl-gettext > community/perl-gettext 0.01-5 > [padfoot@******* ~]$ yaourt -Q gettext > core/gettext 0.18.1.1-1 (base) > Of course, no xml output is generated. It looks like you miss the Locale/gettext.pm package. Could you check if you have such file using find? (find / -name gettext.pm) I have here a gettext.pm in a directory named Locale. The package here is named perl-Locale-gettext. So perhaps it's different from your perl-gettext package. Or perhaps the gettext.pm file is not in the right place.
That also means that your fellow Arch packager didn't work correctly because when building anjuta from sources it checks for that module. Please also file a bug against Arch.
find / -name gettext.pm produces nothing. I searched all the paths listed above manually and I found gettext.pm in /usr/share/perl5/vendor_perl/Gettext.pm I symlinked this to /usr/share/per5/vendor_perl/Locale/gettext.pm Now executing gbf-am-parse -d -v --get <project_directory> produces: [padfoot@******* ~]$ gbf-am-parse -d -v --get /mnt/data/Projects/anjuta/default/ Undefined subroutine &main::textdomain called at /usr/bin/gbf-am-parse line 24. So I am guessing I haven't symlinked the correct gettext.pm file? Good to see that it appears to be just a packaging error. Filing a bug against arch. Cheers
SOLVED: I was indeed missing the perl-locale-gettext package. All is working now. Thankyou so much for working through this with me. I will recommend the Arch packagers link this package as a dependency for perl-gettext. Cheers.
Thanks for taking the time to track this down. I am sure this will be helpful for other Arch users.