This is a crude example of what we could have, but it's what I've got so far:
%post -n %{libname}-gtk2 if ![ -e `gcj-dbtool -p` ]; then dirname `gcj-dbtool -p` | xargs mkdir -p; gcj-dbtool -n `gcj-dbtool -p`; fi
if [ -n "`find %{_libdir}/%{name}/mappings -name *.db`" ]; then gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name *.db` `gcj-dbtool -p` fi
%postun %{libname}-gtk2 if [ -n "`find %{_libdir}/%{name}/mappings -name *.db`" ]; then gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name *.db` `gcj-dbtool -p` fi
I'm not even sure if what I have will work. I'd just like to start the discussion about how best to do it. Anthony Green has raised valid concerns about multilib systems.
Andrew
"Andrew" == Andrew Overholt overholt@redhat.com writes:
Andrew> This is a crude example of what we could have, but it's what Andrew> I've got so far:
Looks ok overall. I would probably put the result of `gcj-dbtool -p` into a shell variable.
Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name *.db`" ]; then Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name *.db` `gcj-dbtool -p` Andrew> fi
Is %{name} the name of the current RPM? If so then I think this is incorrect. We need to merge everything into the master .db.
Andrew> I'm not even sure if what I have will work. I'd just like to start the Andrew> discussion about how best to do it.
Can we get this in somewhere as an RPM macro? And, if so, where? jpackage-utils? java-gcj-compat?
Andrew> Anthony Green has raised valid concerns Andrew> about multilib systems.
I looked at the current gcc4.spec a little. It seems to me that we will have to just put the host architecture name into the path to the .db file. Assuming that would work, I don't really know about RPM multilibs.
I CC'd Jakub for advice. Jakub, what should we do to make the built-in .db file work with multilibs? I will implement whatever it is we need.
Tom
* Tom Tromey tromey@redhat.com [2005-03-22 13:55]:
Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name *.db`" ]; then Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name *.db` `gcj-dbtool -p` Andrew> fi
Is %{name} the name of the current RPM? If so then I think this is incorrect. We need to merge everything into the master .db.
We're merging into the master .db but until we sort out where to put the other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings.
Andrew
On Tue, 2005-03-22 at 13:58 -0500, Andrew Overholt wrote:
- Tom Tromey tromey@redhat.com [2005-03-22 13:55]:
Andrew> if [ -n "`find %{_libdir}/%{name}/mappings -name *.db`" ]; then Andrew> gcj-dbtool -m `gcj-dbtool -p` `find %{_libdir}/%{name}/mappings -name *.db` `gcj-dbtool -p` Andrew> fi
Is %{name} the name of the current RPM? If so then I think this is incorrect. We need to merge everything into the master .db.
We're merging into the master .db but until we sort out where to put the other .dbs, I'm keeping the eclipse ones in /usr/lib/eclipse/mappings.
Other than Anthony Green's response, there's not much opinion on that yet it seems. Maybe asking the question was premature; it's something I'd like to figure out sooner rather than later, though.
The only other thing was the `find %{_libdir}/%{name}/mappings -name *.db` potentially producing a list of db's that is to big to fit in the argument buffer, and that may make an incorrect merge.
What are the advantages of an rpmacro over just placing a merge shell script in /usr/bin?
Regards
Phil
"Phil" == Phil Muldoon pmuldoon@redhat.com writes:
Phil> What are the advantages of an rpmacro over just placing a merge shell Phil> script in /usr/bin?
Just that it doesn't show up in the user's $PATH. I don't know if that is a plus or a minus, honestly. Wherever it ends up, it needs a sensible name.
Tom
On Tue, Mar 22, 2005 at 11:48:19AM -0700, Tom Tromey wrote:
Andrew> Anthony Green has raised valid concerns Andrew> about multilib systems.
I looked at the current gcc4.spec a little. It seems to me that we will have to just put the host architecture name into the path to the .db file. Assuming that would work, I don't really know about RPM multilibs.
I CC'd Jakub for advice. Jakub, what should we do to make the built-in .db file work with multilibs? I will implement whatever it is we need.
Well, first you want to decide whether you want one master .db file or one .db file per architecture.
One master .db file might be a tiny bit slower (since the .db file will be bigger), but might be easier for users (e.g. gcj-dbtool -p would be usable). You just need to pick up some magic values for the architectures (say for ELF architectures you can e.g. use the EM_* constants ored with ELFCLASS{32,64} shifted up or something), add code that at configure or compile time stores the current arch magic number into libgcj.so (or wherever the code that will parse the .db file lives) and code into gcj-dbtool to compute the magic value for a given shared library.
With per-arch .db you could e.g. store the file into /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be gcc $CFLAGS -print-multi-os-directory (well, even better the path would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with gcj-dbtool -p <arch>.
The first approach is what e.g. ldconfig/ld.so use.
Jakub
On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote:
With per-arch .db you could e.g. store the file into /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be gcc $CFLAGS -print-multi-os-directory (well, even better the path would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with gcj-dbtool -p <arch>.
I'm not sure I understand this second part.
What's wrong with...
/usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db
?
"gcj-dbtool -p <arch>" sounds hard to implement.
AG
On Tue, Mar 22, 2005 at 11:39:14AM -0800, Anthony Green wrote:
On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote:
With per-arch .db you could e.g. store the file into /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be gcc $CFLAGS -print-multi-os-directory (well, even better the path would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with gcj-dbtool -p <arch>.
I'm not sure I understand this second part.
What's wrong with...
/usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db
?
"gcj-dbtool -p <arch>" sounds hard to implement.
You mean that gcj-dbtool -p would print /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db and you'd need to pass that through shell after making sure $CC and $CFLAGS are properly defined? Then you'd put the burden on rpm packagers, because in rpm %post $RPM_OPT_FLAGS certainly aren't set (and, you shouldn't require gcc to be installed just to install Java packages).
Reminds me, gcj-dbtool should be probably moved from gcc-java subpackage to libgcj now that it is used not only during compile time.
Jakub
Jakub Jelinek writes:
On Tue, Mar 22, 2005 at 11:39:14AM -0800, Anthony Green wrote:
On Tue, 2005-03-22 at 14:20 -0500, Jakub Jelinek wrote:
With per-arch .db you could e.g. store the file into /usr/lib/$LIB/gcj-%{version}/classmap.db where $LIB would be gcc $CFLAGS -print-multi-os-directory (well, even better the path would be canonicalized), compile `gcc $CFLAGS -print-multi-os-directory` string into ilbgcj.so and get rid of gcj-dbtool -p or replace it with gcj-dbtool -p <arch>.
I'm not sure I understand this second part.
What's wrong with...
/usr/lib/`$CC $CFLAGS -print-multi-os-directory`/classmap.db
?
"gcj-dbtool -p <arch>" sounds hard to implement.
You mean that gcj-dbtool -p would print /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db and you'd need to pass that through shell after making sure $CC and $CFLAGS are properly defined?
gcj-dbtool is a target program, part of libgcj. So, on a multi-arch system, would there not be two gcj-dbtools, linked against different libgcjs? And, each one would print its *own* directory.
Andrew.
On Tue, Mar 22, 2005 at 07:58:53PM +0000, Andrew Haley wrote:
You mean that gcj-dbtool -p would print /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db and you'd need to pass that through shell after making sure $CC and $CFLAGS are properly defined?
gcj-dbtool is a target program, part of libgcj. So, on a multi-arch system, would there not be two gcj-dbtools, linked against different libgcjs? And, each one would print its *own* directory.
On multi-arch systems, there is usually just one set of binaries and one or two sets of libraries. If you want 2 gcj-dbtool programs, that's of course possible, but you need to decide where to install them (e.g. /usr/libexec/gcj/$LIB/gcj-dbtool ), but then all the programs that want to use gcj-dbtool need to figure out which one they want to call. For %post this location wouldn't be that hard, rpm %post would just call /usr/libexec/gcj/%{_lib}/gcj-dbtool -p ... But, will you require all Makefiles that deal with gcj-dbtool to call /usr/libexec/gcj/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-dbtool ?
Certainly, one master .db file, although it will need some work inside gcj-dbtool and libgcj.so, will make things far easier for the users and developers.
Jakub
Jakub Jelinek writes:
Certainly, one master .db file, although it will need some work inside gcj-dbtool and libgcj.so, will make things far easier for the users and developers.
That's impossible.
The .db is a mapping from bytecode to shared objects, and there is no guarantee that if a class exists in lib/foo.so it will also exist in lib64/foo.so. However, that class might well exist in lib64/bar.so.
Andrew.
On Tue, Mar 22, 2005 at 08:11:10PM +0000, Andrew Haley wrote:
Jakub Jelinek writes:
Certainly, one master .db file, although it will need some work inside gcj-dbtool and libgcj.so, will make things far easier for the users and developers.
That's impossible.
The .db is a mapping from bytecode to shared objects, and there is no guarantee that if a class exists in lib/foo.so it will also exist in lib64/foo.so. However, that class might well exist in lib64/bar.so.
Why impossible? If can be a mapping from <bytecode, arch> pair to shared objects...
Jakub
Jakub Jelinek writes:
On Tue, Mar 22, 2005 at 08:11:10PM +0000, Andrew Haley wrote:
Jakub Jelinek writes:
Certainly, one master .db file, although it will need some work inside gcj-dbtool and libgcj.so, will make things far easier for the users and developers.
That's impossible.
The .db is a mapping from bytecode to shared objects, and there is no guarantee that if a class exists in lib/foo.so it will also exist in lib64/foo.so. However, that class might well exist in lib64/bar.so.
Why impossible? If can be a mapping from <bytecode, arch> pair to shared objects...
Oh, what a horrible idea. Yes, that would work, I suppose. It doesn't scale well, though.
I would have thought it easier just to give the db an appropriate name for the arch. We don't use fat libraries, so why create fat databases? The reasoning is exactly the same.
Andrew.
"Jakub" == Jakub Jelinek jakub@redhat.com writes:
Jakub> On multi-arch systems, there is usually just one set of binaries and one Jakub> or two sets of libraries.
Programs like 'gcj-dbtool' and 'gij' are linked against a specific libgcj.so. If there is only one set of binaries, then it seems like we don't need to bother with multilib at all, since it will only ever be possible to use one particular libgcj.so -- the one 'gij' is linked to. At least, that is true in the common case... e.g., eclipse, which in the end invokes 'gij' at startup.
Or am I missing some magic that lets us pick libraries at runtime? I don't know how this could work, but I'm ready to be enlightened :-)
Tom
On Wed, Mar 23, 2005 at 05:33:13PM -0700, Tom Tromey wrote:
Programs like 'gcj-dbtool' and 'gij' are linked against a specific libgcj.so. If there is only one set of binaries, then it seems like we don't need to bother with multilib at all, since it will only ever be possible to use one particular libgcj.so -- the one 'gij' is linked to. At least, that is true in the common case... e.g., eclipse, which in the end invokes 'gij' at startup.
Or am I missing some magic that lets us pick libraries at runtime? I don't know how this could work, but I'm ready to be enlightened :-)
What prevents other programs to use libgcj.so (or now that there is libgij.so also libgij.so)? And when they do, you don't know if those programs will be 32-bit or 64-bit.
Jakub
Jakub Jelinek writes:
On Wed, Mar 23, 2005 at 05:33:13PM -0700, Tom Tromey wrote:
Programs like 'gcj-dbtool' and 'gij' are linked against a specific libgcj.so. If there is only one set of binaries, then it seems like we don't need to bother with multilib at all, since it will only ever be possible to use one particular libgcj.so -- the one 'gij' is linked to. At least, that is true in the common case... e.g., eclipse, which in the end invokes 'gij' at startup.
Or am I missing some magic that lets us pick libraries at runtime? I don't know how this could work, but I'm ready to be enlightened :-)
What prevents other programs to use libgcj.so (or now that there is libgij.so also libgij.so)?
Nothing.
And when they do, you don't know if those programs will be 32-bit or 64-bit.
I don't understand purpose of this comment. If there's a 32-bit multilib, the user will use -m32 at compile time, and that will link with the 32-bit library.
Andrew.
"Andrew" == Andrew Haley aph@redhat.com writes:
And when they do, you don't know if those programs will be 32-bit or 64-bit.
Andrew> I don't understand purpose of this comment. If there's a 32-bit Andrew> multilib, the user will use -m32 at compile time, and that will link Andrew> with the 32-bit library.
Jakub was responding to me, since I didn't see how people would end up using the non-default libgcj.so. But his point is that some program may link against it explicitly, or dlopen and use the invocation API. And so, since we can't predict now which library might be used on a fully installed system, we have to handle this somehow.
Anthony's gcj-dbtool patch went in, so we can start trying this soon. (FWIW I also didn't like the idea of having the ABI recorded in the .db.)
Have we worked everything out now? We solved the multilib problem, and there seems to be a consensus on where to put the .so cache.
Tom
On Tue, 2005-03-22 at 14:50 -0500, Jakub Jelinek wrote:
You mean that gcj-dbtool -p would print /usr/lib/`$CC $CFLAGS -print-multi-os-directory`/gcj-4.0.0/classmap.db and you'd need to pass that through shell after making sure $CC and $CFLAGS are properly defined? Then you'd put the burden on rpm packagers, because in rpm %post $RPM_OPT_FLAGS certainly aren't set (and, you shouldn't require gcc to be installed just to install Java packages).
This shouldn't require gcc at install time. We can create the application specific classmaps at build time, and simply merge them at install time.
AG
On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote:
I CC'd Jakub for advice. Jakub, what should we do to make the built-in .db file work with multilibs? I will implement whatever it is we need.
After looking at this for a bit, I recommend the following:
"gcj-dbtool -p" operates as usual (for no special reason) "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db
This is convenient because it is easy to implement and easy to use.
The %post and %postun spec file sections can simply do:
DB=`gcj-dbtool -p %{_libdir}`
and use DB for the database name. Presumably rpm will make sure that _libdir refers to the correct lib directory for the target ABI.
AG
Anthony Green writes:
On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote:
I CC'd Jakub for advice. Jakub, what should we do to make the built-in .db file work with multilibs? I will implement whatever it is we need.
After looking at this for a bit, I recommend the following:
"gcj-dbtool -p" operates as usual (for no special reason) "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db
This is convenient because it is easy to implement and easy to use.
The %post and %postun spec file sections can simply do:
DB=`gcj-dbtool -p %{_libdir}`
and use DB for the database name. Presumably rpm will make sure that _libdir refers to the correct lib directory for the target ABI.
That sounds pleasingly simple.
Andrew.
On Wed, 2005-03-23 at 18:42 +0000, Andrew Haley wrote:
Anthony Green writes:
On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote:
I CC'd Jakub for advice. Jakub, what should we do to make the built-in .db file work with multilibs? I will implement whatever it is we need.
After looking at this for a bit, I recommend the following:
"gcj-dbtool -p" operates as usual (for no special reason) "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db
[snip]
That sounds pleasingly simple.
There's a patch waiting for approval now:
http://gcc.gnu.org/ml/java-patches/2005-q1/msg00886.html
Hopefully it will find its way into rawhide update sometime soon.
AG
* Anthony Green green@redhat.com [2005-03-22 22:32]:
On Tue, 2005-03-22 at 11:48 -0700, Tom Tromey wrote:
I CC'd Jakub for advice. Jakub, what should we do to make the built-in .db file work with multilibs? I will implement whatever it is we need.
After looking at this for a bit, I recommend the following:
"gcj-dbtool -p" operates as usual (for no special reason) "gcj-dbtool -p LIBDIR" results in LIBDIR/gcj-VERSION/classmap.db
This is convenient because it is easy to implement and easy to use.
The %post and %postun spec file sections can simply do:
DB=`gcj-dbtool -p %{_libdir}`
and use DB for the database name. Presumably rpm will make sure that _libdir refers to the correct lib directory for the target ABI.
This sounds good. Can we put a database subdirectory at the same location?
LIBDIR/gcj-VERSION/classmap.d
Andrew
On Wed, 2005-03-23 at 13:53 -0500, Andrew Overholt wrote:
The %post and %postun spec file sections can simply do:
DB=`gcj-dbtool -p %{_libdir}`
and use DB for the database name. Presumably rpm will make sure that _libdir refers to the correct lib directory for the target ABI.
This sounds good. Can we put a database subdirectory at the same location?
LIBDIR/gcj-VERSION/classmap.d
Yes - in my spec file proposal I used $DB.d.
AG
Here's a real-world example from the servletapi5 spec file. It currently assumes that we should be using `gcj-dbtool -p`. Comments/suggestions welcome.
*** servletapi5.spec 2004-11-04 06:41:06.000000000 -0800 --- servletapi5.spec.new 2005-03-22 14:23:54.964489184 -0800 *************** *** 3,9 **** %define name %{base_name}%{major_version} %define full_name jakarta-%{base_name} %define version 5.0.18 ! %define release 1jpp_3fc %define section free
Name: %{name} --- 3,9 ---- %define name %{base_name}%{major_version} %define full_name jakarta-%{base_name} %define version 5.0.18 ! %define release 1jpp_4fc %define section free
Name: %{name} *************** *** 23,29 **** BuildRequires: xerces-j2, xml-commons-apis BuildRequires: jpackage-utils >= 1.5.30 BuildRequires: java-javadoc - BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot #Obsoletes: servlet4 #Obsoletes: servlet23 --- 23,28 ---- *************** *** 66,79 **** --- 65,91 ---- ant dist -Dservletapi.build=build -Dservletapi.dist=dist popd
+ # Generate native code. + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar + gcj-dbtool -n jspapi-%{version}.db + gcj-dbtool -f jspapi-%{version}.db jsr152/dist/lib/jsp-api.jar %{_libdir}/libjspapi-%{version}.jar.so + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o lib%{name}-%{version}.jar.so jsr154/dist/lib/servlet-api.jar + gcj-dbtool -n %{name}-%{version}.db + gcj-dbtool -f %{name}-%{version}.db jsr154/dist/lib/servlet-api.jar %{_libdir}/lib%{name}-%{version}.jar.so
%install cd jakarta-tomcat-%{version}-src/jakarta-servletapi-5 # jars install -d -m 755 $RPM_BUILD_ROOT%{_javadir} + install -d -m 755 $RPM_BUILD_ROOT%{_libdir} + install -d -m 755 $RPM_BUILD_ROOT`gcj-dbtool -p`.d
install -m 644 jsr152/dist/lib/jsp-api.jar $RPM_BUILD_ROOT%{_javadir}/jspapi-%{version}.jar install -m 644 jsr154/dist/lib/servlet-api.jar $RPM_BUILD_ROOT%{_javadir}/%{name}-%{version}.jar + install -m 644 libjspapi-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/libjspapi-%{version}.jar.so + install -m 644 lib%{name}-%{version}.jar.so $RPM_BUILD_ROOT%{_libdir}/lib%{name}-%{version}.jar.so + install -m 644 jspapi-%{version}.db $RPM_BUILD_ROOT`gcj-dbtool -p`.d/jspapi-%{version}.db + install -m 644 %{name}-%{version}.db $RPM_BUILD_ROOT`gcj-dbtool -p`.d/%{name}-%{version}.db
(cd $RPM_BUILD_ROOT%{_javadir} && for jar in *-%{version}*; do ln -sf ${jar} `echo $jar| sed "s|-%{version}||g"`; done)
*************** *** 94,105 **** --- 106,125 ---- %post update-alternatives --install %{_javadir}/servlet.jar servlet %{_javadir}/%{name}-%{version}.jar 50 #update-alternatives --install %{_javadir}/jsp.jar jsp %{_javadir}/jsp-api-%{version}.jar 50 + DB=`gcj-dbtool -p` + rm -f $DB + gcj-dbtool -n $DB + (cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
%postun if [ "$1" = "0" ]; then update-alternatives --remove servlet %{_javadir}/%{name}-%{version}.jar # update-alternatives --remove jsp %{_javadir}/jsp-api-%{version}.jar fi + DB=`gcj-dbtool -p` + rm -f $DB + gcj-dbtool -n $DB + (cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
%post javadoc rm -f %{_javadocdir}/%{name} *************** *** 110,115 **** --- 130,136 ---- %files %defattr(-,root,root) %doc LICENSE + %{_libdir}/* %{_javadir}/*
%files javadoc *************** *** 121,126 **** --- 142,150 ----
%changelog + * Tue Mar 22 2005 Anthony Green green@redhat.com 0:5.0.18-1jpp_4fc + - Generate native libraries. + * Thu Nov 4 2004 Gary Benson gbenson@redhat.com 0:5.0.18-1jpp_3fc - Build into Fedora.
%post update-alternatives --install %{_javadir}/servlet.jar servlet %{_javadir}/%{name}-%{version}.jar 50 #update-alternatives --install %{_javadir}/jsp.jar jsp %{_javadir}/jsp-api-%{version}.jar 50
- DB=`gcj-dbtool -p`
- rm -f $DB
- gcj-dbtool -n $DB
- (cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
I think it was Tom who suggested we should have some structure below the location of the db location to allow for name collisions. Will the:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
account for
$DB.d/foo/foo.jar.so
and
$DB.d/bar/bar.jar.so
and so on?
Regards
Phil
On Tue, 2005-03-22 at 16:41 -0600, Phil Muldoon wrote:
I think it was Tom who suggested we should have some structure below the location of the db location to allow for name collisions. Will the:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
account for
$DB.d/foo/foo.jar.so
and
$DB.d/bar/bar.jar.so
and so on?
No, but I think we should be using versioned names so, in theory, there should be no collisions.
# ls -l /usr/lib/gcj-4.0.0/classmap.db.d/ total 2832 -rw-r--r-- 1 root root 1441792 Mar 22 14:19 jspapi-5.0.18.db -rw-r--r-- 1 root root 1441792 Mar 22 14:19 servletapi5-5.0.18.db
BTW, I also think we should prefix the libs with "lib" and make them versioned.
# ls -l /usr/lib/libjspapi-5.0.18.jar.so -rw-r--r-- 1 root root 300642 Mar 22 14:19 /usr/lib/libjspapi-5.0.18.jar.so
This will make them usable for explicit linking, and make up a little bit for the fact that we don't have real so name versioning.
AG
On Tue, 2005-03-22 at 14:46 -0800, Anthony Green wrote:
On Tue, 2005-03-22 at 16:41 -0600, Phil Muldoon wrote:
I think it was Tom who suggested we should have some structure below the location of the db location to allow for name collisions. Will the:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
account for
$DB.d/foo/foo.jar.so
and
$DB.d/bar/bar.jar.so
and so on?
No, but I think we should be using versioned names so, in theory, there should be no collisions.
Okay, my example was wrong (s/jar.so/db), but I take your point. Right now appending version is something we don't do (because we can safely assume with our db and our location we won't have collision). Something to keep in mind. As long as it is tied with the version of the rpm then it should be cool. Maybe there are other issues here, but I can't think of any.
I can't be sure but I think the merge automatically deletes the destination "merge to" database, so there theoretically could be an issue with the size of the argument list provided from the ls . to xargs there. Not sure if this is something we should worry about in reality or not
Regards
Phil
On Tue, 2005-03-22 at 17:13 -0600, Phil Muldoon wrote:
I can't be sure but I think the merge automatically deletes the destination "merge to" database, so there theoretically could be an issue with the size of the argument list provided from the ls . to xargs there. Not sure if this is something we should worry about in reality or not
Oh, yes, you're right.
gcj-dbtool seems to create a temporary db and then copies it on top of the real one once complete. Given that, I think this would work:
DB=`gcj-dbtool -p` rm -f $DB gcj-dbtool -n $DB (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
[note the extra $DB on that last line]
AG
"Anthony" == Anthony Green green@redhat.com writes:
Anthony> No, but I think we should be using versioned names so, in Anthony> theory, there should be no collisions.
The name would have to include both the package name and the jar name in the package. It doesn't matter to me what particular naming convention we pick, as long as it is reasonably sensible and easy to automate... we can spell that with a '-' or a '/' :-)
The reason I opted for subdirectories is just that programs like eclipse already use them. It presents an obvious mapping from the .jar structure to the .so cache, and we know it cannot clash as the original package has no clashes.
Anthony> This will make them usable for explicit linking, and make up a little Anthony> bit for the fact that we don't have real so name versioning.
Yeah, this is attractive, at least for some of the libraries.
Tom
"Anthony" == Anthony Green green@redhat.com writes:
Anthony> Here's a real-world example from the servletapi5 spec file. It Anthony> currently assumes that we should be using `gcj-dbtool -p`. Anthony> Comments/suggestions welcome.
Anthony> + # Generate native code. Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar Anthony> + gcj-dbtool -n jspapi-%{version}.db [ ...]
If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial...
Tom
If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial...
Andrew Overholt and I mused around with creating a wiki page somewhere along the lines of "How to build your Java project with GCJ and package it to rpm", and highlight some of the pitfalls, and strategies involved here (that our group encountered with Eclipse). I'm not sure if Fedora Core has a semi official wiki somewhere, but it is something I would like to do. Also another wiki on how to debug your natively built Java app. Hopefully that would help any Extra's project find the right path; and make things even easier.
Regards
Phil
On 23 Mar 2005, at 18:55, Phil Muldoon wrote:
Andrew Overholt and I mused around with creating a wiki page somewhere along the lines of "How to build your Java project with GCJ and package it to rpm", and highlight some of the pitfalls, and strategies involved here (that our group encountered with Eclipse). I'm not sure if Fedora Core has a semi official wiki somewhere, but it is something I would like to do. Also another wiki on how to debug your natively built Java app. Hopefully that would help any Extra's project find the right path; and make things even easier.
How about this? I would be interested in your notes.
On Wed, 2005-03-23 at 18:55 -0600, Phil Muldoon wrote:
Andrew Overholt and I mused around with creating a wiki page somewhere along the lines of "How to build your Java project with GCJ and package it to rpm", and highlight some of the pitfalls, and strategies involved here (that our group encountered with Eclipse). I'm not sure if Fedora Core has a semi official wiki somewhere, but it is something I would like to do. Also another wiki on how to debug your natively built Java app. Hopefully that would help any Extra's project find the right path; and make things even easier.
I think that would be very useful.
Maybe you could add it to http://fedoraproject.org/wiki/ ?
Thanks,
Tadej
On Sat, 2005-03-26 at 11:09 +0100, Tadej Janež wrote:
I think that would be very useful.
Maybe you could add it to http://fedoraproject.org/wiki/ ?
Thanks,
Tadej
On Thu, 2005-03-24 at 14:04 +0000, Phil Shaw wrote:
How about this? I would be interested in your notes.
Okay, when the current rush has died down, I'll write something up, and post it to both sites.
Regards
Phil
Phil,
If you could post here when you've done that, I'd be most appreciative.
Regards,
Dave Orme
Phil Muldoon wrote:
On Sat, 2005-03-26 at 11:09 +0100, Tadej Janež wrote:
I think that would be very useful.
Maybe you could add it to http://fedoraproject.org/wiki/ ?
Thanks,
Tadej
On Thu, 2005-03-24 at 14:04 +0000, Phil Shaw wrote:
How about this? I would be interested in your notes.
Okay, when the current rush has died down, I'll write something up, and post it to both sites.
Regards
Phil
-- fedora-devel-java-list mailing list fedora-devel-java-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote:
"Anthony" == Anthony Green green@redhat.com writes:
Anthony> Here's a real-world example from the servletapi5 spec file. It Anthony> currently assumes that we should be using `gcj-dbtool -p`. Anthony> Comments/suggestions welcome.
Anthony> + # Generate native code. Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar Anthony> + gcj-dbtool -n jspapi-%{version}.db [ ...]
If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial...
If someone sends me the script I can add it to java-1.4.2-gcj-compat.
Tom
On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote:
"Anthony" == Anthony Green green@redhat.com writes:
Anthony> Here's a real-world example from the servletapi5 spec file. It Anthony> currently assumes that we should be using `gcj-dbtool -p`. Anthony> Comments/suggestions welcome.
Anthony> + # Generate native code. Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar Anthony> + gcj-dbtool -n jspapi-%{version}.db [ ...]
If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial...
hmmm.. what do you mean by "find" in find-compile-db? I don't think it's safe to simply compile and db-ify any .jar file in your build tree.
The best we might hope for is probably something like...
gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
SRC_JARFILE refers to the jar file we want to process.
DEST_SO_NAME is the name we want to install it as. JPackages seem to use different build and install jar names in some cases, so we can't infer from SRC_JARFILE. And we should probably version the library name.
BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS. I suppose the script can handle certain options, like -findirect- dispatch and -Wl,Bsymbolic.
I'm not sure I'd call this utterly trivial. Is it enough of an improvement over what I suggested earlier?
Then we could have another little script to replace:
DB=`gcj-dbtool -p %{_libdir}` rm -f $DB gcj-dbtool -n $DB (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
Could these go in java-gcj-compat? Or maybe as RPM macros?
AG
"Anthony" == Anthony Green green@redhat.com writes:
If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial...
Anthony> hmmm.. what do you mean by "find" in find-compile-db? I Anthony> don't think it's safe to simply compile and db-ify any .jar Anthony> file in your build tree.
I was thinking we would do this in %install, by compiling every jar (or war or ...) we found in the install tree. But maybe it is ugly not to do in %build -- in which case, yeah, we need to do more manually.
Anthony> The best we might hope for is probably something like... Anthony> gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
Anthony> I'm not sure I'd call this utterly trivial. Is it enough of an Anthony> improvement over what I suggested earlier?
One thing that is nice about it is we can unpack and compile war files in the script. I suppose if we wanted we could also purge non-.class files from jars here as well, at least until gcj gets an option to do this.
Anthony> Then we could have another little script to replace: Anthony> DB=`gcj-dbtool -p %{_libdir}` Anthony> rm -f $DB Anthony> gcj-dbtool -n $DB Anthony> (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB) Anthony> Could these go in java-gcj-compat? Or maybe as RPM macros?
Yeah, Tom F. offered to put them as scripts in java-gcj-compat. Let's do that for the time being.
Tom
On Fri, 2005-03-25 at 11:33 -0700, Tom Tromey wrote:
Anthony> hmmm.. what do you mean by "find" in find-compile-db? I Anthony> don't think it's safe to simply compile and db-ify any .jar Anthony> file in your build tree.
I was thinking we would do this in %install, by compiling every jar (or war or ...) we found in the install tree. But maybe it is ugly not to do in %build -- in which case, yeah, we need to do more manually.
I don't think we'll get much support for compiling these at install time: (1) as Jakub recently pointed out, it would require gcj to be installed just to install java applications. (2) releng types have told us that slowing down the install by compiling things at install time is a non-starter.
AG
"Anthony" == Anthony Green green@redhat.com writes:
I was thinking we would do this in %install, by compiling every jar (or war or ...) we found in the install tree. But maybe it is ugly not to do in %build -- in which case, yeah, we need to do more manually.
Anthony> I don't think we'll get much support for compiling these at install Anthony> time:
There's some terminology confusion here. As I understand RPM, which is not much, '%install' is a step that is run while building the RPM itself. %build does the "building", and %install puts the results into an install tree. Then RPM uses %files to figure out how to break down the install tree into different binary RPMs. There are other sections you can specify if you want some script to be run when the RPM itself is installed.
Tom
Anthony Green writes:
On Wed, 2005-03-23 at 17:44 -0700, Tom Tromey wrote:
> "Anthony" == Anthony Green green@redhat.com writes:
Anthony> Here's a real-world example from the servletapi5 spec file. It Anthony> currently assumes that we should be using `gcj-dbtool -p`. Anthony> Comments/suggestions welcome.
Anthony> + # Generate native code. Anthony> + gcj $RPM_OPT_FLAGS -shared -findirect-dispatch -Wl,-Bsymbolic -o libjspapi-%{version}.jar.so jsr152/dist/lib/jsp-api.jar Anthony> + gcj-dbtool -n jspapi-%{version}.db [ ...]
If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial...
hmmm.. what do you mean by "find" in find-compile-db? I don't think it's safe to simply compile and db-ify any .jar file in your build tree.
The best we might hope for is probably something like...
gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
SRC_JARFILE refers to the jar file we want to process.
DEST_SO_NAME is the name we want to install it as. JPackages seem to use different build and install jar names in some cases, so we can't infer from SRC_JARFILE. And we should probably version the library name.
BUILD_OPTIONS is needed because we want to pass in $RPM_OPT_FLAGS. I suppose the script can handle certain options, like -findirect- dispatch and -Wl,Bsymbolic.
I'm not sure I'd call this utterly trivial. Is it enough of an improvement over what I suggested earlier?
Then we could have another little script to replace:
DB=`gcj-dbtool -p %{_libdir}` rm -f $DB
I don't like this. Any process that starts during this time will fail because the .db is missing.
The right way is to find everything and merge into the master.
This is how it should work:
DB=`gcj-dbtool -p %{_libdir}` (cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
If we expect problems with command line lengths I'll fix gcj-dbtool to take the list from stdin.
Andrew.
* Anthony Green green@redhat.com [2005-03-24 20:30]:
If it isn't too unwieldy, I would like to see this whole section replaced by a single call to some shell script to automate the find-compile-db loop. My goal is to make gcj-izing a jpackage RPM utterly trivial...
<snip>
The best we might hope for is probably something like...
gcj-nativify -build SRC_JARFILE DEST_SO_NAME BUILD_OPTIONS
Then we could have another little script to replace:
DB=`gcj-dbtool -p %{_libdir}` rm -f $DB gcj-dbtool -n $DB (cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
How about the attached three scripts? gcj-findandnativify.sh is kinda flaky, but it'll work well for us during the eclipse build procedure (I'm testing a build now). I've attached a patch to the current eclipse.spec and it simplifies things greatly. Comments welcome.
Could these go in java-gcj-compat? Or maybe as RPM macros?
Tom Fitzsimmons has offered to put these in java-gcj-compat.
Andrew
It's been pointed out to me that if we merge db's with the obvious
(find . -name 'temp-*.db' | xargs gcj-dbtool -m $DB)
we run the risk of failure if arg length exceeds the operating system limit, because xargs will call gcj-dbtool several times.
The right way to fix this is to have gcj-dbtool read a list of files from stdin, which is what this patch does.
(find . -name 'temp-*.db' | gcj-dbtool - -m $DB)
Andrew.
2005-03-30 Andrew Haley aph@redhat.com
* gnu/gcj/tools/gcj_dbtool/Main.java (Fileset): New class. (getFiles): New method. (main): Add "-" argument. Read list of files from stdin when merging map databases. (usage): Add "-" argument. Minor corrections.
Index: Main.java =================================================================== RCS file: /cvs/gcc/gcc/libjava/gnu/gcj/tools/gcj_dbtool/Main.java,v retrieving revision 1.9 diff -c -2 -p -r1.9 Main.java *** Main.java 25 Mar 2005 00:38:43 -0000 1.9 --- Main.java 30 Mar 2005 15:04:15 -0000 *************** public class Main *** 23,27 **** --- 23,37 ---- public static void main (String[] s) { + boolean fileListFromStdin = false; insist (s.length >= 1); + + if (s[0].equals("-")) + { + fileListFromStdin = true; + String[] newArgs = new String[s.length - 1]; + System.arraycopy(s, 1, newArgs, 0, s.length - 1); + s = newArgs; + } + if (s[0].equals("-v") || s[0].equals("--version")) { *************** public class Main *** 146,151 **** { // Merge databases. ! insist (s.length >= 3); ! try { File database = new File(s[1]); --- 156,162 ---- { // Merge databases. ! insist (s.length >= 3 ! || fileListFromStdin && s.length == 2); ! try { File database = new File(s[1]); *************** public class Main *** 156,171 **** int newSize = 0; int newStringTableSize = 0; ! PersistentByteMap[] sourceMaps = new PersistentByteMap[s.length - 2]; // Scan all the input files, calculating worst case string // table and hash table use. ! for (int i = 2; i < s.length; i++) ! { ! PersistentByteMap b ! = new PersistentByteMap(new File(s[i]), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i - 2] = b; ! } newSize *= 1.5; // Scaling the new size by 1.5 results in --- 167,188 ---- int newSize = 0; int newStringTableSize = 0; ! Fileset files = getFiles(s, 2, fileListFromStdin); ! PersistentByteMap[] sourceMaps = new PersistentByteMap[files.size()]; ! // Scan all the input files, calculating worst case string // table and hash table use. ! { ! Iterator it = files.iterator(); ! int i = 0; ! while (it.hasNext()) ! { ! PersistentByteMap b ! = new PersistentByteMap((File)it.next(), ! PersistentByteMap.AccessMode.READ_ONLY); ! newSize += b.size(); ! newStringTableSize += b.stringTableSize(); ! sourceMaps[i++] = b; ! } ! } newSize *= 1.5; // Scaling the new size by 1.5 results in *************** public class Main *** 297,310 **** + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a new gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name"); }
--- 314,329 ---- + " gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database\n" + " gcj-dbtool -a file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -f file.gcjdb file.jar file.so\n" ! + " - Add the contents of file.jar to a gcj map database\n" + " gcj-dbtool -t file.gcjdb - Test a gcj map database\n" + " gcj-dbtool -l file.gcjdb - List a gcj map database\n" ! + " gcj-dbtool [-] -m dest.gcjdb [source.gcjdb]...\n" ! + " - Merge gcj map databases into dest\n" ! + " Replaces dest\n" ! + " To add to dest, include dest in the list of sources\n" ! + " If the first arg is -, read the list from stdin\n" ! + " gcj-dbtool -p [LIBDIR] - Print default database name" ! ); }
*************** public class Main *** 406,409 **** --- 425,485 ---- return hexBytes.toString(); } + + + // Return a Fileset, either from a String array or from System.in, + // depending on fileListFromStdin. + private static final Fileset getFiles(String[] s, int startPos, + boolean fileListFromStdin) + { + if (fileListFromStdin) + return new Fileset(System.in); + else + return new Fileset(s, startPos, s.length); + } }
+ // A Fileset is a container for a set of files; it can be created + // either from a string array or from an input stream. + class Fileset + { + LinkedHashSet files = new LinkedHashSet(); + + Fileset (String[] s, int start, int end) + { + for (int i = start; i < end; i++) + { + files.add(new File(s[i])); + } + } + + Fileset (InputStream is) + { + Reader r = new BufferedReader(new InputStreamReader(is)); + StringBuffer buf = new StringBuffer(); + try + { + int chr; + while ((chr = r.read()) != -1) + buf.append((char)chr); + } + catch (IOException _) + { + } + StringTokenizer st = new StringTokenizer(buf.toString()); + while (st.hasMoreElements ()) + { + String name = st.nextToken (); + files.add(new File(name)); + } + } + + Iterator iterator() + { + return files.iterator(); + } + + int size() + { + return files.size(); + } + }
Hi,
On Tue, 2005-03-29 at 17:48 -0500, Andrew Overholt wrote:
Could these go in java-gcj-compat? Or maybe as RPM macros?
Tom Fitzsimmons has offered to put these in java-gcj-compat.
These scripts are in java-1.4.2-gcj-compat-1.4.2.0-40jpp_14rh. I renamed them find-and-nativify, nativify and rename-gcj-db.
Tom
* Andrew Overholt overholt@redhat.com [2005-03-29 16:52]: [...]
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
[...]
I'm thinking this should be:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
What's the purpose of the extraneous $DB? I don't think we want it because we actually want the entire db recreated every time. We don't want entries that are not in sub-dbs in $DB.d to be in the resultant db. Does that make sense?
Andrew
On Mon, 2005-04-04 at 21:36 -0400, Andrew Overholt wrote:
- Andrew Overholt overholt@redhat.com [2005-03-29 16:52]:
[...]
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
[...]
I'm thinking this should be:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
What's the purpose of the extraneous $DB? I don't think we want it because we actually want the entire db recreated every time. We don't want entries that are not in sub-dbs in $DB.d to be in the resultant db. Does that make sense?
The -m option cases the destination database to be overwritten. If you want to maintain its contents you need to specify it as a source database. From "gcj-dbtool --help" output:
gcj-dbtool -m dest.gcjdb [source.gcjdb]... - Merge gcj map databases into dest Replaces dest To add to dest, include dest in the list of sources
But as I understand it, rebuild-gcj-db is supposed to rebuild classmap.db from scratch. If that's the intended behaviour (and is safe -- aph?) then
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
is correct.
Tom
Andrew Overholt writes:
- Andrew Overholt overholt@redhat.com [2005-03-29 16:52]:
[...]
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB $DB)
[...]
I'm thinking this should be:
(cd $DB.d; ls . | xargs gcj-dbtool -m $DB)
What's the purpose of the extraneous $DB? I don't think we want it because we actually want the entire db recreated every time. We don't want entries that are not in sub-dbs in $DB.d to be in the resultant db. Does that make sense?
Yes. The extra $DB is there because xargs will call gcj-dbtool multiple times if it needs to. The right answer is not to use xargs.
Andrew.
java-devel@lists.fedoraproject.org
-
Andrew Haley -
Andrew Overholt -
Anthony Green -
David J. Orme -
Jakub Jelinek -
Phil Muldoon -
Phil Shaw -
Tadej Janež -
Thomas Fitzsimmons -
Tom Tromey