Can't compile 3.3b against (vanilla) mcpp 2.7

[mefoster]

I'm trying to compile the Ice 3.3 beta against mcpp 2.7 -- the newest version of mcpp, as released last month. It seems like something in 2.7 isn't interacting well with Ice, as slice2cpp now fails with an assertion error. I'm not sufficiently conversant with yacc to figure out what's going on here, or whether it's due to the changes in 2.7 or to the lack of the Ice patch included in the Ice version of 2.6.

The assertion happens at line 5516 of cpp/src/Slice/Parser.cpp:

        assert(_definitionContextStack.size() == 1);

As far as I can tell, the size of that stack is actually 2 when that line is reached ...

Any suggestions on how to resolve this would be appreciated, as using mcpp 2.7 is pretty much unavoidable.

Thanks,

MEF

[benoit]

Hi,

I'm afraid I don't think you can use 2.7. The 2.6.4 patch contains required fixes which were not included in 2.7. Note that mcpp is only required to build Ice, it's not required to use the slice translators since the mcpp library is statically linked with the Slice library. Perhaps a solution would be to build the patched 2.6.4 version when building the Ice 3.3b RPMs?

Cheers,
Benoit.

[mefoster]

I'm afraid I don't think you can use 2.7. The 2.6.4 patch contains required fixes which were not included in 2.7. Note that mcpp is only required to build Ice, it's not required to use the slice translators since the mcpp library is statically linked with the Slice library. Perhaps a solution would be to build the patched 2.6.4 version when building the Ice 3.3b RPMs?

Unfortunately, I don't think that can work: linking statically against a private, patched, older copy of a library is against just about every Fedora packaging guideline in existence.

As far as I can see, there are two alternatives that meet Fedora guidelines:

• Patch Ice to work with mcpp 2.7
• Patch Ice to not use mcpp at all

To choose between these, I guess I need to understand a bit more about how mcpp works and what the ZeroC patch to mcpp 2.6.4 accomplishes. Which of the above do you think is more practical?

Maybe this thread doesn't belong in "Bug Reports" any more ...

MEF

[benoit]

I'm checking if Ice can use the vanilla 2.7 mcpp distribution on Linux. I already have a fix for the Parser.cpp assert above (a bit different from yours) but I believe one more change is required for Ice for Ruby and Python (the python/ruby interpreters don't really like the fact that mcpp closes stdin...).

The Slice library will still need to link against the mcpp library so you'll need to have a mcpp build which includes the mcpp library not just the executable. I assume the mcpp RPM includes the library, is this correct?

Cheers,
Benoit.

[bernard]

Hi Mary-Ellen,

Removing the Ice 3.3. dependency on mcpp would be very difficult; we use mcpp to pre-process Slice files, and it would be quite a bit of work to replace mcpp with another preprocessor.

Fixing Ice / mcpp sounds like a more reasonable solution for the Fedora RPMs.

We build Ice in such a way that when you use Ice binaries (at runtime or for development), you don't see mcpp. The libSlice shared library "links in" various mcpp objects from a special mcpp static-library build. It's "special" because we include a number of patches for mcpp (currently patches for mcpp 2.6.4) and we build the objects in this static library with position-independent code. From the mcpp-devel spec file:

./configure CFLAGS=-fPIC --enable-mcpplib --disable-shared

It's not clear to me why doing the same for Fedora is so bad (who would be affected? who would care?). Is your main concern the version of mcpp? The patching of mcpp? The use of a "fPIC" static library?

Do you want to link your Ice RPMs with a dynamic library version of an unpatched mcpp 2.7 shared library, or static linking with a patched mcpp 2.7 lib would be fine?

We'd rather use an unpatched version of mcpp, and some of our patches (against 2.6.4) were incorporated into mcpp 2.7.

Unfortunately we discovered and addressed more issues later on, after the mcpp 2.7 release. For example, we replaced a number of freopen calls by fopen calls so that Ice for Python and Ice for Ruby can successfully process Slice files at runtime. It doesn't look like there is a good way to work-around these issues in the Ice code.

Thanks,
Bernard

[mefoster]

It's not clear to me why doing the same for Fedora is so bad (who would be affected? who would care?). Is your main concern the version of mcpp? The patching of mcpp? The use of a "fPIC" static library?

Well, the big issue is including a copy of a system library, although static linking isn't exactly smiled on either.

Do you want to link your Ice RPMs with a dynamic library version of an unpatched mcpp 2.7 shared library, or static linking with a patched mcpp 2.7 lib would be fine?

For the reasons listed above, I don't really have any alternative to linking dynamically against the system version of mcpp 2.7. At the moment, the Fedora mcpp package includes only the executable, but I'm working on getting the library added to that. I guess the freopen patches will also have to get into the Fedora mcpp package too. I'll find out shortly how responsive that package maintainer is.

MEF

[benoit]

Hi Mary Ellen,

I guess the freopen patches will also have to get into the Fedora mcpp package too. I'll find out shortly how responsive that package maintainer is.

FYI, I've submitted the freopen patch to the mcpp maintainer, see the mcpp forums.

Cheers,
Benoit.

[asamardzic]

Am intending to eventually create Ice package for Slackware, and would like to second MEF statements above: please do try to push all needed mcpp patches upstream so that it could be possible to build Ice against vanilla mcpp, and also please do try to provide the possibility to build and use Ice linked simply against shared version of the mcpp library - if possible, these would make life much easier to potential packagers...

[fmoya]

I do not really understand what's the fuss with the mcpp required by Ice 3.3b. Ice 3.2 included a hacked version of GNU cpp and nobody complained. All previous distributions of Ice included a hacked standalone GNU cpp and there where no problems then.
It is very simply stated: icecpp was a fork of GNU cpp. This is not an ideal situation but it is not uncommon in free software.
Now a hacked version of mcpp is required. The only difference is that the hacked mcpp is distributed in a different tarball.
Two options: either consider the source tarball to be a combination of the two required tarballs (Ice and hacked mcpp) or include the hacked tarball into the patches to be applied to the source.
It is true that fixes in upstream source do not automatically propagate to Ice. But that's a decision which competes to ZeroC, not to Debian, Fedora or Slackware.
On the other hand having mcpp linked into libSlice reinforces the tight coupling between them and avoids semantic mismatches between future versions of libSlice and mcpp. Otherwise you would need to set up a dependency on a explicit version of libmcpp. That would be even worse than linking libmcpp.a into libSlice.
Regards,
F. Moya

[mefoster]

On the other hand having mcpp linked into libSlice reinforces the tight coupling between them and avoids semantic mismatches between future versions of libSlice and mcpp. Otherwise you would need to set up a dependency on a explicit version of libmcpp. That would be even worse than linking libmcpp.a into libSlice.

Unfortunately, given the Fedora packaging guidelines (at least my reading thereof), the only option in this situation is to link dynamically against a system copy of libmcpp. It's very strongly discouraged to have an internal, patched copy of an external library inside another package (link to the relevant section of the guidelines). Static linking is also only allowed in exceptional cases which I don't think this is one of (guidelines link).

It looks like this problem is on its way to being solved for Fedora, as long as the changes in upstream mcpp make it into the Fedora package soon.

MEF

[fmoya]

Unfortunately, given the Fedora packaging guidelines (at least my reading thereof), the only option in this situation is to link dynamically against a system copy of libmcpp.

My point was that what you link into libSlice is not a system library but a fork of an existing package that was made into a part of a larger system library (libSlice). Not an ideal situation, but not against any Fedora policy either.

Regards,
F. Moya

[bernard]

Naturally, it is not our intent for fork mcpp. We'd like Ice to link with the mainstream libmcpp, just like Ice links with OpenSSL, Expat, Bzip2, Berkeley DB.

Hopefully, mcpp 2.7.1 will include all the patches necessary for Ice, and this issue will disappear!

Cheers,
Bernard

[asamardzic]

Just tried to compile Ice-3.3b against freshly released mcpp 2.7.1, and the same compilation error is still there (the system is Slackware 12.1, with gcc 4.2.3):

----
../../bin/slice2cpp --ice --include-dir Ice --dll-export ICE_API -I../../../slice --stream ../../../slice/Ice/BuiltinSequences.ice
slice2cpp: Parser.cpp:5516: int Slice::Unit:arse(const std::string&, FILE*, bool, Slice::FeatureProfile): Assertion `_definitionContextStack.size() == 1' failed.
make[3]: *** [BuiltinSequences.cpp] Aborted
----

[benoit]

Hi,

Yes, it's a problem with the Slice library that occurs only with mcpp 2.7. This has been fixed for 3.3.0 which will be released very soon.

Cheers,
Benoit.

[asamardzic]

Ah - OK then, thanks!

Am not able to find any pointer to Ice CVS/SVN/... repository, in order to try current code - the code is not publicly available this way, right?