Jython dependencies...

Jython dependencies...

[Alexandre Petit-Bianco]

I'm experimenting with a Makefile.am file for jython. I haven't solved
the `make install' issue yet. But I have questions regarding this
section:

  # Several libraries define what readline needs (tgetnum for instance
  # is defined in libcurses, libncurses and libtermcap.) The one we need
  # should be found at configure time. FIXME.
  TEST_LDADD_LIBS = -lreadline -lcurses
  # There has to be a better way to specify these extra
  # libraries. FIXME.
  TEST_DEPS = ../jakarta-servletapi/lib-javax-servlet.la \
              ../jakarta-oro/lib-org-apache-oro.la \
              ../gnu.readline/lib-org-gnu-readline.la
  
  test_SimpleEmbedded_DEPENDENCIES = $(TEST_DEP)
  test_SimpleEmbedded_SOURCES = upstream/src/Demo/embed/SimpleEmbedded.java
  test_SimpleEmbedded_LDFLAGS = --main=SimpleEmbedded
  test_SimpleEmbedded_LDADD = -L. -l-org-jython $(TEST_DEPS) $(TEST_LDADD_LIBS)
  
  First, I guess I should hack configure.in to check for the curses
  libraries (and others) availability and let it replace macros in
  TEST_LDADD_LIBS. We need to check for readline too, in order to figure
  how we build the gnu.readline. I haven't done that yet.
  
Second, is this the right way to express libraries dependencies on the
two jython test examples?

./A

Re: Jython dependencies...

[Anthony Green]

Alex wrote:
> Second, is this the right way to express libraries dependencies on the
> two jython test examples?

I'm probably wrong, but I seem to recall not being able to use macros in
defining *_DEPENDENCIES.  Try calling them out explicitly.

AG

Re: Jython dependencies...

[Alexandre Petit-Bianco]

Anthony Green writes:

> I'm probably wrong, but I seem to recall not being able to use
> macros in defining *_DEPENDENCIES.  Try calling them out explicitly.

OK.

./A

Re: Jython dependencies...

[Tom Tromey]

>>>>> "Alex" == Alexandre Petit-Bianco <apbianco@cygnus.com> writes:

Alex>   First, I guess I should hack configure.in to check for the curses
Alex>   libraries (and others) availability and let it replace macros in
Alex>   TEST_LDADD_LIBS. We need to check for readline too, in order to figure
Alex>   how we build the gnu.readline. I haven't done that yet.

There may be code in gdb/configure.in that will help.

Alex> Second, is this the right way to express libraries dependencies
Alex> on the two jython test examples?

Seems like it should work.  Offhand I don't know if what AG sees is a
bug or is intentional.

Tom

Re: Jython dependencies...

[Alexandre Petit-Bianco]

Tom Tromey writes:

> There may be code in gdb/configure.in that will help.

I looked at libgcj's configure.in and gdb's too but not closely enough
I guess.

Thanks.

./A

Re: Jython dependencies...

[Anthony Green]

Alex wrote:
>   TEST_DEPS = ../jakarta-servletapi/lib-javax-servlet.la \
>               ../jakarta-oro/lib-org-apache-oro.la \
>               ../gnu.readline/lib-org-gnu-readline.la
>
>   test_SimpleEmbedded_DEPENDENCIES = $(TEST_DEP)
>   test_SimpleEmbedded_SOURCES = upstream/src/Demo/embed/SimpleEmbedded.java
>   test_SimpleEmbedded_LDFLAGS = --main=SimpleEmbedded
>   test_SimpleEmbedded_LDADD = -L. -l-org-jython $(TEST_DEPS)
$(TEST_LDADD_LIBS)

> Second, is this the right way to express libraries dependencies on the
> two jython test examples?

Hmm... if you link lib-org-jython.la with -l-javax-servlet
and -l-org-apache-oro and -l-org-gnu-readline, then there should be no need to
put these in your dependencies list.  Does lib-org-jython.la really refer to
classes in these libraries?  If so you'll need to modify
lib_org_jython_la_LIBADD and then have lib-org-jython.la in your dependencies
for the test programs.  Things break pretty badly otherwise.

AG

Re: Jython dependencies...

[Alexandre Petit-Bianco]

Anthony Green writes:

> Hmm... if you link lib-org-jython.la with -l-javax-servlet and
> -l-org-apache-oro and -l-org-gnu-readline, then there should be no
> need to put these in your dependencies list.

Noted, thanks.

>  Does lib-org-jython.la really refer to classes in these libraries?
> If so you'll need to modify lib_org_jython_la_LIBADD and then have
> lib-org-jython.la in your dependencies for the test programs.
> Things break pretty badly otherwise.

I have to check. I think I haven't exercised this part yet.

./A

Re: Jython dependencies...

[Alexandre Petit-Bianco]

Anthony Green writes:

> Hmm... if you link lib-org-jython.la with -l-javax-servlet and
> -l-org-apache-oro and -l-org-gnu-readline, then there should be no
> need to put these in your dependencies list.  Does lib-org-jython.la
> really refer to classes in these libraries?  If so you'll need to
> modify lib_org_jython_la_LIBADD and then have lib-org-jython.la in
> your dependencies for the test programs.  Things break pretty badly
> otherwise.

That's what I did. I'm about to check in the bits to let jython
build. But there's much work to do (see jython/TODO.)

One mystery is that this morning, my build yields to a test_jython
which core all the time. I just rebuilt with -static (and a re-build
of bhoem-gc sans -O) and I got the following stack trace:

xception in thread "main" java.lang.NullPointerException
   at 0x080f8044: _Jv_ThrowSignal (/home/apbianco/src/egcs-devel/libjava/prims.cc:119)
   at 0x080f8067: catch_segv(int) (/home/apbianco/src/egcs-devel/libjava/prims.cc:128)
   at 0xbfffeb54: ?? (??:0)
   at 0x0807000a: ?? (/usr/src/bs/BUILD/glibc-2.2.1/csu/init.c:0)
   at 0x080da494: ?? (/usr/src/bs/BUILD/glibc-2.2.1/csu/init.c:0)
   at 0x080da3ca: ?? (/usr/src/bs/BUILD/glibc-2.2.1/csu/init.c:0)
   at 0x0808992f: ?? (/usr/src/bs/BUILD/glibc-2.2.1/csu/init.c:0)
   at 0x08089597: ?? (/usr/src/bs/BUILD/glibc-2.2.1/csu/init.c:0)
   at 0x08089262: ?? (/usr/src/bs/BUILD/glibc-2.2.1/csu/init.c:0)
   at 0x080482d8: ?? (/usr/src/bs/BUILD/glibc-2.2.1/csu/init.c:0)
   at 0x0817fccb: gnu.gcj.runtime.FirstThread.call_main() (/home/apbianco/src/egcs-devel/libjava/gnu/gcj/runtime/natFirstThread.cc:47)
   at 0x08154028: gnu.gcj.runtime.FirstThread.run() (/home/apbianco/src/egcs-devel/libjava/gnu/gcj/runtime/FirstThread.java:55)
   at 0x081163ae: _Jv_ThreadRun(java.lang.Thread) (/home/apbianco/src/egcs-devel/libjava/java/lang/natThread.cc:285)
   at 0x080f967a: _Jv_RunMain(java.lang.Class, byte const, int, byte const, boolean) (/home/apbianco/src/egcs-devel/libjava/prims.cc:1025)
   at 0x080f979f: JvRunMain (/home/apbianco/src/egcs-devel/libjava/prims.cc:1035)
   at 0x0804822d: ?? (/usr/src/bs/BUILD/glibc-2.2.1/csu/init.c:0)
   at 0x081c69ba: __libc_start_main (/usr/src/bs/BUILD/glibc-2.2.1/csu/../sysdeps/generic/libc-start.c:129)
   at 0x08048101: _start (??:0)

Strange. test_SimpleEmbeddd works thoug. When I get this fixed, I'll
work on the make check.

./A

Re: Jython dependencies...

[Tom Tromey]

>>>>> "Alex" == Alexandre Petit-Bianco <apbianco@cygnus.com> writes:

Alex> One mystery is that this morning, my build yields to a test_jython
Alex> which core all the time. I just rebuilt with -static (and a re-build
Alex> of bhoem-gc sans -O) and I got the following stack trace:

This must be specific to the particular program.
With yesterday's 3.1 tree, a static hello-world type program works
fine.  (I was surprised by that.)

Tom

Re: Jython dependencies...

[Alexandre Petit-Bianco]

Tom Tromey writes:

> This must be specific to the particular program.  With yesterday's
> 3.1 tree, a static hello-world type program works fine.  (I was
> surprised by that.)

Well, I linked statically so I could debug because I never managed to
put my hands on a gdb to would let me debug dynamically linked Java
apps.

Knowing that the GC had a problem with -O2, I rebuilt it appropriately
and started to debug to eventually get the same error the trace
shows. Now the interesting thing is that before rebuilding the GC,
jython would simply say something like `Aborted' but now the
statically or dynamically linked version are printing the trace.

I'm just going to try to rebuild the toolchain without any
optimization, and we'll see. I tried to back Bryce's static ctor
patch, but just going by the message he posted, I get sources that
aren't building -- note that the upgrade after which jython would
crash included that mod (and many others, of course.)

./A