[kaffe] Re: [tritonus-user] Tritonus on kaffe
Matthias Pfisterer wrote: Dalibor Topic wrote: My other problem is that libtritonusalsa needs javah to run on some Alsa* inner classes. I can't seem to get the $-character properly quoted in the Makefile.am file, and I'm not even sure kaffe's javah properly supports them anyway. If the inner classes could be moved into proper classes of their own, that would let me add support for ALSA in a much easier fashion. Removing these inner classes is on the TODO list, too. I noticed that there is no real benefit from using inner classes. Data hiding has to be violated anyway. (For instance, m_lNativeHandle in AlsaPcm.HWParams has to be package visible instead of private.) So I agree to changing the inner classes. Please tell me if this is high priority. (And I think the bug in javah has to be fixed anyway.) I've fixed this now, too. You have to update the following directories: - src/lib/alsa - src/org/tritonus/lowlevel/alsa - src/org/tritonus/sampled/mixer/alsa As my system currently is only partly working, I wasn't able to check if Tritonus still runs with the changes. I was only able to compile and link. Maybe I forgot to change some method name, which will be detected at run-time. So if you get obscure problems, it may well be my fault. Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone +49-711-62 87 12 D-70176 Stuttgart GERMANY Java Sound Examples: http://www.jsresources.org/examples/ Java Sound Programmer's FAQ: http://www.jsresources.org/faq/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [tritonus-user] Tritonus on kaffe
Dalibor Topic wrote: --- Stuart Ballard [EMAIL PROTECTED] wrote: Dalibor Topic wrote: My current code fits it into kaffe's auto* tools based build as en extension library, adds a configure option for the sound backend to use, compiles the java libraries, and links the C++ libraries accordingly. Ouch, a configure option for the sound backend? Isn't that going to make life hard on distributors like Debian, who don't force their users into a single sound system? Will they need to build multiple versions of Kaffe depending on which sound backend is desired? Wouldn't some way of doing it at runtime be preferable? Currently, I've only got esd to work, so there is not much choice anyway: esd, or no sound at all. ;) there are a few reasons why I think a sound backend option makes sense: a) native sound libraries are written in C++. We shouldn't require having a C++ compiler in order to build kaffe, as that would make porting to systems like minix even harder. So there should be a convenient way to tell the configure script that we don't want to bother with it. Should be solved now: no more C++. b) In order to compile kaffe with sound support, you need libesound and esd.h. Many linux distributions don't install libesound development files by default. I wouldn't want to force people to install a few sound RPMs just because they want to use kaffe for XML processing, for example. So the default option for sound in my patch is no. c) It mirrors the current situation with AWT backends. You can only have either Xlib, Qt or no awt at all at the same time. Changing that would require a significant rewrite of kaffe's java AWT libraries, I think. That would be good to have, though, as it would in theory allow us to run those nice 3rd party AWT implementations like PureJavaAWT. d) I'm not sure if it is possible to have several different MixerProviders in tritonus simultaneously. Matthias, do you know if that works? If so, then it shouldn't be hard to add other backends, i.e. ALSA by just adding its class file name to META-INF/services/javax.sound.sampled.spi.MixerProvider It would be pointless at the moment as the native libs for ALSA don't compile on kaffe, due to some problems with kaffeh (and me not being able to tell automake to quote $ in the Makefile.am). I'll better try to post some code tonight, so you guys have something to play with. I have to write up a massive ChangeLog entry first ... Hi, both compile-time and run-time switches do make sense and should be present. To start with the run-time ones: The configuration system of Java Sound works by scanning the class paths (boot, extension, user) for configuration files like META-INF/services/javax.sound.sampled.spi.MixerProvider. This is done using the method Classloader.findResources(String). Note that it's 'Resources', no 'Resource', so multiple entries can be found. For all configuration files found, the file is read. Classes mentioned in the configuration file are instantiated with Class.forName(). All classes of one type of configuration file form an ordered list of Service Providers of the respective type. This leads to the practice of packaging (for instance) a Mixer implementation together with a configuration file naming just this Service Provider. The resulting .jar file can just be added to or removed from the class path. This is why Tritonus routinely builds 10+ jar files: one for esd, one for ALSA, one for standard audio file readers and writers, one for the GSM codec, and so on. In theory, it is possible to have any number of service providers of the same type. For mixer providers, there is an obvious restriction: It can't work if multiple mixer implementations compete for exclusive hardware access. Compile-time configuration: this is useful for the reasons stated above: not forcing too much build dependencies. There should be either an option like --with-sound-backend=esd,also,... (multiple entries should be possible) or an automatic detection of available libraries that can be linked against. Distributions could be broken in packages as it is common for sound programs with different backends: vlc vlc-alsa vlc-arts vlc-esd xmms xmms-alsa ... ... where the vlc-* packages only contain the plug-ins (Java Sound speak: 'service providers'). Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone +49-711-62 87 12 D-70176 Stuttgart GERMANY Java Sound Examples: http://www.jsresources.org/examples/ Java Sound Programmer's FAQ: http://www.jsresources.org/faq/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [tritonus-user] Tritonus on kaffe
Dalibor Topic wrote: --- Matthias Pfisterer [EMAIL PROTECTED] wrote: It is no longer necessary to build a library in ../common/. I'm now linking the (single, small) object file to any library in the other directories. This is to simplify installation. You could turn the helper functions in common.c into static __inline__ functions in common.h. Then you would not have to link anything accross directories. Ok, but doesn't that mean that there will be one object code instance per source file instead of one per library? It won't matter for esd with now only two source files. But for ALSA with 20+ source files, it may make a noticable difference. The cooked_ioctl directory contains code to read CDs using the Linux cooked ioctl interface. As it is superseeded by the cdparanoia based implementation, it is no longer maintained. I keep it as an example of how to structure simple CDDA reading on other operating systems. Yeah, I'll leave mp3 out for all the good reasons. Jorbis might be interesting, but I haven't played extensively with it yet. I think having gorbis as the default Ogg provider, and Jorbis as second choice if the ogg tools don't work would be the way to go for kaffe, when I've merged in the basic functionality. Jogg/Jorbis are pure java, so they will work even if no additional native libraries are installed. There is already a Java Sound service provider (think of it as some sort of a wrapper layer) for Jorbis. It has a minor problem with thread safety, but I will fix this and include this, too. The reason for dealing with native stuff for ogg vorbis at all is that Jorbis only covers the decoder. For using an encoder, the C libraries are the only choice. So I think it's rather the Jorbis based service provider that should be the default and gsorbis the option. At least this seems appropriate when detecting the build configuration. If both are present, it can still be debated which implementation to choose at run-time (for decoding). The run-time configuration system of Java Sound is flexible enough to separate between decoding and encoding. (More details later) Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone +49-711-62 87 12 D-70176 Stuttgart GERMANY Java Sound Examples: http://www.jsresources.org/examples/ Java Sound Programmer's FAQ: http://www.jsresources.org/faq/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [tritonus-user] Tritonus on kaffe
Dalibor Topic wrote: Hallo Matthias, --- Matthias Pfisterer [EMAIL PROTECTED] wrote: My fix for this is to use libtool from current CVS and upgrade out build scripts to latest auto* tools. There are some issues in going that way, mainly increasing the bar for build system developers, and having to fix all the bugs in the build scripts exposed by the upgrade. Of course, if the libraries could be switched to plain old C, that would make my life much easier, I hope. What is the HandleFieldHandler class used for? I've switched back to C in the directories src/lib/esd, src/lib/alsa, src/lib/common and src/lib/cdparanoia. This should do it for the moment. Note that the inner class issue with the ALSA classes is still pending. It is no longer necessary to build a library in ../common/. I'm now linking the (single, small) object file to any library in the other directories. This is to simplify installation. The cooked_ioctl directory contains code to read CDs using the Linux cooked ioctl interface. As it is superseeded by the cdparanoia based implementation, it is no longer maintained. I keep it as an example of how to structure simple CDDA reading on other operating systems. gsvorbis contains an incomplete interface to the ogg vorbis encoder. It is not assumed to work. lame contains, well, an interface to LAME, an mp3 encoder. I suggest to leave it out. All open source implementations of mp3 encoders are illegal, as well as all open source implementations of mp3 decoders. We keep it because it is requested quite often and no open source developer or entity was sued so far. But I think it's best to not proliferate it further. ogg vorbis is a viable alternative gaining market share rapidly, and of better quality. The only drawback is that it is not yet integreted into Java Sound. And I've deleted the saint directory from the cvs, since it was all legacy. Ah, the HandleFieldHandler: all low level classes need to keep some handle to some native facility. For esd, it is the file descriptor of the socket connection to the esd server. For ALSA, it is some pointer of type snd_pcm_t* or snd_seq_t*. These handles are stored in instance variables of the JNI classes. Looking into the Java code, you will see members 'private long m_lNativeHandle' or similar. These are used by the native code to store the handles. They are long in Java, because in the future, the native word size or the size of pointers will become 64 bit. It is the code to access these Java fields from the native code that I have generalized in the former C++ class HandleFieldHandler. Now -- after the change to C -- there is a header file src/lib/common/HandleFieldHandler.h that contains C macros to do almost the same. MidiShare is a low-level MIDI API. In theory, it is quite portable. It evolved on Macintosh and has also versions for Windows and Linux. I was not very happy with it. The windows version only worked for 16bit Windows (including Win95, but not WinNT, Win2000, etc.). This is an old state, perhaps newer versions have evolved. But the main reason I didn't deal with it is that it is not comparative to ALSA's MIDI and sequencing facilities. Plus, I think, some personal taste on API design. You can get more information on MidiShare at http://www.grame.fr/MidiShare/ their web site mentions new versions for Win 200 OS X , so it might be worth a try. I'll see if I can get it to work. The Person that implemented the MidiShare support in Tritonus was Stephane Letz. I haven't heard from him for a while. However, he is still subscribed to the tritonus-devel list (note that I moved the discussion there). You can also contact him directly with letz [at] grame.fr Matthias -- Matthias Pfisterer mailto:[EMAIL PROTECTED] Reuchlinstrasse 28 phone +49-711-62 87 12 D-70176 Stuttgart GERMANY Java Sound Examples: http://www.jsresources.org/examples/ Java Sound Programmer's FAQ: http://www.jsresources.org/faq/ Tritonus, the open source implementation of the Java Sound API: http://www.tritonus.org/ -- ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [tritonus-user] Tritonus on kaffe
--- Matthias Pfisterer [EMAIL PROTECTED] wrote: Dalibor Topic wrote: Hallo Matthias, --- Matthias Pfisterer [EMAIL PROTECTED] wrote: My fix for this is to use libtool from current CVS and upgrade out build scripts to latest auto* tools. There are some issues in going that way, mainly increasing the bar for build system developers, and having to fix all the bugs in the build scripts exposed by the upgrade. Of course, if the libraries could be switched to plain old C, that would make my life much easier, I hope. What is the HandleFieldHandler class used for? I've switched back to C in the directories src/lib/esd, src/lib/alsa, src/lib/common and src/lib/cdparanoia. This should do it for the moment. Note that the inner class issue with the ALSA classes is still pending. Great! I'll look at kaffeh in order to see where the bug is, and I hope to be able to post a new tritonus-merge-patch by end of the week. It is no longer necessary to build a library in ../common/. I'm now linking the (single, small) object file to any library in the other directories. This is to simplify installation. You could turn the helper functions in common.c into static __inline__ functions in common.h. Then you would not have to link anything accross directories. The cooked_ioctl directory contains code to read CDs using the Linux cooked ioctl interface. As it is superseeded by the cdparanoia based implementation, it is no longer maintained. I keep it as an example of how to structure simple CDDA reading on other operating systems. I'll leave it out for kaffe then. gsvorbis contains an incomplete interface to the ogg vorbis encoder. It is not assumed to work. I'll leave out the gvorbis interface for now, as well. I'm more interested into getting the basic javax.sound implementation to work, and then taking the next step, and eventually merge in additional providers from tritonus.org. lame contains, well, an interface to LAME, an mp3 encoder. I suggest to leave it out. All open source implementations of mp3 encoders are illegal, as well as all open source implementations of mp3 decoders. We keep it because it is requested quite often and no open source developer or entity was sued so far. But I think it's best to not proliferate it further. ogg vorbis is a viable alternative gaining market share rapidly, and of better quality. The only drawback is that it is not yet integreted into Java Sound. Yeah, I'll leave mp3 out for all the good reasons. Jorbis might be interesting, but I haven't played extensively with it yet. I think having gorbis as the default Ogg provider, and Jorbis as second choice if the ogg tools don't work would be the way to go for kaffe, when I've merged in the basic functionality. thanks for the quick replies and great work so far, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [tritonus-user] Tritonus on kaffe
--- Patrick Tullmann [EMAIL PROTECTED] wrote: Hey Dalibor, I didn't realize Tritonus provided part of JDK1.4 compatibility. I see why you're trying to get it into the tree. Any chance there is a simple hacky fix to kaffe's libtool to get it to link c++ correctly? Maybe, I think I saw some patches in the libtool mailing list archives from some Mandrake Linux guys. You can try to merge it with what we have (1.4.3), if you wish. On the other hand, if that means supporting our own version of libtool, I'd rather not go there, but just take stuff from the upstream CVS, and remerge when some significant bug is fixed. Since I think we're going to get bitten whatever we do, I think we should probably be doing more to reduce the need for developers to re-build Makefiles and configure. For example, the change proposed a while ago to remove the list of java sources from the Makefiles would be a really good step. I can work on that a bit unless someone else already has it working... I agree. Just because someone would like to test a class or two from Classpath, they should not have to go through the whole 'edit libraries/javalib/Makefile.am, run developers/autogen.sh, reconfigure, compile, and wait for a while until it's finished' procedure. I find that quite time consuming when I'm merging in new classes, given that each (configure; compile; test) cycle takes about 10 minutes on my current development machine. So please go ahead, and make it better. That frustration was one of the reasons why I proposed ant for the job a few months ago. I've changed my mind since, as suporting ant would mean that we need to pull in javax.xml into Klasses.jar.bootstrap, and all other classes for XML support. That would turn Klasses.jar.bootstrap into the big, cvs-unfriendly thing that Klasses.jar was. I wouldn't want that. Ant has one great feature, though: given a path of directories in the build file (equivalent to the makefile in make-terms) it finds all *.java files and compiles them, without the developer having to spend time maintaining a current list of classes. So if you plan to work on it, some code that does the equivalent of: find $PACKAGE-BATCH -name *.java class-files $JAVAC @class-files would be great. the is there because as the class library grows, enumerating it is going to exceed the maximum command line length on most systems. It does so on IRIX already, which is one of the reasons why I have split Klasses_jar_SRCS in libraries/javalib/Makefile.am . The other is amount of memory required to build kaffe. It's not very funny to watch the garbage collector crawl through the swap space for a day. ;) My idea would be to have package lists in a separate file, say classlib.packagelist. The format could be like that of bootstrap.classlist, with a small addition to allow to specify multiple batches of packages. Having it separately, means being independant of auto* tools for class library issues. What do you think? I imagine doing something similar for the extensions library is a bit too much (since libtool has to do linking of the generated objects). Any other ideas? Anyone else find themselves running developers/autogen too much? I think I'll be migrating the java bits of the extension library into the main library directory eventually. Sometime next year, at the moment I'm busy with javax.sound, and if we get that in, I'll be busy fixing the damage the transition to latest auto* tools would have done ;) I don't know about the native libraries, but I assume that the situation is similar. I think it would harder to flexibilize the build process for native libraries, because of libtool. Maybe that would be a nice addition to configure.in: regenerate Makefile.in Makefile when a Makefile.am file is younger than its heirs. Just-in-time configuration ;) best regards, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [tritonus-user] Tritonus on kaffe
Dalibor Topic wrote: My current code fits it into kaffe's auto* tools based build as en extension library, adds a configure option for the sound backend to use, compiles the java libraries, and links the C++ libraries accordingly. Ouch, a configure option for the sound backend? Isn't that going to make life hard on distributors like Debian, who don't force their users into a single sound system? Will they need to build multiple versions of Kaffe depending on which sound backend is desired? Wouldn't some way of doing it at runtime be preferable? Stuart. -- Stuart Ballard, Programmer NetReach - Internet Solutions (215) 283-2300, ext. 126 http://www.netreach.com/ ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [tritonus-user] Tritonus on kaffe
--- Stuart Ballard [EMAIL PROTECTED] wrote: Dalibor Topic wrote: My current code fits it into kaffe's auto* tools based build as en extension library, adds a configure option for the sound backend to use, compiles the java libraries, and links the C++ libraries accordingly. Ouch, a configure option for the sound backend? Isn't that going to make life hard on distributors like Debian, who don't force their users into a single sound system? Will they need to build multiple versions of Kaffe depending on which sound backend is desired? Wouldn't some way of doing it at runtime be preferable? Currently, I've only got esd to work, so there is not much choice anyway: esd, or no sound at all. ;) there are a few reasons why I think a sound backend option makes sense: a) native sound libraries are written in C++. We shouldn't require having a C++ compiler in order to build kaffe, as that would make porting to systems like minix even harder. So there should be a convenient way to tell the configure script that we don't want to bother with it. b) In order to compile kaffe with sound support, you need libesound and esd.h. Many linux distributions don't install libesound development files by default. I wouldn't want to force people to install a few sound RPMs just because they want to use kaffe for XML processing, for example. So the default option for sound in my patch is no. c) It mirrors the current situation with AWT backends. You can only have either Xlib, Qt or no awt at all at the same time. Changing that would require a significant rewrite of kaffe's java AWT libraries, I think. That would be good to have, though, as it would in theory allow us to run those nice 3rd party AWT implementations like PureJavaAWT. d) I'm not sure if it is possible to have several different MixerProviders in tritonus simultaneously. Matthias, do you know if that works? If so, then it shouldn't be hard to add other backends, i.e. ALSA by just adding its class file name to META-INF/services/javax.sound.sampled.spi.MixerProvider It would be pointless at the moment as the native libs for ALSA don't compile on kaffe, due to some problems with kaffeh (and me not being able to tell automake to quote $ in the Makefile.am). I'll better try to post some code tonight, so you guys have something to play with. I have to write up a massive ChangeLog entry first ... best regards, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: [tritonus-user] Tritonus on kaffe
--- Dalibor Topic [EMAIL PROTECTED] wrote: What I have at the moment, is that I've added tritonus to kaffe's build system, all the tritonus java libs compile, the C++ libraries (except ALSA, because of the inner class problems) compile and link, SampleAudioPlayer starts but can't link libtritonusesd because of cerr not found, i.e. the libtool-over-shared-C++ libs problem mentioned above. I've got sound output working[1] on kaffe with esd now, by linking tritonus libraries manually using g++. The developers on the libtool mailing list were kind enough to point out that the current CVS version of libtool should be able to generate shared C++ libaries out of the box. As the CVS libtool requires new versions of autoconf friends, I'm trying to get kaffe's build system to work with autoconf 2.56 automake 1.7.1 as well as libtool from CVS. If all goes well, I hope to have something to check in by the end of the week. best regards, dalibor topic [1] I've tested SimpleAudioPlayer with a wav file from Atari Teenage Riot's song Revolution Action [2]. jorbis doesn't work yet. [2] The song is supposed to be mostly distorted noise, really, so I can't tell much about the perceived output quality. It sounded truthful to the original to me on my old cyrix p200 box. Your mileage might vary depending on your processor speed, the engine used etc. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [tritonus-user] Tritonus on kaffe
Dalibor wrote:
I'm trying to get kaffe's build system to work with autoconf 2.56
automake 1.7.1 as well as libtool from CVS. If all goes well, I hope
to have something to check in by the end of the week.
I'd be wary of upgrading the autoconf and configure requirements for
Kaffe, simply because you'll reduce the number of folks willing and
able to deal with rebuilding Kaffe's build infrastructure even further.
Also, its not clear to me why Kaffe's build system needs to be
upgraded to build third-party libraries. Shouldn't this library be
buildable/linkable without being part of Kaffe's build system?
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
${HOME} is where the .emacs is.
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [tritonus-user] Tritonus on kaffe
Hi Pat, --- Patrick Tullmann [EMAIL PROTECTED] wrote: Dalibor wrote: I'm trying to get kaffe's build system to work with autoconf 2.56 automake 1.7.1 as well as libtool from CVS. If all goes well, I hope to have something to check in by the end of the week. I'd be wary of upgrading the autoconf and configure requirements for Kaffe, simply because you'll reduce the number of folks willing and able to deal with rebuilding Kaffe's build infrastructure even further. You're right, and I have been thinking about this. I don't want to increase the requirements for participating. Upgrading to latest auto* tools could make the life harder for projects syncing with kaffe's CVS like JanosVM, maybe even pushing them to switch over to latest auto* tools, with all the work that implies. I'd rather delay merging in tritonus before I make life harder for people who've been working hard to improve kaffe or new developers. I'll be providing the tritonus patch as a separate download for now, until I get feedback from people whether it works at all. I'll post the URL in a separate mail, when I get it cleaned up and tested on a few systems. We could wait until the *BSDs, Linux distributions and the rest of the world agree to ship automake 1.7 and autoconf 2.56 and then upgrade our build scripts because they break with latest versions. Or we could do it now, and live with an even smaller set of build system developers. I don't think that either option is great. Also, its not clear to me why Kaffe's build system needs to be upgraded to build third-party libraries. Shouldn't this library be buildable/linkable without being part of Kaffe's build system? In theory it is buildable. In practice it is quite hard to get it to work. The INSTALL file for tritonus says compiling from CVS is complicated. It involves running autoconf, ant, and then running make a few times and ignoring the errors ... so it's quite messy in my opinion, and doesn't fit in well in the build process kaffe is already using. Tritonus doesn't provide *.am files, or a configure.in file in the CVS, so hacking its build scripts is complicated. My current code fits it into kaffe's auto* tools based build as en extension library, adds a configure option for the sound backend to use, compiles the java libraries, and links the C++ libraries accordingly. Merging and tracking this external library in kaffe would give kaffe a cross-platform, esound based javax.sound implementation, and allow more people interested in writing java sound applications to do so on a free platform, just like merging in GNU JAXP should have made the life easier for people using kaffe to process XML. Both APIs are parts of java 1.4. Tritonus makes things more complicated, as it exposes a bug in libtool 1.4.3. Tritonus is written in C++, and the latest stable release of libtool (1.4.3, used in kaffe) has serious problems when linking shared libraries written in C++. It uses gcc instead of g++ for the linking step, so it doesn't link with libstdc++ and friends. That in turn prevents the shared library from loading, as it can't resolve symbols like cerr anymore. This bug is fixed in libtool CVS. Libtool from CVS depends on a fairly current autoconf, and so on. cheers, dalibor topic __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: [tritonus-user] Tritonus on kaffe
Hey Dalibor, I didn't realize Tritonus provided part of JDK1.4 compatibility. I see why you're trying to get it into the tree. Any chance there is a simple hacky fix to kaffe's libtool to get it to link c++ correctly? We could wait until the *BSDs, Linux distributions and the rest of the world agree to ship automake 1.7 and autoconf 2.56 and then upgrade our build scripts because they break with latest versions. Or we could do it now, and live with an even smaller set of build system developers. I don't think that either option is great. Heh, not great: that's the story of autoconf Since I think we're going to get bitten whatever we do, I think we should probably be doing more to reduce the need for developers to re-build Makefiles and configure. For example, the change proposed a while ago to remove the list of java sources from the Makefiles would be a really good step. I can work on that a bit unless someone else already has it working... I imagine doing something similar for the extensions library is a bit too much (since libtool has to do linking of the generated objects). Any other ideas? Anyone else find themselves running developers/autogen too much? -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Don't hate yourself in the morning -- sleep until noon! ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
