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?

http://www.antlr.org/doc/cpp-runtime.html#_buildruntime

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.

Thanks, I understand now.

Can you try
  http://people.redhat.com/vadimn/scratch/antlr/antlr-2.7.4-2jpp_3fc.i386.rpm

and tell me if that works for you?

Created attachment 120819 [details]
antlr.spec.patch

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.

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?

http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/
http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/Fedora/RPMS/

Unfortunately, I get linker errors when trying to use this:

/usr/lib64/libantlr.a(BitSet.o)(.gnu.linkonce.t._ZN9__gnu_cxx18__common_pool_baseINS_6__poolELb1EE13_S_initializeEv[__gnu_cxx::__common_pool_base<__gnu_cxx::__pool,
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()'
/usr/lib64/libantlr.a(BitSet.o)(.gnu.linkonce.t._ZN9__gnu_cxx18__common_pool_baseINS_6__poolELb1EE18_S_initialize_onceEv[__gnu_cxx::__common_pool_base<__gnu_cxx::__pool,
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()'
/usr/lib64/libantlr.a(TokenBuffer.o)(.gnu.linkonce.t._ZN9__gnu_cxx10__mt_allocIN5antlr8RefCountINS1_5TokenEEENS_20__common_pool_policyINS_6__poolELb1EEEE8allocateEmPKv[__gnu_cxx::__mt_alloc<antlr::RefCount<antlr::Token>,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned
long, void const*)]+0x29c): In function
`__gnu_cxx::__mt_alloc<antlr::RefCount<antlr::Token>,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned
long, void const*)':
: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
/usr/lib64/libantlr.a(BaseAST.o)(.gnu.linkonce.t._ZN9__gnu_cxx10__mt_allocIN5antlr11ASTRefCountINS1_3ASTEEENS_20__common_pool_policyINS_6__poolELb1EEEE8allocateEmPKv[__gnu_cxx::__mt_alloc<antlr::ASTRefCount<antlr::AST>,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned
long, void const*)]+0x29c): In function
`__gnu_cxx::__mt_alloc<antlr::ASTRefCount<antlr::AST>,
__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

Can you post a small example to reproduce the error?

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
libantlr.a?

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.

-benjamin

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.

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
| warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
| 
| $ 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.

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.

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.

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
	$(CXXLINK) $(CXXFLAGS) -o $@ $^ $(LDFLAGS)

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

Looking at the comments, it doesn't look like this still needs to be NEEDINFO.

Antlr updated to 2.7.7 in rawhide. It includes the fixes from Vadim and Radu --
thanks.