opencxx-users

Re: [Opencxx-users] Cygwin problem

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

Hi ???????,

It looks like a problem with garbage collector. From the logs I can see 
that you are using 2.7; to disable gc in 2.7 you need to define DONT_GC 
preproc symbol, this should do:

     ./configure CPPFLAGS=-DDONT_GC ...

If you feel adventurous, you may try to checkout the lates sources from 
CVS, AFAIK this version has not been tried on XP+cygwin yet. For CVS 
snapshot you can disable gc like this:

     ./configure --diable-gc

If this works, then you have choice: either you live without gc (it is 
ok in many situations, since occ quits after processing anyway, so 
usually allocation build-up is not huge) or investigate further.

Please let me know if the above works for you.

Regards
Grzegorz


?????????? ??????? wrote:
> Hello!
>  
> I have a problem during installation openc++ under WinXP Professional & 
> Cygwin.
> occ.exe receive signal 11 any time I try to use it.
>  
> All log files are in an attachment.
> 'make2.log' file is stderr output of 'make test' command
>  
> What shell I do?
> Thank you.

Re: [Opencxx-users] Cygwin problem

[?????????? ??????? <pos...@na...>]

Hello!

I am sorry for my silence.

I tried your method and configured whith following:
./configure CPPFLAGS=-DDONT_GC

It was an error message:

g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../gc/include -DDONT_GC -g -O2 -MT
main-con.l
o -MD -MP -MF .deps/main-con.Tpo -c main-con.cc -o main-con.o
main-con.cc: In function `int main(int, char**)':
main-con.cc:76: error: `GC_init' undeclared (first use this function)
main-con.cc:76: error: (Each undeclared identifier is reported only once for
   each function it appears in.)
make[2]: *** [main-con.lo] Error 1

I fixed main-con.cc by this way:

#ifndef DONT_GC
 GC_init(); // This is mandatory and must be called before any other GC
function.
#endif

Unfortunately it does not works for me. I still receive segmentation fault
signal on each test.
When using gdb the first step after the 75-th string of main-con.cc is the
77-th string of iostream.
Next step produce SIGSEGV.

I have some problems with dynamic linking under Cygwin. There are
differences between Cygwin and Linux and I do not understand their enought.
So I undefined USE_DLOADER and SHARED_OPTION preproc symbols in driver2.cc.
After that I linked my meta-class with occ statically. It works! But I do
not know why...

Thank you,
Grigorenko Dmitriy

----- Original Message -----
From: "Grzegorz Jakacki" <ja...@ac...>
To: "?????????? ???????" <pos...@na...>
Cc: <ope...@li...>
Sent: Monday, June 28, 2004 2:20 PM
Subject: Re: [Opencxx-users] Cygwin problem


> Hi ???????,
>
> It looks like a problem with garbage collector. From the logs I can see
> that you are using 2.7; to disable gc in 2.7 you need to define DONT_GC
> preproc symbol, this should do:
>
>      ./configure CPPFLAGS=-DDONT_GC ...
>
> If you feel adventurous, you may try to checkout the lates sources from
> CVS, AFAIK this version has not been tried on XP+cygwin yet. For CVS
> snapshot you can disable gc like this:
>
>      ./configure --diable-gc
>
> If this works, then you have choice: either you live without gc (it is
> ok in many situations, since occ quits after processing anyway, so
> usually allocation build-up is not huge) or investigate further.
>
> Please let me know if the above works for you.
>
> Regards
> Grzegorz
>
>
> ?????????? ??????? wrote:
> > Hello!
> >
> > I have a problem during installation openc++ under WinXP Professional &
> > Cygwin.
> > occ.exe receive signal 11 any time I try to use it.
> >
> > All log files are in an attachment.
> > 'make2.log' file is stderr output of 'make test' command
> >
> > What shell I do?
> > Thank you.
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Opencxx-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opencxx-users
>

Re: [Opencxx-users] Cygwin problem

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

?????????? ??????? wrote:
> Hello!
> 
> I am sorry for my silence.
> 
> I tried your method and configured whith following:
> ./configure CPPFLAGS=-DDONT_GC
> 
> It was an error message:
> 
> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../gc/include -DDONT_GC -g -O2 -MT
> main-con.l
> o -MD -MP -MF .deps/main-con.Tpo -c main-con.cc -o main-con.o
> main-con.cc: In function `int main(int, char**)':
> main-con.cc:76: error: `GC_init' undeclared (first use this function)
> main-con.cc:76: error: (Each undeclared identifier is reported only once for
>    each function it appears in.)
> make[2]: *** [main-con.lo] Error 1
> 
> I fixed main-con.cc by this way:
> 
> #ifndef DONT_GC
>  GC_init(); // This is mandatory and must be called before any other GC
> function.
> #endif
> 
> Unfortunately it does not works for me. I still receive segmentation fault
> signal on each test.
> When using gdb the first step after the 75-th string of main-con.cc is the
> 77-th string of iostream.
> Next step produce SIGSEGV.

This 77-th line of iostream looks like a bug in debugger or compiler 
(invalid debugging information), I remember that I had similar problems 
somewhere else.

 From your description it is difficult to tell where the sigfault really 
happens. As far as I understand line 75 is the first line of main(). 
Perhaps the segfault happens during initialization of static variables.
One way to find out would be to load core file to gdb ('gdb occ core')
and examine stack trace ('bt').

> I have some problems with dynamic linking under Cygwin. There are
> differences between Cygwin and Linux and I do not understand their enought.
> So I undefined USE_DLOADER and SHARED_OPTION preproc symbols in driver2.cc.
> After that I linked my meta-class with occ statically. It works! But I do
> not know why...

If you need to get dynamic linking to work I would recommend trying CVS 
HEAD.

Please let me know if I can be of any further help.

Best regards
Grzegorz


> 
> Thank you,
> Grigorenko Dmitriy
> 
> ----- Original Message -----
> From: "Grzegorz Jakacki" <ja...@ac...>
> To: "?????????? ???????" <pos...@na...>
> Cc: <ope...@li...>
> Sent: Monday, June 28, 2004 2:20 PM
> Subject: Re: [Opencxx-users] Cygwin problem
> 
> 
> 
>>Hi ???????,
>>
>>It looks like a problem with garbage collector. From the logs I can see
>>that you are using 2.7; to disable gc in 2.7 you need to define DONT_GC
>>preproc symbol, this should do:
>>
>>     ./configure CPPFLAGS=-DDONT_GC ...
>>
>>If you feel adventurous, you may try to checkout the lates sources from
>>CVS, AFAIK this version has not been tried on XP+cygwin yet. For CVS
>>snapshot you can disable gc like this:
>>
>>     ./configure --diable-gc
>>
>>If this works, then you have choice: either you live without gc (it is
>>ok in many situations, since occ quits after processing anyway, so
>>usually allocation build-up is not huge) or investigate further.
>>
>>Please let me know if the above works for you.
>>
>>Regards
>>Grzegorz
>>
>>
>>?????????? ??????? wrote:
>>
>>>Hello!
>>>
>>>I have a problem during installation openc++ under WinXP Professional &
>>>Cygwin.
>>>occ.exe receive signal 11 any time I try to use it.
>>>
>>>All log files are in an attachment.
>>>'make2.log' file is stderr output of 'make test' command
>>>
>>>What shell I do?
>>>Thank you.
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by Black Hat Briefings & Training.
>>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>>digital self defense, top technical experts, no vendor pitches,
>>unmatched networking opportunities. Visit www.blackhat.com
>>_______________________________________________
>>Opencxx-users mailing list
>>Ope...@li...
>>https://lists.sourceforge.net/lists/listinfo/opencxx-users
> 
>>

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hello.

> This 77-th line of iostream looks like a bug in debugger or compiler
> (invalid debugging information), I remember that I had similar problems
> somewhere else.
Your are right. I found that problem is in the lt_dlinit() call (the first
call of the ltdl function). You can find it in
the InitDynamicLoader() function in driver2.cc. I checked that sigfault
heppens befor the first line of lt_dlinit and befor the first line of the
main function in ltdl. (We have to add an empty main funcion in ltdl.c).
I  investigated that in case of static linking occ which ltdl.o (instead of
using -lltdl) it is all right!
So I think that problem is in the linking process. Namely, I think what the
lt_dlinit() function address is incorrect.

>  From your description it is difficult to tell where the sigfault really
> happens. As far as I understand line 75 is the first line of main().
> Perhaps the segfault happens during initialization of static variables.
> One way to find out would be to load core file to gdb ('gdb occ core')
> and examine stack trace ('bt').
It does not work on cygwin stackdump file in this way.
Error: "occ.exe.stackdump" is not a core dump: File
format not recognized

Re: [Opencxx-users] Cygwin problem

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

Grigorenko Dmitriy wrote:

> Your are right. I found that problem is in the lt_dlinit() call (the first
> call of the ltdl function). You can find it in
> the InitDynamicLoader() function in driver2.cc. I checked that sigfault
> heppens befor the first line of lt_dlinit and befor the first line of the
> main function in ltdl. (We have to add an empty main funcion in ltdl.c).
> I  investigated that in case of static linking occ which ltdl.o (instead of
> using -lltdl) it is all right!
> So I think that problem is in the linking process. Namely, I think what the
> lt_dlinit() function address is incorrect.

This sounds strangely familiar. I had lots of trouble with initialization
code that was due to the undefined order of global variable initialization.
We eventually replaced all global variables (in synopsis) by alternatives
(singletons, explicit initialization, etc.) and the problem disappeared.

May be there are somewhere some global variables left in opencxx...

Regards,
		Stefan

Re: [Opencxx-users] Cygwin problem

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

Hi,

Grigorenko Dmitriy wrote:
> Hello.
> 
> 
>>This 77-th line of iostream looks like a bug in debugger or compiler
>>(invalid debugging information), I remember that I had similar problems
>>somewhere else.
> 
> Your are right. I found that problem is in the lt_dlinit() call (the first
> call of the ltdl function). You can find it in
> the InitDynamicLoader() function in driver2.cc. I checked that sigfault
> heppens befor the first line of lt_dlinit and befor the first line of the
> main function in ltdl. (We have to add an empty main funcion in ltdl.c).
> I  investigated that in case of static linking occ which ltdl.o (instead of
> using -lltdl) it is all right!

Congratulations, very nice workaround.

> So I think that problem is in the linking process. Namely, I think what the
> lt_dlinit() function address is incorrect.

That very well may be. However, I would also check if by any chance 
dynamic linker is not picking another version of libltdl installed 
somewhere else on your system. On my Linux there is 'ldd' utility for 
this purpose, I am not sure about Cygwin.

If this is a genuine bug on Cygwin (and this is likely, since I have 
heard about similar problems from three other persons), then I will fix 
it in HEAD by following your workaround.

Thanks
Grzegorz

>> From your description it is difficult to tell where the sigfault really
>>happens. As far as I understand line 75 is the first line of main().
>>Perhaps the segfault happens during initialization of static variables.
>>One way to find out would be to load core file to gdb ('gdb occ core')
>>and examine stack trace ('bt').
> 
> It does not work on cygwin stackdump file in this way.
> Error: "occ.exe.stackdump" is not a core dump: File
> format not recognized

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hi

> Congratulations, very nice workaround.
Thank`s

> That very well may be. However, I would also check if by any chance 
> dynamic linker is not picking another version of libltdl installed 
> somewhere else on your system. On my Linux there is 'ldd' utility for 
> this purpose, I am not sure about Cygwin.
I checked that it does not compile without ltdt libs.

Re: [Opencxx-users] Cygwin problem

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

Grigorenko Dmitriy wrote:
> Hello
> 
> I checked which library is used by occ.
> 
> H:\cygwin\home\Dima\opencxx-2.7\src>cygcheck occ
> Found: .\occ.exe
> occ.exe
>   h:\cygwin\bin\cygltdl-3.dll
>     h:\cygwin\bin\cygwin1.dll
>       H:\WINDOWS\System32\ADVAPI32.DLL
>         H:\WINDOWS\System32\ntdll.dll
>         H:\WINDOWS\System32\KERNEL32.dll
>         H:\WINDOWS\System32\RPCRT4.dll
> 

Yes, this is exactly the information that was needed.

As you see when occ.exe is loaded the dynamic linker will pick the 
global cygltdl.dll;

> It couses sigsegv when cygltdl-3.dll builds from opencxx/libltdl.
> In case of native cygltdl-3.dll using it`s ok.

I suppose that the version of ltdl in opencxx/libltdl is different from 
your system-wide version. The problem is that ld sets function offsets 
in occ.exe according to the layout of opencxx/cygltdl-3.dll, but at 
load-time /cygwin/bin/cygltdl-3.dll is linked dynamically and there is a 
mismatch between offsets and entries in /cygwin/bin/cygltdl-3.dll

> Why does it make libltdl instead of using the native one?

I had problems on Compile Farm --- the version of libtool installed 
there system-wide was too old and crashed with libgc. So I decided to 
force occ to use the libltdl bundled with OpenC++.

> How can it be fixed?

(1) On Linux you can tell the dynamic linker where to look for
shared libraries by setting the environment variable LD_LIBRARY_PATH. 
There must be a way to tell this to cygwin dynamic linker also. This 
will instruct dynamic linker to pick opencxx/libltdl/cygltdl-3.dll, not 
the system-wide one.

(2) Another solution would be to make OpenC++ by default use system-wide 
cygltdl.dll on Cygwin, as anyway there is no Cygwin on Compile Farm. 
This requires modifying configure.in/Makefile.am, so that it does not 
use libltdl if it is installed. The key point that needs to be changed 
is --enable-ltdl-install in Makefile.am, because it forces installation 
of libltdl.so/cygltdl-3.dll even if it is already present.

(3) Ultimate solution, which I think is the way to go in the long term, 
would be to

   - remove libltdl from OpenC++ at all
   - add --with-libltdl=DIR to ./configure

Then OpenC++ will use system-wide libltdl by default. On Compile Farm 
the tests build would be configured with

   ./configure --with-libltdl=PATH_TO_RECENT_VERSION_OF_LIBLTDL.

If you could help with implementing (2) or (3), please do.

> Thank you
> 
> P.S. Your last letter was only for me, not for the hole mail list. Is it
> right?

I am sorry, I make this mistake recently. I switched from Pine to 
Mozilla and they handle replies differently (when replying in Pine you 
have an option to reply to all, but in Mozilla it by default replies 
only to main recipient). As the thread came from the list, I intended to 
reply to the list. Sorry again, I am forwarding these e-mails.

BR
Grzegorz

Re: [Opencxx-users] Cygwin problem

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

On Wed, 2004-07-14 at 11:16, Grzegorz Jakacki wrote:
> Grigorenko Dmitriy wrote:
> > Hello
> > 
> > I checked which library is used by occ.
> > 
> > H:\cygwin\home\Dima\opencxx-2.7\src>cygcheck occ
> > Found: .\occ.exe
> > occ.exe
> >   h:\cygwin\bin\cygltdl-3.dll
> >     h:\cygwin\bin\cygwin1.dll
> >       H:\WINDOWS\System32\ADVAPI32.DLL
> >         H:\WINDOWS\System32\ntdll.dll
> >         H:\WINDOWS\System32\KERNEL32.dll
> >         H:\WINDOWS\System32\RPCRT4.dll
> > 
> 
> Yes, this is exactly the information that was needed.
> 
> As you see when occ.exe is loaded the dynamic linker will pick the 
> global cygltdl.dll;
> 
> > It couses sigsegv when cygltdl-3.dll builds from opencxx/libltdl.
> > In case of native cygltdl-3.dll using it`s ok.
> 
> I suppose that the version of ltdl in opencxx/libltdl is different
> from your system-wide version. The problem is that ld sets function
> offsets in occ.exe according to the layout of opencxx/cygltdl-3.dll,
> but at load-time /cygwin/bin/cygltdl-3.dll is linked dynamically
> and there is a mismatch between offsets and entries
> in /cygwin/bin/cygltdl-3.dll

I suspect two problems
- When libtool package is install, the make tool must not
  compile anything in the libltdl subdirectory.
  Even less, link to produce a static and/or shared libraries.
  a) Usely two packages are provided,
     that is libtool-lib and libtool.
     libtool-lib package provides  cygltdl-3.dll, that is for user
     libtool provide the Software Development Kit,
     that is for developer.

  b) the subdirectory libltdl in cvs is not for cygwin.
     neither the bootstrap script enough powerfull to detect
     your platform.  Present alternative is to
     - delete the libltdl subdirectory
     - in top_srcdir execute foolwing equivalent cli command,
       $ libtoolize --automake --copy --ltdl
       What is desired, option --ltdl ask to copy your
       platform ltdl.h and ltdl.c in libltdl subdirectory.

  c) step b) is *not* supposed to be required.
     but may be require to do test or check.
     We have hardwire dependency in the Makefile.
     Solution, removed them

diff -u -r1.7.2.1 Makefile.am
--- opencxx/Makefile.am 11 Jul 2004 02:07:32 -0000 1.7.2.1
+++ opencxx/Makefile.am 12 Jul 2004 19:28:08 -0000
@@ -44,13 +44,13 @@
 occ_SOURCES    = MetaclassPreregistration.cc
 occ_LDADD      = libocc.la
 occ_LDFLAGS    = -export-dynamic
-INCLUDES       = -I$(top_srcdir) -I$(top_srcdir)/libltdl
+INCLUDES       = -I$(top_srcdir) $(INCLTDL)
 
 lib_LTLIBRARIES        = libocc.la
 libocc_la_SOURCES = empty_libocc.cc
 libocc_la_LIBADD       = \
                opencxx/libocc_mop.la   \
-               libltdl/libltdl.la      \
+               $(LIBLTDL) \
                $(libgc)
 
 include_HEADERS        = mop.h

diff -u -r1.2.2.2 Makefile.am
--- opencxx/opencxx/Makefile.am 11 Jul 2004 02:07:32 -0000 1.2.2.2
+++ opencxx/opencxx/Makefile.am 12 Jul 2004 19:34:12 -0000
@@ -119,7 +119,7 @@
 EXTRA_DIST     = \
                parser/ptree-gen.in
 
-INCLUDES = -I$(builddir) -I$(top_srcdir) -I$(top_srcdir)/libltdl 
+INCLUDES = -I$(builddir) -I$(top_srcdir) $(INCLTDL)
 
 lib_LTLIBRARIES                = \
        libocc_mop.la   \
@@ -227,7 +227,7 @@
 parser_test_LDADD = \
        libparser-test.la       \
        libocc_parser.la        \
-       ../libltdl/libltdl.la
+       $(LIBLTDL)
 
 ###################################################################

> > Why does it make libltdl instead of using the native one?

see above

> I had problems on Compile Farm --- the version of libtool installed 
> there system-wide was too old and crashed with libgc. So I decided
> to force occ to use the libltdl bundled with OpenC++.

solutions, link static library libltdl.a

> > How can it be fixed?

./configure --with-ltdl=/my/path/libltdl
we need to verified that your build does it correctly.

> (1) On Linux you can tell the dynamic linker where to look for
> shared libraries by setting the environment variable LD_LIBRARY_PATH.
> There must be a way to tell this to cygwin dynamic linker also.
> This will instruct dynamic linker to pick
> opencxx/libltdl/cygltdl-3.dll, not the system-wide one.

this presuppose that both libraries even if not at the same
location are in fact identical.  You must prove me,
that they are(see above libtoolize -ltdl option).

> (2) Another solution would be to make OpenC++ by default use
> system-wide cygltdl.dll on Cygwin, as anyway there is no Cygwin on
> Compile Farm. This requires modifying configure.in/Makefile.am, so
> that it does not use libltdl if it is installed. The key point that
> needs to be changed is --enable-ltdl-install in Makefile.am,
> because it forces installation of libltdl.so/cygltdl-3.dll

This does not resolve the Compile farm problem,
because you must not be authorized to replace system library.

>  even if it is already present.

Means, the Compile Farm must ensure equivalence to
OCC=LD_PRELOAD=/my/path/libldlt.so.3 /my/path/occ

> (3) Ultimate solution, which I think is the way to go in the long
> term, would be to
> 
>    - remove libltdl from OpenC++ at all

we keep it, it is our development reference.
Others mechanisms provided way around this.

>    - add --with-libltdl=DIR to ./configure
> 
> Then OpenC++ will use system-wide libltdl by default.

Verified that libltdl provide a known working library.
if not, two choice used static or ensure that the ld utility
know how to find the shared library. That is,
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
  during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
  during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
- LD_PRELOAD mechanism.
where LIBDIR=/my/path/opencxx/libtool/.libs/libltdl.so

> On Compile Farm the tests build would be configured with
> 
>    ./configure --with-libltdl=PATH_TO_RECENT_VERSION_OF_LIBLTDL.
> 
> If you could help with implementing (2) or (3), please do.

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hello

> As you see when occ.exe is loaded the dynamic linker will pick the
> global cygltdl.dll;
I`m sorry. The coorect log is here:

H:\...ome\Dima\opencxx-2.7\testbed\bin>cygcheck occ.exe
Found: .\occ.exe
occ.exe
  .\cygltdl-3.dll
    h:\cygwin\bin\cygwin1.dll
      H:\WINDOWS\System32\ADVAPI32.DLL
        H:\WINDOWS\System32\ntdll.dll
        H:\WINDOWS\System32\KERNEL32.dll
        H:\WINDOWS\System32\RPCRT4.dll

The previos one described the case when all is correct.
I`d like to call attention that sigsegv occurs whith the local (opencxx/)
cygltdl-3.dll

> ./configure --with-ltdl=/my/path/libltdl
> we need to verified that your build does it correctly.
I tried
./configure --with-ltdl=/usr/bin
becouse the correct cygltdl-3.dll is in the /usr/bin directory

'make test' do not work properly. It steel uses local ltdl and crashes.

> > (2) Another solution would be to make OpenC++ by default use
> > system-wide cygltdl.dll on Cygwin, as anyway there is no Cygwin on
> > Compile Farm. This requires modifying configure.in/Makefile.am, so
> > that it does not use libltdl if it is installed. The key point that
> > needs to be changed is --enable-ltdl-install in Makefile.am,
> > because it forces installation of libltdl.so/cygltdl-3.dll
>
> This does not resolve the Compile farm problem,
> because you must not be authorized to replace system library.
As far as I understood, the idea is to use system-wide library if it
presents. You must not be authorized to do it.
Unfortunately I do not know autoconf  enough to modify configure.in. At
least once I did not investigate it enough. I`ll try later.

> > (3) Ultimate solution, which I think is the way to go in the long
> > term, would be to
> >
> >    - remove libltdl from OpenC++ at all
>
> we keep it, it is our development reference.
> Others mechanisms provided way around this.
I am agree.

Re: [Opencxx-users] Cygwin problem

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

On Wed, 2004-07-14 at 16:47, Grigorenko Dmitriy wrote:
> Hello
> 
> > As you see when occ.exe is loaded the dynamic linker will pick the
> > global cygltdl.dll;
> I`m sorry. The correct log is here:
> 
> H:\...ome\Dima\opencxx-2.7\testbed\bin>cygcheck occ.exe
> Found: .\occ.exe
> occ.exe
>   .\cygltdl-3.dll
>     h:\cygwin\bin\cygwin1.dll
>       H:\WINDOWS\System32\ADVAPI32.DLL
>         H:\WINDOWS\System32\ntdll.dll
>         H:\WINDOWS\System32\KERNEL32.dll
>         H:\WINDOWS\System32\RPCRT4.dll
> 
> The previos one described the case when all is correct.
> I`d like to call attention that sigsegv occurs whith the local (opencxx/)
> cygltdl-3.dll
> 
> > ./configure --with-ltdl=/my/path/libltdl
> > we need to verified that your build does it correctly.
> I tried
> ./configure --with-ltdl=/usr/bin
> becouse the correct cygltdl-3.dll is in the /usr/bin directory
> 
> 'make test' do not work properly. It steel uses local ltdl and crashes.

does the config.log is created, if yes
$ grep LIBLTDL config.log
LIBLTDL='-lltdl'
$ grep INCLTDL config.log
INCLTDL=''
what are the results

if LIBLTDL is not '-lltdl'
in opencxx/testsuite/tester2.in
we have line
LIBS="-locc @libgc@ -lltdl"
change to
LIBS="-locc @libgc@ @LIBLTDL@"
than do configure in your top_builddir
what is the result of this line

Have you try 'libtoolize --ltdl' before bootstrap script

when running configure, do you have somthing like
checking dependency style of gcc... gcc3
checking for lt_dlinit in -lltdl... yes
checking for gcc... (cached) gcc

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hello

> Dmitriy can you make some tests,
OK

> in config.log, you have
> configure:2886: checking for main in -lltdl
> configure:2911: gcc -o conftest.exe -g -O2   conftest.c -lltdl   >&5
> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld:
> cannot find -lltdl
> collect2: ld returned 1 exit status
> configure:2914: $? = 1
> configure: failed program was:
>
> we want this to pass, saying 'yes'.
I`he downloaded the head of cvs and tried ./configure
The result is in the simple_cfg.log.
As you can see the answer is 'yes' now.
When I type 'make', I get an error message becouse there is no Makefile in
gc directory (so it does not know how to build target 'all'). Why is it so?

> can you try to change configure.in, adding AC_LIBTOOL_WIN32_DLL,
> you will have,
>
> AC_DISABLE_SHARED
> AC_LIBTOOL_WIN32_DLL
> AM_PROG_LIBTOOL
>
> then
>
> libtoolize --force --automake --copy
> ./bootstrap
> ./configure --disable-gc # save compile time
I`ve done it (and I`ve undated my libtool up to 1.5.6)
As you can see,
checking dependency style of gcc... gcc3
checking for lt_dlinit in -lltdl... yes
(no checking for main in -lltdl)
Also there two new warnings:
configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: dlfcn.h: proceeding with the compiler's result

Next step I tried to run make tests and got:
In file included from ../opencxx/parser/Ptree.h:37,
                 from ../opencxx/Class.h:37,
                 from ChangedMemberList.cc:36:
../opencxx/parser/PtreeUtil.h:34:32: opencxx/parser/aux.h: No such file or
direc
tory
make[2]: *** [ChangedMemberList.lo] Error 1

It is right. There is no aux.h in the opencxx/parser. Why is it so?

The result of 'cvn up' command is following:
cvs update: move away opencxx/member.h; it is in the way
C opencxx/member.h
cvs update: Updating opencxx/dll-off
cvs update: Updating opencxx/gc-related-gc-no
cvs update: Updating opencxx/gc-related-gc-yes
cvs update: Updating opencxx/gc-related-gc-yes/dll-off
cvs update: Updating opencxx/gc-related-gc-yes/dll-on
cvs update: Updating opencxx/parser
cvs update: move away opencxx/parser/aux.cc; it is in the way
C opencxx/parser/aux.cc
cvs update: move away opencxx/parser/aux.h; it is in the way
C opencxx/parser/aux.h
cvs update: move away opencxx/parser/ptree.h; it is in the way
C opencxx/parser/ptree.h
cvs update: Updating opencxx/ptree
cvs update: Updating opencxx/ptree/src

How can I download these files?

Thank you

Re: [Opencxx-users] Cygwin problem

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

Grigorenko Dmitriy wrote:
> Hello
> 
> 
>>Dmitriy can you make some tests,
> 
> OK
> 
> 
>>in config.log, you have
>>configure:2886: checking for main in -lltdl
>>configure:2911: gcc -o conftest.exe -g -O2   conftest.c -lltdl   >&5
>>/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld:
>>cannot find -lltdl
>>collect2: ld returned 1 exit status
>>configure:2914: $? = 1
>>configure: failed program was:
>>
>>we want this to pass, saying 'yes'.
> 
> I`he downloaded the head of cvs and tried ./configure
> The result is in the simple_cfg.log.
> As you can see the answer is 'yes' now.
> When I type 'make', I get an error message becouse there is no Makefile in
> gc directory (so it does not know how to build target 'all'). Why is it so?

I suspect that you don't have exact copy of CVS. I am not sure which 
branch you are using (MAIN or rel_2_8), but neither of them contains 
directory 'gc' anymore. Perhaps you need to do 'cvs update -C -P'.

> 
> 
>>can you try to change configure.in, adding AC_LIBTOOL_WIN32_DLL,
>>you will have,
>>
>>AC_DISABLE_SHARED
>>AC_LIBTOOL_WIN32_DLL
>>AM_PROG_LIBTOOL
>>
>>then
>>
>>libtoolize --force --automake --copy
>>./bootstrap
>>./configure --disable-gc # save compile time
> 
> I`ve done it (and I`ve undated my libtool up to 1.5.6)
> As you can see,
> checking dependency style of gcc... gcc3
> checking for lt_dlinit in -lltdl... yes
> (no checking for main in -lltdl)

That's correct, since libltdl shouldn't normally contain main. (I know 
that you need main on cygwin, but this is workaround for a bug.)

> Also there two new warnings:
> configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: dlfcn.h: proceeding with the compiler's result
> 
> Next step I tried to run make tests and got:
> In file included from ../opencxx/parser/Ptree.h:37,
>                  from ../opencxx/Class.h:37,
>                  from ChangedMemberList.cc:36:
> ../opencxx/parser/PtreeUtil.h:34:32: opencxx/parser/aux.h: No such file or
> direc
> tory
> make[2]: *** [ChangedMemberList.lo] Error 1
> 
> It is right. There is no aux.h in the opencxx/parser. Why is it so?
> 

Again, I think you are not in sync with CVS. Viewcvs shows that both 
rel_2_8 and MAIN contain parser/aux.h

http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/opencxx/parser/aux.h?rev=1.2.2.1&only_with_tag=rel_2_8&view=log
http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/opencxx/parser/aux.h?rev=1.2&only_with_tag=MAIN&view=log

BR
Grzegorz

> The result of 'cvn up' command is following:
> cvs update: move away opencxx/member.h; it is in the way
> C opencxx/member.h
> cvs update: Updating opencxx/dll-off
> cvs update: Updating opencxx/gc-related-gc-no
> cvs update: Updating opencxx/gc-related-gc-yes
> cvs update: Updating opencxx/gc-related-gc-yes/dll-off
> cvs update: Updating opencxx/gc-related-gc-yes/dll-on
> cvs update: Updating opencxx/parser
> cvs update: move away opencxx/parser/aux.cc; it is in the way
> C opencxx/parser/aux.cc
> cvs update: move away opencxx/parser/aux.h; it is in the way
> C opencxx/parser/aux.h
> cvs update: move away opencxx/parser/ptree.h; it is in the way
> C opencxx/parser/ptree.h
> cvs update: Updating opencxx/ptree
> cvs update: Updating opencxx/ptree/src
> 
> How can I download these files?
> 
> Thank you

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hello

I renamed ptree.h to ptree2.h and so on. I cannot send you patch for it
becouse I cannot represent the origin version on my FAT :-)

I runned bootstrap. After this there is the configure params:
./configure --disable-gc --enable-ltdl-install --prefix=`pwd`/testbed 2>&1 |
tee cfg.log

There were some warnings:
In file included from /usr/include/c++/3.3.1/backward/strstream:51,
                 from driver.cc:47:
/usr/include/c++/3.3.1/backward/backward_warning.h:32:2: warning: #warning
This
file includes at least one deprecated or antiquated header. Please consider
usin
g one of the 32 headers found in section 17.4.1.2 of the C++ standard.
Examples
include substituting the <X> header for the <X.h> header for C++ includes,
or <s
stream> instead of the deprecated header <strstream.h>. To disable this
warning
use -Wno-deprecated.

/bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
/usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la libltdl/libltdl.la
mkdir .libs
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries

Tests do not work :(. See tester2.log for more details.
But occ does not crash with sigsegv signal!

Re: [Opencxx-users] Cygwin problem

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

Hi!

Grigorenko Dmitriy wrote:
> Hello
> 
> I renamed ptree.h to ptree2.h and so on. 

Gilles renamed files in CVS already.

To avoid holding your changes/patches, could I add you to developers and 
ask that you commit this kind of changes to CVS yourself in the future? 
If you agree, please send me your SourceForge id.

> I cannot send you patch for it
> becouse I cannot represent the origin version on my FAT :-)

I see. AFAIK this is solved already (also 'aux').

> 
> I runned bootstrap. After this there is the configure params:
> ./configure --disable-gc --enable-ltdl-install --prefix=`pwd`/testbed 2>&1 |
> tee cfg.log
> 
> There were some warnings:
> In file included from /usr/include/c++/3.3.1/backward/strstream:51,
>                  from driver.cc:47:
> /usr/include/c++/3.3.1/backward/backward_warning.h:32:2: warning: #warning
> This
> file includes at least one deprecated or antiquated header. Please consider
> usin
> g one of the 32 headers found in section 17.4.1.2 of the C++ standard.
> Examples
> include substituting the <X> header for the <X.h> header for C++ includes,
> or <s
> stream> instead of the deprecated header <strstream.h>. To disable this
> warning
> use -Wno-deprecated.

This is just because of 'strstream'. Unfortunately, gcc-2.95  which is 
still widely used does not have 'sstream', so we either have to live 
with this warning, or provide our own, say, 'sstream-workaround.h' which 
will check if the compiler is gcc-2.95 and include 'strstream' or 
'sstream' respectively.

> 
> /bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
> /usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la libltdl/libltdl.la
> mkdir .libs
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> shared libraries

Is there a way to learn what undefined symbols are left??? (On Linux 
there is 'nm', I don't know how to do this on Cygwin.)

> Tests do not work :(. See tester2.log for more details.

This I don't understand. Libtool says it cannot find configure.ac or 
configure.in. WHY??? Why on earth should it need these files??? 
tester2.log shows the libtool command that failed. Could you check what 
happens if you just use this command on its own?

> But occ does not crash with sigsegv signal!

This is definitely a progress!!!

Are there any fixes that you introduced which are not in CVS yet?

Thanks,

Grzegorz

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hi!

> Gilles renamed files in CVS already.
OK
I am waiting for anonymous CVS to see it.

> To avoid holding your changes/patches, could I add you to developers and
> ask that you commit this kind of changes to CVS yourself in the future?
> If you agree, please send me your SourceForge id.
I`m now sure I`ll do any changes in the future.
I think, it is useful in any case so my id is:
1090814

> > /bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
> > /usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la libltdl/libltdl.la
> > mkdir .libs
> > libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> > shared libraries
>
> Is there a way to learn what undefined symbols are left??? (On Linux
> there is 'nm', I don't know how to do this on Cygwin.)
I`ll investigate.

>
> > Tests do not work :(. See tester2.log for more details.
>
> This I don't understand. Libtool says it cannot find configure.ac or
> configure.in. WHY??? Why on earth should it need these files???
> tester2.log shows the libtool command that failed. Could you check what
> happens if you just use this command on its own?
I`ll look for it after downloading the last CVS version.

>Are there any fixes that you introduced which are not in CVS yet?
No, there are not. I just renamed files.

Re: [OBORONA-SPAM] Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hi!

> > > /bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
> > > /usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la
libltdl/libltdl.la
> > > mkdir .libs
> > > libtool: link: warning: undefined symbols not allowed in
i686-pc-cygwin
> > > shared libraries
> >
> > Is there a way to learn what undefined symbols are left??? (On Linux
> > there is 'nm', I don't know how to do this on Cygwin.)
Here is the output:

Dima@home ~/opencxx.pch
$ /bin/bash ./libtool  --mode=relink g++ -g -O2 -o libocc.la -rpath
/home/Dima/
opencxx.pch/testbed/lib empty_libocc.lo opencxx/libocc_mop.la
libltdl/libltdl.la
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared libraries
ar cru .libs/libocc.a  empty_libocc.o
ranlib .libs/libocc.a
creating libocc.la
(cd .libs && rm -f libocc.la && ln -s ../libocc.la libocc.la)

Dima@home ~/opencxx.pch
$ ./libtool --help --mode=relink
libtool: invalid operation mode `relink'
Try `libtool --help' for more information.

Dima@home ~/opencxx.pch
$ ./libtool --version
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.94 2004/04/10 16:27:27)

Copyright (C) 2003  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.

Which file do I have to check?
As far as I understand, libocc.a is OK.

Dima@home ~/opencxx.pch
$ cd .libs/

Dima@home ~/opencxx.pch/.libs
$ nm libocc.a

empty_libocc.o:
00000000 b .bss
00000000 d .data
00000000 N .stab
00000000 N .stabstr
00000000 t .text


> > > Tests do not work :(. See tester2.log for more details.
> >
> > This I don't understand. Libtool says it cannot find configure.ac or
> > configure.in. WHY??? Why on earth should it need these files???
> > tester2.log shows the libtool command that failed. Could you check what
> > happens if you just use this command on its own?

I do not know why it is.

Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
$ libtool --tag=CXX --mode=compile --silent g++ -c tnested-class.2.ii -o
tnested-class.lo
libtool: Couldn't find configure.ac nor configure.in file

Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
$ libtool --version
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)

Copyright (C) 2003  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.
--------------------------------------------------------
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
--------------------------------------------------------
This is libtool-wrapper, which will hand off execution
to one of the two real versions listed above, depending
on the contents of configure.in/configure.ac.  Since the
wrapper was called from within a directory in which those
files are not found, this generic 'version' message is
displayed.

Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
$

Re: [OBORONA-SPAM] Re: [Opencxx-users] Cygwin problem

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

Hi,

Grigorenko Dmitriy wrote:
>>>>/bin/bash ./libtool --mode=link g++  -g -O2   -o libocc.la -rpath
>>>>/usr/local/lib  empty_libocc.lo opencxx/libocc_mop.la
> 
> libltdl/libltdl.la
> 
>>>>mkdir .libs
>>>>libtool: link: warning: undefined symbols not allowed in
> 
> i686-pc-cygwin
> 
>>>>shared libraries
>>>
>>>Is there a way to learn what undefined symbols are left??? (On Linux
>>>there is 'nm', I don't know how to do this on Cygwin.)
> 
> Here is the output:
> 
> Dima@home ~/opencxx.pch
> $ /bin/bash ./libtool  --mode=relink g++ -g -O2 -o libocc.la -rpath
> /home/Dima/
> opencxx.pch/testbed/lib empty_libocc.lo opencxx/libocc_mop.la
> libltdl/libltdl.la
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
> shared libraries
> ar cru .libs/libocc.a  empty_libocc.o
> ranlib .libs/libocc.a
> creating libocc.la
> (cd .libs && rm -f libocc.la && ln -s ../libocc.la libocc.la)
> 
> Dima@home ~/opencxx.pch
> $ ./libtool --help --mode=relink
> libtool: invalid operation mode `relink'
> Try `libtool --help' for more information.
> 
> Dima@home ~/opencxx.pch
> $ ./libtool --version
> ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.94 2004/04/10 16:27:27)
> 
> Copyright (C) 2003  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.
> 
> Which file do I have to check?
> As far as I understand, libocc.a is OK.

All .(l)o and .(l)a files on the linker command line.

> Dima@home ~/opencxx.pch
> $ cd .libs/
> 
> Dima@home ~/opencxx.pch/.libs
> $ nm libocc.a
> 
> empty_libocc.o:
> 00000000 b .bss
> 00000000 d .data
> 00000000 N .stab
> 00000000 N .stabstr
> 00000000 t .text
> 
> 
> 
>>>>Tests do not work :(. See tester2.log for more details.
>>>
>>>This I don't understand. Libtool says it cannot find configure.ac or
>>>configure.in. WHY??? Why on earth should it need these files???
>>>tester2.log shows the libtool command that failed. Could you check what
>>>happens if you just use this command on its own?
> 
> 
> I do not know why it is.
> 
> Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
> $ libtool --tag=CXX --mode=compile --silent g++ -c tnested-class.2.ii -o
> tnested-class.lo
> libtool: Couldn't find configure.ac nor configure.in file

Looks like a bug in cygwin. Seemingly workaround is available, see:

     http://www.cygwin.com/ml/cygwin/2002-01/msg01040.html

BR
GJ

> 
> Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
> $ libtool --version
> ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42)
> 
> Copyright (C) 2003  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.
> --------------------------------------------------------
> ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
> --------------------------------------------------------
> This is libtool-wrapper, which will hand off execution
> to one of the two real versions listed above, depending
> on the contents of configure.in/configure.ac.  Since the
> wrapper was called from within a directory in which those
> files are not found, this generic 'version' message is
> displayed.
> 
> Dima@home ~/opencxx.pch/testsuite/testsuite.dir/comp/tnested/compilation
> $

Re: [Opencxx-users] Cygwin problem

[Grigorenko D. <pos...@na...>]

Hi

> the most stable thing is rel_2_8,
> which is the next release.
OK
I`ve investigated my cvs problems
First of all, there is a problem with aux.* files. Some filenames (such are
aux, com, prn, con) have the special meaning in DOS/Win OS, so they cannot
be used for
common files. Please, rename them.
The second point is that Windows is not case sensitive. So ptree.h and
Ptree.h are the same file. (member.h and Member.h have the same problem).

The second problem is the following:
$./bootstrap
$./configure
<..>
configure: error: libgc not found; set up paths or --disable-gc

The logs of bootstrap (boot.log) and configure (cfg.log) are attached.
The full configure log which --disable-gc option is attached (cfg2.log)

You can see that in all cases the configure gives the right answer about
ltdl (as far as I understand).
I cannot show you results of tests becouse I have to make a number of
changes in the filenames.
I`ll write about 'make tests' later.

There is no makefile.in in the script folder.
http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/scripts/?only_with_tag
=rel_2_8
There is no gc/Makefile
http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/gc/?only_with_tag=rel_
2_8

Is it correct?

Re: [Opencxx-users] Cygwin problem

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

Grigorenko Dmitriy wrote:
> Hi
> 
> 
>>the most stable thing is rel_2_8,
>>which is the next release.
> 
> OK
> I`ve investigated my cvs problems
> First of all, there is a problem with aux.* files. Some filenames (such are
> aux, com, prn, con) have the special meaning in DOS/Win OS, so they cannot
> be used for
> common files. Please, rename them.
> The second point is that Windows is not case sensitive. So ptree.h and
> Ptree.h are the same file. (member.h and Member.h have the same problem).

See my other reply (sent just a minute ago).

> The second problem is the following:
> $./bootstrap
> $./configure
> <..>
> configure: error: libgc not found; set up paths or --disable-gc

This is ok. Beginning with 2.8 libgc is not a part of OpenC++, it is an 
external library. If you want to use gc, you need to install it 
system-wide or in your home. In the latter case you have guarantee, that 
compiler/linker will be able to find libgc, one way is:

./configure CPPFLAGS=-I<dir_with_gc>/include LDFLAGS=-L<dir_with_gc>/lib

Alternatively, you can switch gc off:

./configure --disable-gc

> The logs of bootstrap (boot.log) and configure (cfg.log) are attached.
> The full configure log which --disable-gc option is attached (cfg2.log)
> 
> You can see that in all cases the configure gives the right answer about
> ltdl (as far as I understand).
> I cannot show you results of tests becouse I have to make a number of
> changes in the filenames.

That would be great to bring all the fixes into CVS.

> I`ll write about 'make tests' later.
> 
> There is no makefile.in in the script folder.
> http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/scripts/?only_with_tag
> =rel_2_8

Correct. Makefile is generated by ./configure, no need to keep it in CVS.

> There is no gc/Makefile
> http://cvs.sourceforge.net/viewcvs.py/opencxx/opencxx/gc/?only_with_tag=rel_
> 2_8

gc directory should be all empty, which effectively means it does not 
exist any more. This is because libgc is no longer distributed as a part 
of OpenC++, starting from 2.8 it is an external dependency.

> 
> Is it correct?

Yes.

Best regards
Grzegorz