opencxx-users

[Opencxx-users] libtool and glibtool for OpenC++ on Mac 10.4.2 (Tiger)

[garaf g. <gar...@ya...>]

Hi,

I am trying to install the latest CVS snapshot of
OpenC++ on Mac 10.4.2 (Tiger). I am facing the
following problem: in Mac 10.4.2, libtool is different
than the gnu libtool -which is called glibtool- 

All installation files in OpenC++ assumes that libtool
is glibtool, which causes installation problems and
errors.

I changed every occurence of "libtool" in the file
bootstrap with "glibtool" and it worked, but later on,
when I tried to run occ2 it caused segmentation fault
because it is again calling libtool thinking it is
glibtool. 

I tried to change every occurence of every "libtool"
in all OpenC++ files with "glibtool" but again this
didn't work.

Anyone can help? 

Please let me know if OpenC++ can be installed on Mac
10.4.2, I have spent over a month trying to install it
on my Mac with no success.

Thank you
garaf

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Opencxx-users] Fwd: Compile error?

[Stefan S. <se...@sy...>]

Scott D. Fleming wrote:
> Hi Jason,
> It looks like OpenC++ doesn't recognize the "explicit" keyword. In
> parser/Lex.cc, there are lines like:
> 
> Lex.cc:853:    { "inline",              token(INLINE) },
> Lex.cc:887:    { "volatile",            token(VOLATILE) },
> 
> But there is nothing equivalent for "explicit".
> 
> I think I can suggest a quick/dirty fix. The "explicit" specifier is
> only used with constructors to prevent implicit type conversions. I

Correct.

> may be wrong, but I would expect that the specifier could just be
> ignored as long as the client programmer is careful not to use
> implicit conversions.

As far as OpenC++ is concerned it simply means that occ would accept
some code that is not valid. But since OpenC++ doesn't do any of the
related analysis anyways, this is fine.

> I'm pretty sure this could be accomplished by
> adding a line as follows to the table[] definition in parser/Lex.cc
> (found around line 810).
> 
>     { "explicit", token(Ignore) },

Right. The slightly more involved fix would be to provide a new token,
and then teach the parser how to deal with it. At first it could
ignore it, but eventually it could integrate it into the generated
parse tree. That's what I did in the synopsis parser (http://synopsis.fresco.org/),
i.e. I expect it as a regular 'function-specifier', as mandated by
the C++ specification (ISO 14882).

Regards,
		Stefan

Re: [Opencxx-users] Fwd: Compile error?

[Scott D. F. <sd...@cs...>]

Hi Jason,
It looks like OpenC++ doesn't recognize the "explicit" keyword. In
parser/Lex.cc, there are lines like:

Lex.cc:853:    { "inline",              token(INLINE) },
Lex.cc:887:    { "volatile",            token(VOLATILE) },

But there is nothing equivalent for "explicit".

I think I can suggest a quick/dirty fix. The "explicit" specifier is
only used with constructors to prevent implicit type conversions. I
may be wrong, but I would expect that the specifier could just be
ignored as long as the client programmer is careful not to use
implicit conversions. I'm pretty sure this could be accomplished by
adding a line as follows to the table[] definition in parser/Lex.cc
(found around line 810).

    { "explicit", token(Ignore) },

Hope this helps.
Scott


On 3/17/06, Jason Kraus <zb...@gm...> wrote:
> Seems i sent too much, lets try this again.
>
> ---------- Forwarded message ----------
> From: Jason Kraus <zb...@gm... >
> Date: Mar 17, 2006 5:15 AM
> Subject: Compile error?
> To: ope...@li...
>
> So went to compile a file like so:
>
> zbyte64 OpenMetaBase # occ2 -c
> '/root/Desktop/OpenMetaBase/MetaBaseClass.mc' --verbose
> -I/usr/include/libxml++-2.6 -I/usr/include/glibmm-2.4
> -I/usr/include/glib-2.0 -I/usr/lib/glib- 2.0/include
> -I/usr/lib/glibmm-2.4/include -o metafoo.mo
> occ2: preproc1: g++ -E -x c++ -D__opencxx -I/usr/local/include
> -I/usr/include/libxml++-2.6 -I/usr/include/glibmm-2.4
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/glibmm-
> 2.4/include /root/Desktop/OpenMetaBase/MetaBaseClass.mc -o
> MetaBaseClass.ii
> occ2: parse-and-translate: /usr/local/bin/occ --private--external-driver =
-E
> <MetaBaseClass.ii --private--output MetaBaseClass.occ.tmp 2>
> MetaBaseClass.feedback
> occ2: command failed: /usr/local/bin/occ --private--external-driver -E
> <MetaBaseClass.ii --private--output MetaBaseClass.occ.tmp
> 2>MetaBaseClass.feedback
>
> I'll attatch the files...
>
> if you look in the feedback file you get to see the following:
>  /usr/include/glibmm-2.4/glibmm/ustring.h:119: parse error before `('
> In reality its glibmm-2.8.1, and the code it is complaining about is as
> follows:
>
>  template <class T>
> class ustring_Iterator
> {
> public:
>  typedef std::bidirectional_iterator_tag iterator_category;
>  typedef gunichar value_type;
>
>  typedef std::string::difference_type difference_type;
>  typedef value_type reference;
>  typedef void pointer;
>
>
>  inline ustring_Iterator();
>  inline ustring_Iterator(const
> ustring_Iterator<std::string::iterator>& other);
>
>  inline value_type
> operator*() const;
>
>  inline ustring_Iterator<T> & operator++();
>  inline const ustring_Iterator<T>
> operator++(int);
>  inline ustring_Iterator<T> & operator--();
>  inline const ustring_Iterator<T>
> operator--(int);
>
>  explicit inline ustring_Iterator(T pos); // this is line 119
>  inline T base() const
> ;
>
> private:
>  T pos_;
> };
> Any ideas? Thx in advanced.
>
>
>

Re: [Opencxx-users] cygwin compilation problems

[&lt;Dima&gt; D. <pos...@ya...>]

Hello,

>  First of all, I am a beginner. I tried to install opencxx under cygwin for a week but I couldn't make it. 

Hello,
Some time ago I tried to install opencxx under cygwin too and had come problems. Unfortunately, I do not remember details. As far as I remember, the main functionality can be achieved under Cygwin.

I remember just a few problems:
1) Some files had deprecated names: aux.cc, aux.h. They were renamed in 2.8
2) Some files had the same names, becouse Windows file systems are not case-sensitive. I am not sure, it was fixed.
You will see these problems (if they are) during uploading/unzipping.

There were a number of topics about Cygwin in the maillist, so you can read an archive.

>  So, I have downloaded the latest opencxx CVS snapshot, which is opencxx-20050912.tar.gz (I got it from http://opencxx.sourceforge.net/snapshots/ ). The problem is that this snapshot doesn't have a "configure" file, so how can I generate the Makefile and install opencxx without the configure file?

You have to install autotools: automake, autoconf and may be come else. Then you have to run ./boostrap script to produce configure and Make files.

I think, it is useful to send error messages, if problem will occur.

[Opencxx-users] cygwin compilation problems

[garaf g. <gar...@ya...>]

Hello,
   
  First of all, I am a beginner. I tried to install opencxx under cygwin for a week but I couldn't make it. I have first downloaded the latest release which is opencxx-2.8, I had many compilation errors when I tried to "make" the code. I am having gcc 3.4.4 and I heard that some source files like MetaCompilerConfiguration.h aren't compatible with this version of gcc.
   
  So, I have downloaded the latest opencxx CVS snapshot, which is opencxx-20050912.tar.gz (I got it from http://opencxx.sourceforge.net/snapshots/ ). The problem is that this snapshot doesn't have a "configure" file, so how can I generate the Makefile and install opencxx without the configure file?
   
  This may be a silly question, but since I am a beginner, I highly appreciate your help.
   
  Thank you
  Garaf

		
---------------------------------
Relax. Yahoo! Mail virus scanning helps detect nasty viruses!

Re: [Opencxx-users] Need help compiling with occ (MacOSX)

[<se...@in...>]

On Mon, 2005-12-12 at 16:08 -0500, Gilles J. Seguin wrote:
> On Mon, 2005-12-12 at 12:12 -0800, Claudio Levinas wrote:
> > Hello,
> > 
> > I was able to generate shared libs out of a metaclass (only) by using the 
> > following two statements:
> > 
> > $ occ -c -m BeforeClass.mc
> > $ occ -mBeforeClass BeforeClass.o
>  if from the examples/before directory
> 
> try make
> 
> or
> make BeforeClass
> make before-test

was using wrong tree
make before-test
make BeforeClass.exe

Re: [Opencxx-users] Need help compiling with occ (MacOSX)

[<se...@in...>]

On Mon, 2005-12-12 at 12:12 -0800, Claudio Levinas wrote:
> Hello,
> 
> I was able to generate shared libs out of a metaclass (only) by using the 
> following two statements:
> 
> $ occ -c -m BeforeClass.mc
> $ occ -mBeforeClass BeforeClass.o
 if from the examples/before directory

try make

or
make BeforeClass
make before-test

Re: [Opencxx-users] Need help compiling with occ (MacOSX)

[<se...@in...>]

On Mon, 2005-12-12 at 12:12 -0800, Claudio Levinas wrote:
> Hello,
> 
> I was able to generate shared libs out of a metaclass (only) by using the 
> following two statements:
> 
> $ occ -c -m BeforeClass.mc
> $ occ -mBeforeClass BeforeClass.o
> 
> This yields the two shared libs "BeforeClass-init.so" and "BeforeClass.so".
> 
> Note that "occ -m BeforeClass.mc " won't work (a lot of undefined symbols).
> 
> 
> Anyway, when I try to compile the test program, I fail:
> 
> $ occ -- -o before-test before-test.cc
> EXECUTING: g++ g++ -D__opencxx -E -o before-test.occ -x c++ before-test.cc
> unknown:0: the metaclass is not loaded: BeforeClass
> EXECUTING: g++ g++ -o before-test before-test.ii
> 
> 
> I tried to set the library path (DYLD_LIBRARY_PATH or even LD_LIBRARY_PATH), 
> and also tried putting the shared libs in "/usr/local/lib", but still the 
> metaclass won't load.
> 
> Here is part of my configuration:
> 
> checking whether the g++ linker (/usr/bin/ld) supports shared libraries... 
> yes
> checking dynamic linker characteristics... darwin8.3.0 dyld
> checking which extension is used for loadable modules... .so
> checking which variable specifies run-time library path... DYLD_LIBRARY_PATH
> checking for the default library search path... /usr/local/lib /lib /usr/lib
> 
> 
> Any suggestion on what to try next?
> 
> Thanks!
> Claudio.

occ2 --help

Re: [Opencxx-users] Need help compiling with occ (MacOSX)

[Stefan S. <se...@sy...>]

Claudio Levinas wrote:
> Hello,
> 
> I was able to generate shared libs out of a metaclass (only) by using 
> the following two statements:
> 
> $ occ -c -m BeforeClass.mc
> $ occ -mBeforeClass BeforeClass.o
> 
> This yields the two shared libs "BeforeClass-init.so" and "BeforeClass.so".
> 
> Note that "occ -m BeforeClass.mc " won't work (a lot of undefined symbols).
> 
> 
> Anyway, when I try to compile the test program, I fail:
> 
> $ occ -- -o before-test before-test.cc
> EXECUTING: g++ g++ -D__opencxx -E -o before-test.occ -x c++ before-test.cc
> unknown:0: the metaclass is not loaded: BeforeClass
> EXECUTING: g++ g++ -o before-test before-test.ii
> 
> 
> I tried to set the library path (DYLD_LIBRARY_PATH or even 
> LD_LIBRARY_PATH), and also tried putting the shared libs in 
> "/usr/local/lib", but still the metaclass won't load.

[Caution: It has been a long time since I have last played with OpenC++, so
  this may only be vaguely helpful.]

occ will attempt to load the metaclass from the BeforeClass.so plugin,
using dlopen(). The plugin intself should therefor be found in either the
local directory or via the LD_LIBRARY_PATH (or however it is spelled on your
platform).
I'm now sure how well occ deals with errors during the plugin loading.
 From your description above it sounds as if the missing symbols you
encountered earlier could still be missing, but now only show up at
load time. Just a shot in the dark...

May be you can debug the loading phase itself, either by means of gdb,
strace, or plain old 'std::cerr'.

HTH,
		Stefan

[Opencxx-users] Need help compiling with occ (MacOSX)

[Claudio L. <c_l...@ho...>]

Hello,

I was able to generate shared libs out of a metaclass (only) by using the 
following two statements:

$ occ -c -m BeforeClass.mc
$ occ -mBeforeClass BeforeClass.o

This yields the two shared libs "BeforeClass-init.so" and "BeforeClass.so".

Note that "occ -m BeforeClass.mc " won't work (a lot of undefined symbols).


Anyway, when I try to compile the test program, I fail:

$ occ -- -o before-test before-test.cc
EXECUTING: g++ g++ -D__opencxx -E -o before-test.occ -x c++ before-test.cc
unknown:0: the metaclass is not loaded: BeforeClass
EXECUTING: g++ g++ -o before-test before-test.ii


I tried to set the library path (DYLD_LIBRARY_PATH or even LD_LIBRARY_PATH), 
and also tried putting the shared libs in "/usr/local/lib", but still the 
metaclass won't load.

Here is part of my configuration:

checking whether the g++ linker (/usr/bin/ld) supports shared libraries... 
yes
checking dynamic linker characteristics... darwin8.3.0 dyld
checking which extension is used for loadable modules... .so
checking which variable specifies run-time library path... DYLD_LIBRARY_PATH
checking for the default library search path... /usr/local/lib /lib /usr/lib


Any suggestion on what to try next?

Thanks!
Claudio.

Re: [Opencxx-users] Can't compile metaclasses on MacOSX with gcc 4

[<se...@in...>]

On Mon, 2005-12-12 at 12:06 -0500, Stefan Seefeld wrote:
> Gilles J. Seguin wrote:
> > On Sun, 2005-12-11 at 12:54 -0800, Claudio Levinas wrote:
> > 
> >>Lex.cc does indeed skip the keyword, only that it was set to skip "__ASM__". 
> >>I simply added "__ASM" and it did the job.
> >>
> >>#if (defined __GNUC__) || (defined _GNUC_SYNTAX)
> >>     { "__alignof__", token(SIZEOF) },
> > 
> > 
> > i need an #ifdef SOMETHING
> > 
> >>+   { "__asm", token(ATTRIBUTE) },
> > 
> > #endif
> > 
> > do we have a standard one
> 
> FWIW, I added '__asm' to synopsis' lexer keywords unconditionally a long time
> ago without ever running into trouble. I think this is a fairly safe thing to
> do, as user code never should use names starting with double underscores, so
> there is no or little danger for name clashes.
> 
> Regards,
> 		Stefan

have commit on branch rel_2_8
new revision: 1.2.2.5;

thanks to Claudio Levinas for the patch

[Opencxx-users] Re: Can't compile metaclasses on MacOSX with gcc 4

[Claudio L. <c_l...@ho...>]

>Please note that the "__asm" token might be inhibiting the "__asm__" token. 
>At least on the mac, the order of these two tokens does seem to be 
>important. When I tried switching the them around, as shown below, the fix 
>didn't work.
>
>     { "__asm__", token(ATTRIBUTE) },
>+   { "__asm", token(ATTRIBUTE) },
>
>Claudio.


On the other hand, there are many examples in the list that suggest that 
"__asm" followed by "__asm__" should be fine:

    { "__restrict", token(Ignore) },
    { "__restrict__", token(Ignore) },
    { "__signed", token(SIGNED) },
    { "__signed__", token(SIGNED) },
    etc...

Claudio.

[Opencxx-users] Re: Can't compile metaclasses on MacOSX with gcc 4

[Claudio L. <c_l...@ho...>]

>i need an #ifdef SOMETHING
> > +   { "__asm", token(ATTRIBUTE) },
>#endif

>FWIW, I added '__asm' to synopsis' lexer keywords unconditionally a long 
>time
>ago without ever running into trouble. I think this is a fairly safe thing 
>to
>do, as user code never should use names starting with double underscores, 
>so
>there is no or little danger for name clashes.

>Regards,
>		Stefan


Please note that the "__asm" token might be inhibiting the "__asm__" token. 
At least on the mac, the order of these two tokens does seem to be 
important. When I tried switching the them around, as shown below, the fix 
didn't work.

     { "__asm__", token(ATTRIBUTE) },
+   { "__asm", token(ATTRIBUTE) },

Claudio.

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[<se...@in...>]

On Sat, 2005-12-10 at 22:57 -0500, Stefan Seefeld wrote:

[...]

> 
> Hi Peter,
> 
> I'v been playing with the OpenC++ code for a couple of years, until
> I realized that to be really useful it required a number of serious
> improvements that couldn't be made incrementally.

Yup, that is
Opencxx must modify the used grammar to conform to the one in the
annexe of ISO standard.
- peoples are used to it
- will cure the problem with the stdc++ headers for gcc 3.4

With gcc version 4.x the problem is deeper, we require semantic
analysis. Or you must make some minor customs change to the gcc stdc++
headers.

Which are the show stopper for version 1.9

> The generated parse tree is similar but not identical to the one generated
> by OpenC++. It aims at full ISO C++ conformance.
> 
> Just a FYI...
> 
> Regards,
> 		Stefan

Re: [Opencxx-users] Can't compile metaclasses on MacOSX with gcc 4

[Stefan S. <se...@sy...>]

Gilles J. Seguin wrote:
> On Sun, 2005-12-11 at 12:54 -0800, Claudio Levinas wrote:
> 
>>Lex.cc does indeed skip the keyword, only that it was set to skip "__ASM__". 
>>I simply added "__ASM" and it did the job.
>>
>>#if (defined __GNUC__) || (defined _GNUC_SYNTAX)
>>     { "__alignof__", token(SIZEOF) },
> 
> 
> i need an #ifdef SOMETHING
> 
>>+   { "__asm", token(ATTRIBUTE) },
> 
> #endif
> 
> do we have a standard one

FWIW, I added '__asm' to synopsis' lexer keywords unconditionally a long time
ago without ever running into trouble. I think this is a fairly safe thing to
do, as user code never should use names starting with double underscores, so
there is no or little danger for name clashes.

Regards,
		Stefan

Re: [Opencxx-users] Can't compile metaclasses on MacOSX with gcc 4

[<se...@in...>]

On Sun, 2005-12-11 at 12:54 -0800, Claudio Levinas wrote:
> Lex.cc does indeed skip the keyword, only that it was set to skip "__ASM__". 
> I simply added "__ASM" and it did the job.
> 
> #if (defined __GNUC__) || (defined _GNUC_SYNTAX)
>      { "__alignof__", token(SIZEOF) },

i need an #ifdef SOMETHING
> +   { "__asm", token(ATTRIBUTE) },
#endif

do we have a standard one

>      { "__asm__", token(ATTRIBUTE) },
>      { "__attribute__", token(ATTRIBUTE) },
> 
> Thanks!!!
> Claudio.

Re: [Opencxx-users] Can't compile metaclasses on MacOSX with gcc 4

[Claudio L. <c_l...@ho...>]

Lex.cc does indeed skip the keyword, only that it was set to skip "__ASM__". 
I simply added "__ASM" and it did the job.

#if (defined __GNUC__) || (defined _GNUC_SYNTAX)
     { "__alignof__", token(SIZEOF) },
+   { "__asm", token(ATTRIBUTE) },
     { "__asm__", token(ATTRIBUTE) },
     { "__attribute__", token(ATTRIBUTE) },

Thanks!!!
Claudio.


>Jonathan Gdalevich wrote:
>>Claudio Levinas wrote:

>>>occ -m BeforeClass.mc
>>>EXECUTING: g++ g++ -D__opencxx -E -o BeforeClass.occ -x c++
>>>BeforeClass.mc
>>>/usr/include/stdio.h:258: parse error before `"_" "fprintf" "$LDBLStub"'
>>>/usr/include/stdio.h:342: parse error before `"_" "snprintf" "$LDBLStub"'
>>>/usr/include/stdio.h:374: parse error before `"_" "__svfscanf"
>>>"$LDBLStub"'
>>>/usr/include/wchar.h:124: parse error before `"_" "fwprintf" "$LDBLStub"'
>>>/usr/include/stdlib.h:181: parse error before `"_" "strtold" "$LDBLStub"'

>[...]

>>I heard somewhere that OpenC++ does not support gcc4.  I dont' remember
>>where I heard it or if its true but you might want to try gcc 3.4.

>The problem is not gcc4, but its use of modern C++ code in the libstdc++
>library headers (notably the type_traits, I believe), which occ doesn't
>parse correctly.

>The above error, however, seems to stem from system headers, notably
>some inline assembler code, which, IIRC, should be skipped by the lexer.

>Regards,
>		Stefan

Re: [Opencxx-users] Can't compile metaclasses on MacOSX with gcc 4

[Stefan S. <se...@sy...>]

Jonathan Gdalevich wrote:
> Claudio Levinas wrote:

>>occ -m BeforeClass.mc
>>EXECUTING: g++ g++ -D__opencxx -E -o BeforeClass.occ -x c++
>>BeforeClass.mc
>>/usr/include/stdio.h:258: parse error before `"_" "fprintf" "$LDBLStub"'
>>/usr/include/stdio.h:342: parse error before `"_" "snprintf" "$LDBLStub"'
>>/usr/include/stdio.h:374: parse error before `"_" "__svfscanf"
>>"$LDBLStub"'
>>/usr/include/wchar.h:124: parse error before `"_" "fwprintf" "$LDBLStub"'
>>/usr/include/stdlib.h:181: parse error before `"_" "strtold" "$LDBLStub"'

[...]

> I heard somewhere that OpenC++ does not support gcc4.  I dont' remember
> where I heard it or if its true but you might want to try gcc 3.4.

The problem is not gcc4, but its use of modern C++ code in the libstdc++
library headers (notably the type_traits, I believe), which occ doesn't
parse correctly.

The above error, however, seems to stem from system headers, notably
some inline assembler code, which, IIRC, should be skipped by the lexer.

Regards,
		Stefan

Re: [Opencxx-users] Can't compile metaclasses on MacOSX with gcc 4

[Jonathan G. <gt...@ma...>]

Claudio Levinas wrote:

> Hello,
>
> I am not able to compile metaclasses with occ (versions 2.7, 2.8, or
> CVS) on the mac. I was able to create the occ executable, but then
> when I use it I get the following (other errors were fixed following
> advice from the forum):
>
>
> occ -m BeforeClass.mc
> EXECUTING: g++ g++ -D__opencxx -E -o BeforeClass.occ -x c++
> BeforeClass.mc
> /usr/include/stdio.h:258: parse error before `"_" "fprintf" "$LDBLStub"'
> /usr/include/stdio.h:342: parse error before `"_" "snprintf" "$LDBLStub"'
> /usr/include/stdio.h:374: parse error before `"_" "__svfscanf"
> "$LDBLStub"'
> /usr/include/wchar.h:124: parse error before `"_" "fwprintf" "$LDBLStub"'
> /usr/include/stdlib.h:181: parse error before `"_" "strtold" "$LDBLStub"'
>
>
> The errors above point to the following definitions:
>
> /usr/include/sys/cdefs.h:
> #define    __STRING(x) #x
> #if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__-0 < 1040
> #  define __DARWIN_LDBL_COMPAT(x)   __asm("_" __STRING(x) "$LDBLStub")
> #else
> #  define __DARWIN_LDBL_COMPAT(x)   __asm("_" __STRING(x) "$LDBL128")
> #endif
>
> /usr/include/stdio.h:
> int     fprintf(FILE * __restrict, const char * __restrict, ...)  
> __DARWIN_LDBL_COMPAT(fprintf);
>
>
> Any suggestion on how to work arround/fix this?
>
> Thanks!
> Claudio.
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
Hi,

I heard somewhere that OpenC++ does not support gcc4.  I dont' remember
where I heard it or if its true but you might want to try gcc 3.4.

Sincerely,

-- 
Jonathan Gdalevich
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gt...@pr...

[Opencxx-users] Can't compile metaclasses on MacOSX with gcc 4

[Claudio L. <c_l...@ho...>]

Hello,

I am not able to compile metaclasses with occ (versions 2.7, 2.8, or CVS) on 
the mac. I was able to create the occ executable, but then when I use it I 
get the following (other errors were fixed following advice from the forum):


occ -m BeforeClass.mc
EXECUTING: g++ g++ -D__opencxx -E -o BeforeClass.occ -x c++ BeforeClass.mc
/usr/include/stdio.h:258: parse error before `"_" "fprintf" "$LDBLStub"'
/usr/include/stdio.h:342: parse error before `"_" "snprintf" "$LDBLStub"'
/usr/include/stdio.h:374: parse error before `"_" "__svfscanf" "$LDBLStub"'
/usr/include/wchar.h:124: parse error before `"_" "fwprintf" "$LDBLStub"'
/usr/include/stdlib.h:181: parse error before `"_" "strtold" "$LDBLStub"'


The errors above point to the following definitions:

/usr/include/sys/cdefs.h:
#define	__STRING(x) #x
#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__-0 < 1040
#  define __DARWIN_LDBL_COMPAT(x)   __asm("_" __STRING(x) "$LDBLStub")
#else
#  define __DARWIN_LDBL_COMPAT(x)   __asm("_" __STRING(x) "$LDBL128")
#endif

/usr/include/stdio.h:
int	 fprintf(FILE * __restrict, const char * __restrict, ...)   
__DARWIN_LDBL_COMPAT(fprintf);


Any suggestion on how to work arround/fix this?

Thanks!
Claudio.

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Stefan S. <se...@sy...>]

Peter C. Chapin wrote:

> I'm not sure if trying to swap auto_ptrs at all is a good idea. I know 
> they have strange semantics. However, I don't know all the issues. In 
> any case, I'm looking forward to playing around with this system. I have 
> used the Ada community's ASIS some. ASIS is a standard library that 
> makes it easy for me to write analysis programs that tap into the Ada 
> compiler's parse tree and symbol table information. I thought that it 
> would be nice to have something like that for C++ and it seems like 
> OpenC++ might be just that thing. Now if only I can find the time to 
> play...

Hi Peter,

I'v been playing with the OpenC++ code for a couple of years, until
I realized that to be really useful it required a number of serious
improvements that couldn't be made incrementally.

I'm now working on synopsis (http://synopsis.fresco.org), which aims at
exactly what you are looking for: a set of APIs to introspect various
representations of the source code such as parse tree, symbol table,
or (abstract) syntax tree.
The code is based on OpenC++ (from which it forked about six years ago),
but is evolving quickly. It provides C++ and python bindings for its APIs.
Right now I'm working on a complete parser rewrite, which works similar
to the g++ parser, i.e. instead of postponing symbol table creation to
a second phase, it builds and uses the symbol table during the first
phase, to disambiguate the syntax.

The generated parse tree is similar but not identical to the one generated
by OpenC++. It aims at full ISO C++ conformance.

Just a FYI...

Regards,
		Stefan

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Peter C. C. <pc...@so...>]

Jonathan Gdalevich wrote:

>I had a similar problem when I first started using it.  Scott D. Fleming
>gave me the following advice...
>  
>
Thanks for your note. The changes you made fixed the compilation issue. 
During 'make check' I get failures during the 'compilation-via-plug-in' 
tests that seem to be Cygwin related. The log file shows libtool 
complaining about undefined references in a shared library and 
explicitly says that they are not allowed under Cygwin. I imagine these 
errors are to be expected.

I'm not sure if trying to swap auto_ptrs at all is a good idea. I know 
they have strange semantics. However, I don't know all the issues. In 
any case, I'm looking forward to playing around with this system. I have 
used the Ada community's ASIS some. ASIS is a standard library that 
makes it easy for me to write analysis programs that tap into the Ada 
compiler's parse tree and symbol table information. I thought that it 
would be nice to have something like that for C++ and it seems like 
OpenC++ might be just that thing. Now if only I can find the time to play...

Peter

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Stefan S. <se...@sy...>]

Jonathan Gdalevich wrote:

> The problem is that in gcc 3.4.x std::auto_ptrs can't be swapped with
> std::swap. I assume this is a bug in the STL, and not a feature. The

Apparently not:

http://gcc.gnu.org/ml/libstdc++/2004-11/msg00086.html

Regards,
		Stefan

Re: [Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Jonathan G. <gt...@ma...>]

Peter C. Chapin wrote:

> Hello!
>
> I'm attempting to compile OpenC++ under Cygwin on my Windows XP
> machine. The compile is failing during the processing of driver.cc
> with the following message:
>
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algobase.h: In
> function `void std::swap(_Tp&, _Tp&) [with _Tp =
> std::auto_ptr<Opencxx::MetacompilerConfiguration::IteratorIface>]':
> ../opencxx/MetacompilerConfiguration.h:50:   instantiated from here
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algobase.h:132:
> error: passing `const
> std::auto_ptr<Opencxx::MetacompilerConfiguration::IteratorIface>' as
> `this' argument of `std::auto_ptr<_Tp>::operator
> std::auto_ptr_ref<_Tp1>() [with _Tp1 =
> Opencxx::MetacompilerConfiguration::IteratorIface, _Tp = Opencxx::Meta
> compilerConfiguration::IteratorIface]' discards qualifiers
>
> It looks like I'm trying to convert a const auto_ptr to an
> auto_ptr_ref and gcc isn't going for it. I'm using v3.4.4 and I'm
> wondering if perhaps the code was originally written for an older
> version of the compiler. Would I be better advised to use the CVS
> version over the current official version? The message above came
> during an attempt to compile v2.8.
>
> Thanks!
>
> Peter
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>
Hi,

I had a similar problem when I first started using it.  Scott D. Fleming
gave me the following advice:

The problem is that in gcc 3.4.x std::auto_ptrs can't be swapped with
std::swap. I assume this is a bug in the STL, and not a feature. The
reason for the problem is that std::swap has a const tmp variable; i.e.
(from bits/stl_algobase.h):

  template<typename _Tp>
    inline void
    swap(_Tp& __a, _Tp& __b)
    {
      // concept requirements
      __glibcxx_function_requires(_SGIAssignableConcept<_Tp>)

      const _Tp __tmp = __a; // <---THIS CAUSES std::auto_ptr PROBLEMS
      __a = __b;
      __b = __tmp;
    }

And std::auto_ptr's auto_ptr_ref operator, which is called in the const
line above, is a non-const method; i.e. (from memory.h):

  template<typename _Tp>
    class auto_ptr
    {
      ...
      template<typename _Tp1>
        operator auto_ptr_ref<_Tp1>() throw()
        { return auto_ptr_ref<_Tp1>(this->release()); }
      ...

My solution to the problem was add my own swap function to the OpenC++
code, and  use it to swap std::auto_ptrs. To accomplish this, I edited
the MetacompilerConfiguration.h file in the OpenC++ source. I added this
function definition near the top of the file just under "class ErrorLog":

  template<class T>
  inline void
  MYswap(std::auto_ptr<T>& a, std::auto_ptr<T>& b)
  {
    std::auto_ptr<T> c = a;
    a = b;
    b = c;
  }

Next (in the same file), I changed class
MetacompilerConfiguration::Iterator (found in the public section of
class MetacompilerConfiguration), so that its operator= went from:

        Iterator& operator=(Iterator iter)
        {
            std::swap(impl_, iter.impl_);
            return *this;
        }

To:

        Iterator& operator=(Iterator iter)
        {
            MYswap(impl_, iter.impl_);
            return *this;
        }

And this solved the problem for me, and I expect it will for you as well.

Now, I must warn you that there is another problem you will encounter
with OpenC++ once you have built it. There is a mistake in the grammar
that OpenC++'s parser expects. Prior to GCC 3.4, this was never a
problem, but since GCC 3.4, the STL library uses the syntax that the
broken grammar doesn't accept. In particular OpenC++ expects template
declarations to look like this:

  template<typename T>...

With an identifier like "T" following typename, but in fact the
following is legal C++:

  template<typename>...

This causes occ to issue errors whenever it parses the GCC library files
that include the latter syntax (e.g., bits/cpp_type_traits.h). I fixed
the problem by changing the Parser::rTempArgDeclaration member function
definition in parser/Parser.cc. I changed this line (roughly the third
line in the function):

    if(t0 == CLASS && lex->LookAhead(1) == Identifier){

To this:

    if(t0 == CLASS && !(lex->LookAhead(1) == Identifier)){
        lex->GetToken(tk1);
        decl = PtreeUtil::List(new Leaf(tk1));
    }
    else if(t0 == CLASS && lex->LookAhead(1) == Identifier){

I am not positive that my Ptree representation for the template argument
declaration (temp.arg.declaration) is exactly what the OpenC++
maintainers would want, but it seemed to make sense to me.

Anyway, I hope these fixes help you get OpenC++ running. I've been using
it for a couple of years, and it's really a lovely tool.
Cheers, Scott

PS: There is one other fix that you will probably want to apply, found in:

    http://sourceforge.net/mailarchive/message.php?msg_id=9785370


Afterwards, it solved the compile problem but still did not work.  I had
to get his version on OpenC++ before it started working. 

Good Luck,

-- 
Jonathan Gdalevich
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gt...@pr...

[Opencxx-users] Problem compiling OpenC++ on Cygwin.

[Peter C. C. <pc...@so...>]

Hello!

I'm attempting to compile OpenC++ under Cygwin on my Windows XP machine. 
The compile is failing during the processing of driver.cc with the 
following message:

/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algobase.h: In 
function `void std::swap(_Tp&, _Tp&) [with _Tp = 
std::auto_ptr<Opencxx::MetacompilerConfiguration::IteratorIface>]': 
../opencxx/MetacompilerConfiguration.h:50:   instantiated from here
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_algobase.h:132: 
error: passing `const 
std::auto_ptr<Opencxx::MetacompilerConfiguration::IteratorIface>' as 
`this' argument of `std::auto_ptr<_Tp>::operator 
std::auto_ptr_ref<_Tp1>() [with _Tp1 = 
Opencxx::MetacompilerConfiguration::IteratorIface, _Tp = Opencxx::Meta 
compilerConfiguration::IteratorIface]' discards qualifiers

It looks like I'm trying to convert a const auto_ptr to an auto_ptr_ref 
and gcc isn't going for it. I'm using v3.4.4 and I'm wondering if 
perhaps the code was originally written for an older version of the 
compiler. Would I be better advised to use the CVS version over the 
current official version? The message above came during an attempt to 
compile v2.8.

Thanks!

Peter