Bug 172456 - Missing C++ library
Missing C++ library
Product: Fedora
Classification: Fedora
Component: antlr (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Deepak Bhole
Depends On:
  Show dependency treegraph
Reported: 2005-11-04 14:56 EST by Braden McDaniel
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-22 20:52:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
antlr.spec.patch (2.06 KB, patch)
2005-11-08 13:51 EST, Vadim Nasardinov
no flags Details | Diff
Trivial test program that uses libantlr (554 bytes, application/x-gzip)
2005-11-11 20:22 EST, Braden McDaniel
no flags Details
Updated antlr.spec patch (1.47 KB, patch)
2006-10-11 04:48 EDT, Radu Greab
no flags Details | Diff

  None (edit)
Description Braden McDaniel 2005-11-04 14:56:07 EST
Description of problem:
Antlr's C++ library is missing from this package.

Version-Release number of selected component (if applicable):
Comment 1 Vadim Nasardinov 2005-11-04 17:35:30 EST
I haven't used Antlr myself.  Before I go and change anything, help me
make me sure I understand the problem, if you can.

Antlr implements the same functionality in at least three different
languages.  For example,

| $ find . -name LLkParser.\*
| ./antlr/LLkParser.java
| ./lib/cpp/antlr/LLkParser.hpp
| ./lib/cpp/src/LLkParser.cpp
| ./lib/csharp/src/antlr/LLkParser.cs

The C# and Java implementations are unsurprisingly similar.  They even
have about 70 identically named classes:

| $ find . -name \*.java | xargs -n1 -exec basename  | sort | uniq |
|   sed 's/\.java$//' > /tmp/antlr-java.txt
| $ find . -name \*.cs | xargs -n1 -exec basename  | sort | uniq | 
|   sed 's/\.cs$//' > /tmp/antlr-csharp.txt
| $ join /tmp/antlr-java.txt /tmp/antlr-csharp.txt | wc -l
| 73

The C++ and Java implementation have a lot less in common:

| $ find . -name \*.cpp | xargs -n1 -exec basename  | sort | uniq |
|   sed 's/\.cpp$//' > /tmp/antlr-cpp.txt
| $ join /tmp/antlr-java.txt /tmp/antlr-cpp.txt  | wc -l

But even regardless of any commonality or lack thereof, the C++ and
Java implementations are essentially two completely independent
codebases.  They share nothing whatsoever, except maybe the manual.

So, my first question is, is this a fair assessment?

My second question is, you want the C++ binaries /usr/bin/antlr and
/usr/lib/libantlr.a included in this package.  Is that right?

Comment 2 Braden McDaniel 2005-11-04 17:51:51 EST
Not quite.

Antlr consists of a code generator program and support libraries that the 
generated code links with. The same generator program is used for both Java 
and C++.

/usr/bin/antlr is already included and it is capable of generating C++ code. 
Only it's a shell script that runs the Java program; not a compiled binary. I 
see no need for it to be a compiled binary--it would do the same thing and a 
Java program works fine as far as I'm concerned.

All that's missing is the C++ library, libantlr, and its associated headers.
Comment 3 Vadim Nasardinov 2005-11-04 18:30:29 EST
Thanks, I understand now.
Comment 4 Vadim Nasardinov 2005-11-07 15:31:57 EST
Can you try

and tell me if that works for you?
Comment 5 Vadim Nasardinov 2005-11-08 13:51:30 EST
Created attachment 120819 [details]

Patch against the current rawhide version that adds
C++ headers and libantlr.a to the RPM.

Filing it here so I don't lose it.

I'll push this into rawhide in a few days, if I don't hear
any objections against the RPMs listed in comment #4.
Comment 6 Braden McDaniel 2005-11-11 03:20:39 EST
Sorry, I'm on an x86_64 box. Any chance you could post an RPM for that platform
or a source RPM I could rebuild?
Comment 8 Braden McDaniel 2005-11-11 09:33:38 EST
Unfortunately, I get linker errors when trying to use this:

true>::_S_initialize()]+0xd0): In function
`__gnu_cxx::__common_pool_base<__gnu_cxx::__pool, true>::_S_initialize()':
: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
true>::_S_initialize_once()]+0xf9): In function
`__gnu_cxx::__common_pool_base<__gnu_cxx::__pool, true>::_S_initialize_once()':
: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned
long, void const*)]+0x29c): In function
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned
long, void const*)':
: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned
long, void const*)]+0x29c): In function
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned
long, void const*)':
: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
collect2: ld returned 1 exit status
Comment 9 Vadim Nasardinov 2005-11-11 09:39:47 EST
Can you post a small example to reproduce the error?
Comment 10 Braden McDaniel 2005-11-11 20:22:26 EST
Created attachment 120973 [details]
Trivial test program that uses libantlr

This trivial test program produces a lot more unresolved symbols when linking
than my actual use case does. Possibly not everything got compiled into
Comment 11 Benjamin Kosnik 2005-11-14 13:16:34 EST
The error message in #8 looks like it is due to something being compiled on a
gcc-4.0.2 system, but then run on a gcc-4.0.1 system. 

That will not work.

Instead, if you want to distribute one set of binaries on FC3/FC4/RHEL4, I would
suggest compiling on the lowest common denominator, ie FC3.

Comment 12 Braden McDaniel 2005-11-14 14:25:13 EST
Yes, I'm using FC4/gcc 4.0.1. I just installed the RPM mentioned in the URL 
here; I guess it was built with gcc 4.0.2.

I'll rebuild the source RPM and see what results I get.
Comment 13 Vadim Nasardinov 2005-11-14 14:45:35 EST
I tried running the example (attachment 120973 [details]) on a rawhide machine
that has gcc-4.0.2 installed and I'm seeing failures.

Here's what I see:

| $ curl -o antlr-test.tar.gz \
|   'https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=120973'
| $ tar xzf antlr-test.tar.gz
| $ cd antlr-test
| $ g++ --version
| g++ (GCC) 4.0.2 20051007 (Red Hat 4.0.2-3)
| Copyright (C) 2005 Free Software Foundation, Inc.
| This is free software; see the source for copying conditions.  There is NO
| $ nm -C /usr/lib/libantlr.a | grep -F 'antlr::CharScanner::consume()'
| 000000b0 T antlr::CharScanner::consume()
|          U antlr::CharScanner::consume()
|          U antlr::CharScanner::consume()
| $ make
| antlr TestParser.g
| ANTLR Parser Generator   Version 2.7.4   1989-2004 jGuru.com
| warning: found optional path in nextToken()
| g++    -c -o antlr_test.o antlr_test.cpp
| g++    -c -o TestLexer.o TestLexer.cpp
| g++    -c -o TestParser.o TestParser.cpp
| g++  -lantlr -o antlr-test antlr_test.o TestLexer.o TestParser.o
| antlr_test.o:(.gnu.linkonce.r._ZTVN5antlr11CharScannerE[vtable for
antlr::CharScanner]+0x24): undefined reference to `antlr::CharScanner::consume()'
| [... 120+ similar lines elided ...]

P.S. Benjamin, I took the liberty of adding you to the cc list.  I
don't mean to impose.  If you don't have the time to look at this,
just remove yourself from the cc list.  Thanks for your help thus far.
Comment 14 Vadim Nasardinov 2005-11-28 16:22:30 EST
I've reverted the previous change, because

 (a) I havend't had the time to sort this out;
 (b) I'm leaving the company and don't want to leave things
     in a broken state.

Comment 15 Chris Adams 2006-02-11 23:30:43 EST
Any chance someone can pick this up again?  I'm trying to help someone get a
package from someone else into a buildable state for Linux (Fedora and/or RHEL),
and they need the antlr C++ library.
Comment 16 Radu Greab 2006-10-11 04:48:02 EDT
Created attachment 138228 [details]
Updated antlr.spec patch

The rpm as modified by Vadim was almost OK, the problem with the test is the
order of the arguments passsed to the linker: "-lantlr" appears before the
object files. Because libantlr.a is an archive and the linker searches an
archive only once, the objects appearing later on the command line can not have
their symbols linked to the previous archive.

If the test's Makefile is changed to add "-lantlr" after the object files, then
the linking is successful:

antlr-test: antlr_test.o TestLexer.o TestParser.o

With the updated makefile:
$ make
g++    -c -o antlr_test.o antlr_test.cpp
g++    -c -o TestLexer.o TestLexer.cpp
g++    -c -o TestParser.o TestParser.cpp
g++  -o antlr-test antlr_test.o TestLexer.o TestParser.o -lantlr
$ ./antlr-test

The patch is against antlr-2.7.4-2jpp_6fc from Fedora 5 and fixes some small
issues I found in Vadim's initial patch:
- --disable-examples should be --without-examples
- antlr-config is installed too. No interesting information inside it, but the 
  antlr docs say that it is a good idea to have it installed.
- changed the order of files inside %files to remove the execute permission
  from headers and library
Comment 17 Braden McDaniel 2007-01-04 20:31:29 EST
Looking at the comments, it doesn't look like this still needs to be NEEDINFO.
Comment 18 Deepak Bhole 2007-01-22 20:52:27 EST
Antlr updated to 2.7.7 in rawhide. It includes the fixes from Vadim and Radu --

Note You need to log in before you can comment on or make changes to this bug.