Ubuntu

--onlytop does not work

Reported by Jules Colding on 2006-10-17
8
Affects Status Importance Assigned to Milestone
orbit2 (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

orbit-idl-2 has an option "--onlytop" that enables it to to produce correct output when compiling IDL files that #include's other IDL files. Packages such as evolution-brutus (http://www.omesc.com/) does this.

The "--onlytop" option does not work when using libIDL and ORBit2 as distributed to Edgy users by Synaptic. Strangely enough, when using apt-get to retrieve the source and installing from source, it works. So I honestly can't tell exactly where the bug is. It is not a bug in the source of libIDL or ORBit2 but somehow related to the packaging.

Best regards,
  jules

Jules Colding (colding) wrote :

This post will explain in details how to work around the bug:

  https://lists.ubuntu.com/archives/ubuntu-users/2006-October/097145.html

--
  jules

Sebastien Bacher (seb128) wrote :

Thank you for your bug. Do you still have that problem? Could you provide an example for that and explain what is happening and what else you would expect?

Changed in orbit2:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Jules Colding (colding) wrote :

Yes, I still have this problem. The problem occurs if you are including an IDL file in another IDL file. Imagine this:

/* a.idl */
module BRUTUS {
   interface foobar {
      void method();
   };
};

/* b.idl */
#Include "a.idl"
module BRUTUS {
   interface foo {
      void bar(in foobar parm);
   };
};

/* c.idl */
#Include "a.idl"
module BRUTUS {
   interface footty {
      void barty(out foobar parm);
   };
};

"b.idl" and "c.idl" are both including "a.idl". Now compile these 3 idl files without the --onlytop option. You will observe that b.h and c.h does not merely contain #include "a.h" but the entire content of a.h. This will therefore make linking of the b.idl and c.idl compilation products impossible due to multible definitions of foobar.

You must compile with --onlytop to produce file that merely includes the appropiate headers instead of the entire file content. Only --onlytop will give you IDL compilation products that compile _and_ link as intended.

A good way to demonstrate this is simply to go get:

http://www.omesc.com/content/downloads/dist/SOURCES/evolution-brutus-1.1.22.tar.gz

and simply do:

./autogen.sh && make

evolution-brutus has a lot of IDL files that includes other IDL files.

Changed in orbit2:
importance: Undecided → Low
status: Needs Info → Unconfirmed
Ian Gibbs (flash666) wrote :

I have just tried the workaround above in gutsy. Couple of additionals:

(1) The additions to .bashrc can be summarised to:

export PATH=$HOME/opt/bin:$PATH
export LIBDIR=$HOME/opt/lib
export LD_LIBRARY_PATH=$LIBDIR:$LD_LIBRARY_PATH
export LD_RUN_PATH=$LIBDIR:$LD_RUN_PATH

which should work for everyone.

(2) Before I compiled evolution-brutus I compiled and installed brutus-keyring-0.9.11
(3) I then compiled evolution-brutus-1.1.30.11. Compilation failed twice:
  (a)
brutus_util.c:38:28: error: brutus-keyring.h: No such file or directory
brutus_util.c:39:29: error: brutus-keyringd.h: No such file or directory

I resolved this with the following as root:

rm -f /usr/local/include/brutus-keyring-1.0
ln -s $HOME/downloads/linux/brutus-keyring-0.9.11/src /usr/local/include/brutus-keyring-1.0

where $HOME/downloads/linux/brutus-keyring-0.9.11 is the name of the folder into which I had unpacked brutus-keyring.

  (b)
In file included from e-book-backend-brutus.h:31,
                 from e-book-backend-brutus-factory.c:48:
/usr/include/evolution-data-server-1.12/libedata-book/e-book-backend-db-cache.h:26:16: error: db.h: No such file or directory

I resolved this with the following as root:
apt-get install libdb4.6-dev

However, whilst this all apparently suceeded, brutus hasn't shown up as an account type, despite brutus stuff appearing under /usr/lib/evolution-data-server-1.2/camel-providers-1.0 and extensions, and a restart of evoution-data-server. Still working on it.

Jules Colding (colding) wrote :

Hi Ian.

I just replied to your mail on the brutus list. There is something about gutsy that makes e-b fail on that platform. The missing db.h is just one symptom of this. I think that it is sufficiently different from edgy to fall flat on its face and I suspect that the only solution to this would be to install gutsy on one of my boxes and debug the problem. Unfortunately this wont happen until mid November as I'm rather pressed for time right now.

Please post the solution if you find it before I dig in.

Thanks,
  jules

Jules Colding (colding) wrote :

Just wanted to note that this bug is still present in gutsy. The workaround keeps working.

Adrian Bishop (ambish) wrote :

In addition to Ian's comments above regarding Gutsy I also found that automake-1.7 prevented the compilation of evolution-brutus, specifically it gave the following errors:

Running automake-1.7...
docs/Makefile.am:35: `brutusdoc_DATA' is used but `brutusdocdir' is undefined
docs/Makefile.am:35: in the following conditions:
docs/Makefile.am:35: BRUTUS_SUSE_FALSE
docs/Makefile.am:39: `brutusdocdevel_DATA' is used but `brutusdocdeveldir' is undefined
docs/Makefile.am:39: in the following conditions:
docs/Makefile.am:39: BRUTUS_SUSE_FALSE

After installing automake-1.10 the compilation was successful.

Jules Colding (colding) wrote :

What version of evolution-brutus was that? Did it only happen in the "docs" directory??

Adrian Bishop (ambish) wrote :

Hi Jules,

The versions were:

Brutus keyring 0.9.11 - this compiled without any problems
Evolution brutus 1.1.29.23 and 1.1.30.11 - both stopped at the same place with the error shown

This only occurred for me in the docs directory, but this may simply be the first directory found with the issue during compilation.

This doesn't seem to be linked to the original bug, but since this bug report was the only guide I could find to building Brutus on Gutsy I thought it would be useful to post the information here.

Jules Colding (colding) wrote :

Hi Adrian,

I think the problem got fixed in later versions, yours are rather old. Try svn trunk
instead. With that you can do 'make distfiles' to generate files for the package
manager in question. On gutsy it would create debs.

HTH,
  jules

Jules Colding (colding) wrote :

Fixed in hardy

Changed in orbit2:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers