Run Coccinella on 64 bit systems

Bug #380289 reported by rain
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

It's about running Coccinela on 64-bit systems and errors like "tkpng package is required for the GUI" or similar (for example

1. in lib/Init.tcl find and replace these strings:
 } elseif {$tcl_platform(machine) eq "x86_64"} {
     # x86_64
     set machine "i686"
 } elseif {$tcl_platform(machine) eq "x86_64"} {
     # x86_64
     set machine "x86_64"

2. Create the following directories

3. Download and compile TkTreeCtrl and TkPNG:

4. Put compiled libs into appropriate directories

5. Copy pkgIndex.tcl:
bin/unix/Linux/i686/tkpng/pkgIndex.tcl -> bin/unix/Linux/x86_64/tkpng/pkgIndex.tcl
bin/unix/Linux/i686/treectrl/pkgIndex.tcl -> bin/unix/Linux/x86_64/treectrl/pkgIndex.tcl

6. Replace the version of libraries in pkgIndex.tcl to the correct values

In attachment precompiled libraries for x86_64
Tested on Debian GNU/Linux amd64 Lenny 5.0.1.

Tags: amd64
Revision history for this message
rain (linuxoid-rain) wrote :
Revision history for this message
sander (s-devrieze) wrote :

Do you think people would be interested in 64bit binaries of Coccinella? If yes, the build script possibly can be updated to support such binaries:

PS: I don't have a 64bit desktop system; I only have access to a 64 bit server I am not able to test these binaries...

Revision history for this message
rain (linuxoid-rain) wrote :

Yes, i think it will be useful. I'm not sure about necessity of full static builds, but Coccinella can't run without 64 bit libraries on pure 64 bit desktops.

buzzdee (sebastia)
Changed in coccinella:
milestone: none → 0.96.20
Revision history for this message
buzzdee (sebastia) wrote :

With the tkpng and treectrl installed that you provided on my openSUSE 11.1 x86_64 Box, my coccinella starts up.
But this is just for the basic startup required, to get all the features, you probably would need to install more stuff.

For opensuse, there are no rpms available for treectrl nor tkpng, I only have rpms available for:
Those I found on if they are not in the main distribution sets. However, besides the missing tktreectrl or tkpng there is no:


for iaxclient I have libiaxclient1 rpm available, but this only installs /usr/lib64/, but unfortunately not the tcliaxclient library.

for tkpng I found a rpm there for centos_5.

How is the availability for dependent packages on Debian?

Maybe instead of bloating the coccinella source tree with a lot of binaries, it would be more clever to create an account on the opensuse build service, and create those missing packages for the distributions available there. This is not only *SUSE/SLES. In the OpenSUSE build service there can be packages built for the main distributions:

For people using other distributions, there we have to keep the manual on how to build the third party dependencies.

Sander, any objections on this one?

Revision history for this message
sander (s-devrieze) wrote :

The source tarball indeed maybe better can include only the source code of the libraries (or even only a README??). However, for the binary distributions of Coccinella, and in particular the daily build binaries, I think it is important to include the binary libraries:
1. It should be as easy as possible for people to test Coccinella without the need to compile or install anything.
2. Running Coccinella from a (multi-platform) USB stick should be easy.

Maybe our daily build system can be fed with the OpenSUSE binaries?

"How is the availability for dependent packages on Debian?"

I'll forward you an old email from Miriam Ruiz. She uploaded some dependencies to Debian long time ago. I'm not sure if this is still up to date.

Revision history for this message
buzzdee (sebastia) wrote :

Yes, for the binaries, at least which we provide already, we should keep everything as is.

But for people wanting to run Coccinella from source, it is a bit cumbersome to compile all needed dependencies manually. Especially the tktreectrl which needs the private header file from TK, that also took me some time to figure this out...

So I think when we could provide rpm and deb packages for the distributions available there, for the dependencies, and released versions, that would be a great thing for the "ordinary" end user to install coccinella.
Also for possible companies wanting to use coccinella they may prefer installing via "usual" system packages, or may even have a policy that nothing else gets installed...

Revision history for this message
sander (s-devrieze) wrote : Re: [Bug 380289] Re: Run Coccinella on 64 bit systems

The deb packages and rpm's are a good idea, but I think we should
start with providing patches and README's in the repository for people
to compile the binaries themselves.

Revision history for this message
v_2e (v-2e) wrote :

  I am a GGL user. ("GGL" stands for "Gentoo GNU/Linux" - just in case :) ). And I had the same problem trying to run Coccinella on my amd64 machine. In my case this problem had been successfully solved by simply removing the following folders:

But still there were some problems (with sound, with tray icon, etc.), which also had been successfully solved by simply removing the following directories:
        /bin/unix/Linux/i686/tktray (solved the tray problem)
        /bin/unix/Linux/i686/snack2.2 (solved the sound problem)

Deleting the following catalogs didn't make any noticeable changes, but I decided to delete them too since I have the same libraries installed natively in my system.

  So as I have understood, for all the Coccinella's functions to work properly (including the possibility to run Coccinella at all), one needs all the packages which are present in "/bin/unix/i686" folder to be installed in the system natively (correct binaries for the host's architecture) and not to use the "bundled" libraries, because the x86 emulation on amd64, for example, doesn't always work correctly.
  Well, I hope, this information at least a bit useful for somebody. :)
  Thanks and good luck!


Revision history for this message
buzzdee (sebastia) wrote :

I changed the code as suggested in the initial report.
The only thing that I am not sure what happens is with running the 32 Bit binary on a x86_64 bit environment.
Will test and see what happens with the next breakfast release.

If that still works, then I'll remove the whole if/else clause as it becomes useless.
If not, I'll need to detect whether coccinella is run from a starkit, and change the path then to the i386 subdirectory, when running from source it should look into the directory whatever matches the machine architecture or use the packages provided from the system.

Changed in coccinella:
status: New → In Progress
Revision history for this message
buzzdee (sebastia) wrote :

With above changes, the 32 Bit Linux binaries were unable to find the packages. With svn revision 2843 I added a check for ::starkit::topdir, in case it exists, then use the i686 path, otherwise when running from source the x86_64.

Revision history for this message
buzzdee (sebastia) wrote :

after the last change the 32Bit Linux binary is working again on 64Bit system.

Revision history for this message
buzzdee (sebastia) wrote :

I think this one can also be considered as closed?

Revision history for this message
sander (s-devrieze) wrote :

Possibly: I still lack a 64 bit system to test.

Revision history for this message
buzzdee (sebastia) wrote :

Downloaded the binary and the source version, both run on 64Bit, thought the Source version needs the required tcl libraries installed in the system as they are not provided with Coccinella.
However, the binary does not connect my Asterisk, the Phone and Addressbook tab do not open.
The source version does, maybe probably a problem with the used iaxclient lib?

Since it generally works, closing this one.

Changed in coccinella:
status: In Progress → Fix Committed
sander (s-devrieze)
Changed in coccinella:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.