opencxx-users

[Opencxx-users] Porting OpenCXX

[Thomas E. <te-...@en...>]

Hi,

I currently wanted to evaluate OpenCXX for generation of language 
bindings of crufty old C code into some reflectable languages on 
MacOS X.

The 2.8 distribution has a bunch of problems:

- with the normal automake / autoconf / make chain there is a problem 
that in most of the makefiles libtool is invoked, not something 
configurable (glibtool on OS X) or the local libtool 
($OPENCXX/libtool).

- compiled, one of the samples (IIRC verbose2) produces an coredump. 
The problem is the sample tries to write to cout at static 
initialisation time. The init order is _not_ guaranteed by the ANSI 
Standard - while it is desirable std::cout is usuable all the time, 
the only thing that is guaranteed is it is usuable when program 
execution reaches the first line of main();

- With an more rigid ANSI compliant standard library implementation 
(Metrowerks Codewarrior) there are compile errors due to missing 
namespace using clauses in a whole bunch of files

ChangedMemberList.cc -> using std::memmove

Error   : undefined identifier 'strlen'
auxil.cc line 28       int len = strlen(src);

Error   : undefined identifier 'strcpy'
auxil.cc line 30       return strcpy(result, src);

etc...

Regards,
	Tom_E

Re: [Opencxx-users] Porting OpenCXX

[Grzegorz J. <ja...@ac...>]

Thomas Engelmeier wrote:
> Hi,
> 
> I currently wanted to evaluate OpenCXX for generation of language 
> bindings of crufty old C code into some reflectable languages on MacOS X.
> 
> The 2.8 distribution has a bunch of problems:
> 
> - with the normal automake / autoconf / make chain there is a problem 
> that in most of the makefiles libtool is invoked, not something 
> configurable (glibtool on OS X) or the local libtool ($OPENCXX/libtool).

You mean during building OpenC++ or compiling with OpenC++?

> - compiled, one of the samples (IIRC verbose2) produces an coredump. The 
> problem is the sample tries to write to cout at static initialisation 
> time. The init order is _not_ guaranteed by the ANSI Standard - while it 
> is desirable std::cout is usuable all the time, the only thing that is 
> guaranteed is it is usuable when program execution reaches the first 
> line of main();
> 
> - With an more rigid ANSI compliant standard library implementation 
> (Metrowerks Codewarrior) there are compile errors due to missing 
> namespace using clauses in a whole bunch of files

That's very valuable feedback. Could you send a patch agains 2.8 for these?

Thanks!
Grzegorz

> 
> ChangedMemberList.cc -> using std::memmove
> 
> Error   : undefined identifier 'strlen'
> auxil.cc line 28       int len = strlen(src);
> 
> Error   : undefined identifier 'strcpy'
> auxil.cc line 30       return strcpy(result, src);
> 
> etc...
> 
> Regards,
>     Tom_E
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users

Re: [Opencxx-users] Porting OpenCXX

[Thomas E. <te-...@en...>]

At 21:50 Uhr +0800 05.11.2004, Grzegorz Jakacki wrote:

Hi Grzegorz,

>>- with the normal automake / autoconf / make chain there is a 
>>problem that in most of the makefiles libtool is invoked, not 
>>something configurable (glibtool on OS X) or the local libtool 
>>($OPENCXX/libtool).
>
>You mean during building OpenC++ or compiling with OpenC++?

Both. Most of the Makefiles refer to libtool even if $LIBTOOL is 
defined, and the occ2 script does the same...

>>- compiled, one of the samples (IIRC verbose2) produces an 
>>coredump. The problem is the sample tries to write to cout at 
>>static initialisation time. The init order is _not_ guaranteed by 
>>the ANSI Standard - while it is desirable std::cout is usuable all 
>>the time, the only thing that is guaranteed is it is usuable when 
>>program execution reaches the first line of main();
>>
>>- With an more rigid ANSI compliant standard library implementation 
>>(Metrowerks Codewarrior) there are compile errors due to missing 
>>namespace using clauses in a whole bunch of files
>
>That's very valuable feedback. Could you send a patch agains 2.8 for these?

If I figure out how to diff directories, yes ;-).
Whom should I send it to? (I'm not a fan of huge compiler error or 
patchfile attachment on mailinglists)...

Regards,
	Tom_E

Re: [Opencxx-users] Porting OpenCXX

[Grzegorz J. <ja...@ac...>]

Thomas Engelmeier wrote:
> At 21:50 Uhr +0800 05.11.2004, Grzegorz Jakacki wrote:
> 
> Hi Grzegorz,
> 
>>> - with the normal automake / autoconf / make chain there is a problem 
>>> that in most of the makefiles libtool is invoked, not something 
>>> configurable (glibtool on OS X) or the local libtool ($OPENCXX/libtool).
>>
>>
>> You mean during building OpenC++ or compiling with OpenC++?
> 
> 
> Both. Most of the Makefiles refer to libtool even if $LIBTOOL is 
> defined, and the occ2 script does the same...
> 
>>> - compiled, one of the samples (IIRC verbose2) produces an coredump. 
>>> The problem is the sample tries to write to cout at static 
>>> initialisation time. The init order is _not_ guaranteed by the ANSI 
>>> Standard - while it is desirable std::cout is usuable all the time, 
>>> the only thing that is guaranteed is it is usuable when program 
>>> execution reaches the first line of main();
>>>
>>> - With an more rigid ANSI compliant standard library implementation 
>>> (Metrowerks Codewarrior) there are compile errors due to missing 
>>> namespace using clauses in a whole bunch of files
>>
>>
>> That's very valuable feedback. Could you send a patch agains 2.8 for 
>> these?
> 
> 
> If I figure out how to diff directories, yes ;-).

diff -r

> Whom should I send it to? (I'm not a fan of huge compiler error or 
> patchfile attachment on mailinglists)...

It's OK on this list.

BR
Grzegorz

Re: [Opencxx-users] Porting OpenCXX

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

On Fri, 2004-11-05 at 08:05, Thomas Engelmeier wrote:
> Hi,
> 
> I currently wanted to evaluate OpenCXX for generation of language 
> bindings of crufty old C code into some reflectable languages on 
> MacOS X.
> 
> The 2.8 distribution has a bunch of problems:
> 
> - with the normal automake / autoconf / make chain there is a problem 
> that in most of the makefiles libtool is invoked, not something 
> configurable (glibtool on OS X) or the local libtool 
> ($OPENCXX/libtool).

Thomas thinks for your report.

>From the top_srcdir directory,
where the tarball has been decompressed
or checkout from cvs.

Executing the following command line
$ for i in `find -name Makefile.am`; do \
    echo "check in $i"; \
    grep libtool $i; \
  done

I have, the following output
check in ./Makefile.am
# use to automatically update the libtool script if it becomes
# out-of-date." [libtool.info]
libtool: $(LIBTOOL_DEPS)
check in ./buildinfo/Makefile.am
check in ./examples/before/Makefile.am
check in ./examples/matrix/Makefile.am
check in ./examples/runtime-mop/Makefile.am
check in ./examples/verbose/Makefile.am
check in ./examples/verbose2/Makefile.am
check in ./examples/wrapper/Makefile.am
check in ./examples/Makefile.am
check in ./html/Makefile.am
check in ./libltdl/Makefile.am
$(libltdl_la_OBJECTS) $(libltdlc_la_OBJECTS): libtool
libtool: $(LIBTOOL_DEPS)
        -rm -rf $(DESTDIR)$(datadir)/libtool/libltdl
        $(mkinstalldirs) $(DESTDIR)$(datadir)/libtool/libltdl
            cp -r $$d/$$file
$(DESTDIR)$(datadir)/libtool/libltdl/$$file; \
            test -f $(DESTDIR)$(datadir)/libtool/libltdl/$$file \
            || cp $$d/$$file $(DESTDIR)$(datadir)/libtool/libltdl/$$file
|| :; \check in ./opencxx/Makefile.am
check in ./scripts/Makefile.am
check in ./src/Makefile.am
# note, that we are using libtool, so it is libgc.la, not libgc.a
#     and libocc library; libocc is linked with libtool;
#     link the same object file with and without libtool;
#     for each source---for linking with and without libtool;
#     process, so that executable is obtained from libtool library.
# We want to make libtool library (.la)
check in ./testsuite/Makefile.am

This result let me beleive that the autoconf/automake tools
have not done their intended works.
the Makefile.in's and Makefile's file are generated files.

** i have absolutely no knowledge of MacOS X **, we can read from
http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/index.html?http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/revision_history/chapter_12_section_1.html
but this does not help us since it is the command line "libtool"
that is wrongly substituted in the Makefile.
That is, you what the command line "glibtool" instead for your system.

=====
check in ./libltdl/Makefile.am
in
http://developer.apple.com/documentation/DeveloperTools/glibtool/libtool_10.html
paragraph How to distribute libltdl with your package

   In order to embed libltdl into your package, just add `--ltdl'
   to the libtoolize command line. It will copy the libltdl sources
   to a subdirectory `libltdl' in your package. Both macros accept
   an optional argument to specify the location of the
   `libltdl' directory. By the default both macros assume
   that it is `${top_srcdir}/libltdl'.

You must read, the sources files provided in opencxx are not for
Mac OS X.  Used the already install "libltdl.so" from already
install package.

If you intend for testing purpose
or others reasons compile that library,
you must do
$ libtoolize --copy --automake --ltdl
before running './bootstrap' script from your top_scrdir of opencxx,
but I also expect that you know what you are doing.

That was to say,
step 1, ./bootstrap
step 2, ./configure ...
step 3, ./make ...
are the normal step.

During the make,
you will compile nothing in libltdl directory,
you will link nothing in libltdl directory.

hope this help
Gilles

> - compiled, one of the samples (IIRC verbose2) produces an coredump. 
> The problem is the sample tries to write to cout at static 
> initialisation time. The init order is _not_ guaranteed by the ANSI 
> Standard - while it is desirable std::cout is usuable all the time, 
> the only thing that is guaranteed is it is usuable when program 
> execution reaches the first line of main();
> 
> - With an more rigid ANSI compliant standard library implementation 
> (Metrowerks Codewarrior) there are compile errors due to missing 
> namespace using clauses in a whole bunch of files
> 
> ChangedMemberList.cc -> using std::memmove
> 
> Error   : undefined identifier 'strlen'
> auxil.cc line 28       int len = strlen(src);
> 
> Error   : undefined identifier 'strcpy'
> auxil.cc line 30       return strcpy(result, src);
> 
> etc...

I will recheck those one

> Regards,
> 	Tom_E