Re: [BLFS Trac] #2319: JDK-1.5.0 Update 11
Updated BLFS to JDK-1.5.0.11 source and binary. > Some notes: > > I listed the source download urls as it appears they are freely > available without acknowloging a license agreement. Apparently, > the license in the code is enough. You still must click on a > link to agree to the binary download license. > Cool, cool, cool. I was gonna update that because there are some JDK6 issues yet, see below. > Added an instruction to delete the copy of the binary download. > IIRC, the sed is not necessary anymore since we don't care which head program we use. The instructions that needed the modification have long since been removed (bypass the license agreement). I had completely forgotten the why and had missed it in last review. I do know for certain that it's not needed in the new version so they have already been removed from the pending JDK6u1 instructions. BTW, an update on that. JDK6 can't go in yet due to the JDBC4 changes WRT hsqldb (from OOo) and probably bdb too (haven't checked). Most upstream was building against b88 or b93 (can't recall), and Sun pulled the EOU features from derby (java db) shortly before release, so not much help yet from the package maintainers. Fop and Subversion build OK, as do a couple of other packages who's names slip my mind, but I haven't tested with any _real_ use other than the plugin and compiler. I did kick out a PDF BLFS book with FOP-93? and all looked well. Also, one of the test suites had to be run in a windowed environment, I think FOP but not sure. No time to check right now, but will get back soon. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0-07 nitpick
Simon Scheiwiller wrote: > Yes, that would be clear ;-) > > Simon > Cool. Thanks for taking the time to explain. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0-07 nitpick
Thus spoke DJ Lucas: > NO..your are completely right! :-) Rereading the OP, I had thought your > interpretation of 'prefix' was incorrect until a few seconds ago. Now, > what to do to make it more clear for others that will read it in the > future? I think replacing '' with '' in the book's > command should make it more clear what to do. Also, replace 'adjust as > necessary' with 'replace with your X Window System installation > prefix' in the text above the command. Sound good? > Yes, that would be clear ;-) Simon -- simon scheiwiller bollstrasse 21 ch-8405 winterthur +41 78 624 16 73 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0-07 nitpick
Simon Scheiwiller wrote: > If I understood the sed command correctly, it replaces /usr/X11R6 in the > files with /usr or whatever is replaced with. So /usr/X11R6 is in > the original files and mustn't be changed, because otherwise the sed > command wouldn't make sense at all. But if you have another X prefix than > /usr (say /usr/X11R7 you have to change the sed argument to > 's@/usr/X11R6@/usr/[EMAIL PROTECTED]' > > Am I completely wrong here? > NO..your are completely right! :-) Rereading the OP, I had thought your interpretation of 'prefix' was incorrect until a few seconds ago. Now, what to do to make it more clear for others that will read it in the future? I think replacing '' with '' in the book's command should make it more clear what to do. Also, replace 'adjust as necessary' with 'replace with your X Window System installation prefix' in the text above the command. Sound good? -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0-07 nitpick
Thus spoke DJ Lucas: > I'm not sure I follow. The expected prefix is /usr/X11R6. If that is > not the prefix applied to your installation of the X Window System, then > you will need to execute the commands so that the build knows where to > find the X Window System. Although, the '' needs to be changed to > '' so the changed portion is more obvious and consistent with > the rest of the book. > > If I've misunderstood the part that you find unclear, would you mind > suggesting a better way to state the entire message? I can get it in > the book in a matter of minutes so that others won't have trouble with > it in the future. If I understood the sed command correctly, it replaces /usr/X11R6 in the files with /usr or whatever is replaced with. So /usr/X11R6 is in the original files and mustn't be changed, because otherwise the sed command wouldn't make sense at all. But if you have another X prefix than /usr (say /usr/X11R7 you have to change the sed argument to 's@/usr/X11R6@/usr/[EMAIL PROTECTED]' Am I completely wrong here? Simon -- simon scheiwiller bollstrasse 21 ch-8405 winterthur +41 78 624 16 73 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0-07 nitpick
Simon Scheiwiller wrote:
> Hi there
>
> That part:
>
> If your X Window System is installed in any prefix other than /usr/X11R6,
> adjust as necessary and execute the following command:
>
> find . -type f -exec sed -i 's@/usr/X11R6@@g' {} \;
>
> is quite confusing. Maybe it should rather be: If your X Window System is
> installed in any prefix other than /usr, ...
>
> Simon
I'm not sure I follow. The expected prefix is /usr/X11R6. If that is
not the prefix applied to your installation of the X Window System, then
you will need to execute the commands so that the build knows where to
find the X Window System. Although, the '' needs to be changed to
'' so the changed portion is more obvious and consistent with
the rest of the book.
If I've misunderstood the part that you find unclear, would you mind
suggesting a better way to state the entire message? I can get it in
the book in a matter of minutes so that others won't have trouble with
it in the future.
Thanks.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
JDK-1.5.0-07 nitpick
Hi there
That part:
If your X Window System is installed in any prefix other than /usr/X11R6,
adjust as necessary and execute the following command:
find . -type f -exec sed -i 's@/usr/X11R6@@g' {} \;
is quite confusing. Maybe it should rather be: If your X Window System is
installed in any prefix other than /usr, ...
Simon
--
simon scheiwiller
bollstrasse 21
ch-8405 winterthur
+41 78 624 16 73
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: jdk-1.5.0 build error
Jeremy Byron wrote:
> DJ Lucas wrote:
>
>>
>>I'll start an optimized build tonight. If it comes down to it, a patch
>>could be created to not pass OTHER_CXXFLAGS to the jar/jarutils subdirs.
>> Unfortunately, my equip is a little older, -march=athlon will have to
>>do for my testing, though we'll probably find the culprit to be -O3. :-)
>
>
> I just failed another build with the OTHER_C{,XX}FLAGS set as '-O3
> -march=athlon-fx' as before. Figures it has to be so far into the build
> as it makes testing things kinda time consuming.
>
> Anyhow, let me know if you want me to run any more builds with different
> options or a patch to save you some time.
>
> Regards,
> Jeremy.
Just to lay it to rest, -O3 opt is the culpret. readelf -s reveals that
zip.o does not contain the necessary gunzip symbols that are required.
Here is the correct output of 'readelf -s zip.o | grep gunzip' from the
changed makefile (see below).
73: 0f1c 102 FUNCGLOBAL DEFAULT1 _ZN6gunzip4freeEv
74: 0cd6 145 FUNCGLOBAL DEFAULT1 _ZN6gunzip4initEP8unpacke
76: 0d68 435 FUNCGLOBAL DEFAULT1 _ZN6gunzip5startEi
77: 0f82 147 FUNCGLOBAL DEFAULT1 _ZN6gunzip16read_fixed_fi
78: 40 FUNCWEAK DEFAULT 31 _ZN6gunzip8abortingEv
80: 44 FUNCWEAK DEFAULT 29 _ZN6gunzip5abortEPKc
In the future, removing the object files and adding this line
'CXXFLAGS= $(CXXFLAGS_$(VARIANT)) $(CXXFLAGS_COMMON)'
_after_ the common/Defs.gmk include will handle the opts correctly in
j2se/make/com/sun/java/pack/Makefile. I'm going to let the build
complete...or die again to see if I can tickle any more opt failures
since they are fairly easy to fix. I do not understand the internals of
the compiler enough to make even a real guess as to why these
differences occur. Any compiler gurus? Would it be enough to use those
functions in zip.cpp and do nothing with them to make them remain in the
resulting object file? Also, which exact opimization is it (implied in
-O3) that would cause them not to show?
-- DJ Lucas
PS To top it off, the build completed successfully while I typed that.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: jdk-1.5.0 build error
DJ Lucas wrote:
>
> I'll start an optimized build tonight. If it comes down to it, a patch
> could be created to not pass OTHER_CXXFLAGS to the jar/jarutils subdirs.
>Unfortunately, my equip is a little older, -march=athlon will have to
> do for my testing, though we'll probably find the culprit to be -O3. :-)
I just failed another build with the OTHER_C{,XX}FLAGS set as '-O3
-march=athlon-fx' as before. Figures it has to be so far into the build
as it makes testing things kinda time consuming.
Anyhow, let me know if you want me to run any more builds with different
options or a patch to save you some time.
Regards,
Jeremy.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: jdk-1.5.0 build error
Jeremy Byron wrote:
> DJ Lucas wrote:
>
>>
>>
>>>/usr/src/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/u
>>>npack-cmd/obj/main.o: In function `.L93':
>>>main.cpp:(.text+0xd1c): undefined reference to `gunzip::init(unpacker*)'
>>>main.cpp:(.text+0xd2e): undefined reference to `gunzip::start(int)'
>>>collect2: ld returned 1 exit status
>>
>>
>>
>>So for an uneducated, shoot from the hip, wild ass guess, ;-) zip.o
>>miscompiled or not in the ld command? It looks as though zip.o has
>
> Looks like it may well be that it miscompiled. I was using
> OTHER_C{,XX}FLAGS='-O3 -march=athlon-fx' as the book suggested in place
> of C{,XX}FLAGS for (I assumed safe) optimizations. I tried unsetting
> those in the build tree and rerunning make but to no effect so I assumed
> that they weren't the cause - probably should have started clean.
>
> Starting from a clean build directory without the OTHER_C{,XX}FLAGS
> variables set resulted in a completed build.
>
>
Jeremy, thanks for the reply. Very good to hear that the build completed.
>
> Of course, now I'm not in a position to look into your other suggestions
> at the moment, having deleted the faulty build directory, but I will try
> to build it again with the optimizations to be sure they were at fault.
> (I had also reinstalled gzip, though I doubt that was the cure). If it
> fails again, at least you can maybe caution against the use of
> optimizations entirely rather than suggesting the alternate variables.
> Also, assuming it fails again I will try your suggestions to maybe find
> out why.
>
I'll start an optimized build tonight. If it comes down to it, a patch
could be created to not pass OTHER_CXXFLAGS to the jar/jarutils subdirs.
Unfortunately, my equip is a little older, -march=athlon will have to
do for my testing, though we'll probably find the culprit to be -O3. :-)
> Thanks very much for your effort; if nothing else I'll keep grep in mind
> as a starting point for next time.
>
> Cheers,
> Jeremy.
Robert, I wasn't sure if you followed this list or not, sorry in advance
for the CC if so. Did you by chance use optimizations in your build
that failed with the same error?
Thanks.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: jdk-1.5.0 build error
DJ Lucas wrote:
>
>
>>/usr/src/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/u
>>npack-cmd/obj/main.o: In function `.L93':
>>main.cpp:(.text+0xd1c): undefined reference to `gunzip::init(unpacker*)'
>>main.cpp:(.text+0xd2e): undefined reference to `gunzip::start(int)'
>>collect2: ld returned 1 exit status
>
>
>
> So for an uneducated, shoot from the hip, wild ass guess, ;-) zip.o
> miscompiled or not in the ld command? It looks as though zip.o has
Looks like it may well be that it miscompiled. I was using
OTHER_C{,XX}FLAGS='-O3 -march=athlon-fx' as the book suggested in place
of C{,XX}FLAGS for (I assumed safe) optimizations. I tried unsetting
those in the build tree and rerunning make but to no effect so I assumed
that they weren't the cause - probably should have started clean.
Starting from a clean build directory without the OTHER_C{,XX}FLAGS
variables set resulted in a completed build.
> built correctly earlier on in the compile log. I checked the changes in
> current mustang (JDK6) and no changes worth mentioning in com/sun at
> all. The only thing that I can see of note is that the build differs
> with use of gcc-3.4.3 and HJL binutils-2.16.90.0.3. You might try to
> add 'export MAKE_VERBOSE=true' to your environment so we can see the
> compiler output to get a better handle on things. Also, you might want
> to rm the object files in the output directory
> 'rm \
> control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/*.o`
> and see what we see from zip.cpp forward, though I'm expecting similar
> output but with a compiler command.
Of course, now I'm not in a position to look into your other suggestions
at the moment, having deleted the faulty build directory, but I will try
to build it again with the optimizations to be sure they were at fault.
(I had also reinstalled gzip, though I doubt that was the cure). If it
fails again, at least you can maybe caution against the use of
optimizations entirely rather than suggesting the alternate variables.
Also, assuming it fails again I will try your suggestions to maybe find
out why.
Thanks very much for your effort; if nothing else I'll keep grep in mind
as a starting point for next time.
Cheers,
Jeremy.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: jdk-1.5.0 build error
Jeremy Byron wrote:
> Has a solution for this been found? I've just received the same error
> and haven't been able to find anything but this old thread which didn't
> go anywhere.
>
> My setup:
> CPU: AMD Athlon 64 FX-53
> HOST: LFS-6.0
> LFS: SVN-20050605
> BLFS: SVN-20050621 (..and back as far as June 6)
> (gcc-3.4.4,glibc-2.3.5,binutils-2.16,gzip-1.3.5)
>
> Any thoughts on how to go about fixing this would be much appreciated; I
> guess finding out how to deal with 'undefined reference to
> aaa::bbb(ccc)' in general would be a good start. In any case a more
> lengthy build log follows in case it helps.
>
> Much thanks,
> Jeremy.
> /usr/src/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/u
> npack-cmd/obj/main.o: In function `.L93':
> main.cpp:(.text+0xd1c): undefined reference to `gunzip::init(unpacker*)'
> main.cpp:(.text+0xd2e): undefined reference to `gunzip::start(int)'
> collect2: ld returned 1 exit status
Not as of yet. Here is what I can find in a working build tree:
[EMAIL PROTECTED] pack]# pwd
/media/lfs/usr/src/jdk-build/jdk-build/j2se/src/share/native/com/sun/java/util/jar/pack
[EMAIL PROTECTED] pack]# grep -R "gunzip" *
main.cpp: gunzip* gzin = NEW(gunzip, 1);
unpack.h:struct gunzip;
unpack.h: gunzip* gzin; // gunzip filter, if any
zip.cpp: //fprintf(u->errstrm, "readInputFn(%d,%d) => %d (gunzip)\n",
zip.cpp:void gunzip::init(unpacker* u_) {
zip.cpp:void gunzip::start(int magic) {
zip.cpp:void gunzip::free() {
zip.cpp:void gunzip::read_fixed_field(char* buf, size_t buflen) {
zip.cpp:void gunzip::free() {
zip.h:struct gunzip {
[EMAIL PROTECTED] pack]#
So for an uneducated, shoot from the hip, wild ass guess, ;-) zip.o
miscompiled or not in the ld command? It looks as though zip.o has
built correctly earlier on in the compile log. I checked the changes in
current mustang (JDK6) and no changes worth mentioning in com/sun at
all. The only thing that I can see of note is that the build differs
with use of gcc-3.4.3 and HJL binutils-2.16.90.0.3. You might try to
add 'export MAKE_VERBOSE=true' to your environment so we can see the
compiler output to get a better handle on things. Also, you might want
to rm the object files in the output directory
'rm \
control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/*.o`
and see what we see from zip.cpp forward, though I'm expecting similar
output but with a compiler command.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
jdk-1.5.0 build error
On Tue, 26 Apr 2005, DJ Lucas wrote: >> Robert Connolly wrote: >> Hi. I get: >> >>/sources/sun_java/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o(.text+0xd7c): >> In function `.L93': >> main.cpp: undefined reference to `gunzip::init(unpacker*)' >>/sources/sun_java/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o(.text+0xd8e):main.cpp: >> undefined reference to `gunzip::start(int)' >> collect2: ld returned 1 exit status >> make[7]: *** >> [/sources/sun_java/jdk-build/control/build/linux-i586/bin/unpack200] >> Error 1 >> >> from jdk-1.5.0. I'm using lfs-unstable. >> >> robert > >New one for me and I've built it 6 times in the past week. By any >chance did you log the output? A little more of the text above could >be helpful, like mabye the actual compiler command line if visible. >-lz??? (I kinda doctored the above reply from web output.. hope I didn't goof it up too badly.. heh) Has a solution for this been found? I've just received the same error and haven't been able to find anything but this old thread which didn't go anywhere. My setup: CPU: AMD Athlon 64 FX-53 HOST: LFS-6.0 LFS: SVN-20050605 BLFS: SVN-20050621 (..and back as far as June 6) (gcc-3.4.4,glibc-2.3.5,binutils-2.16,gzip-1.3.5) Any thoughts on how to go about fixing this would be much appreciated; I guess finding out how to deal with 'undefined reference to aaa::bbb(ccc)' in general would be a good start. In any case a more lengthy build log follows in case it helps. Much thanks, Jeremy. ** <<>>Recursively making pack all @ Wed Jun 22 14:47:21 PDT 2005 ... make[5]: Entering directory `/usr/src/jdk-build/j2se/make/com/sun/java/pack' make /usr/src/jdk-build/control/build/linux-i586/lib/i386/libunpack.so unpacker VARIANT=OPT make[6]: Entering directory `/usr/src/jdk-build/j2se/make/com/sun/java/pack' rm -f /usr/src/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar. pack/unpack/.classes.list if [ -s /usr/src/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.ja r.pack/unpack/.classes.list ] ; \ then /usr/src/jdk-build/control/build/linux-i586/bin/javac -J-XX:ThreadStackSiz e=768 -J-Xms64m -J-Xmx256m -classpath /usr/src/jdk-build/control/build/linux-i58 6/classes -bootclasspath "/usr/src/jdk-build/control/build/linux-i586/lib/jce.ja r:/usr/src/jdk-build/control/build/linux-i586/lib/jsse.jar" -sourcepath "/usr/sr c/jdk-build/control/build/linux-i586/gensrc:../../../../../src/solaris/classes:. ./../../../../src/share/classes" -d /usr/src/jdk-build/control/build/linux-i586/ classes -encoding ascii -source 1.5 \ ; \ fi make /usr/src/jdk-build/control/build/linux-i586/bin/unpack200 STANDALONE=true make[7]: Entering directory `/usr/src/jdk-build/j2se/make/com/sun/java/pack' echo -e "Resource files not required for Unix" Resource files not required for Unix g++ -fPIC -DCC_NOEX -W -Wall -Wno-unused -Wno-parentheses -I../../../../../src /share/native/java/util/zip/zlib-1.1.3 -DPRODUCT -DFULL -Di586 -DARCH='"i586"' -DLINUX -DRELEASE='"1.5.0-internal"' -DFULL_VERSION='"1.5.0-internal-blfs-svn"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -D_LITTLE_ENDIAN -I. -I/usr/sr c/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/C ClassHeaders -I../../../../../src/solaris/javavm/export -I../../../../../src/sha re/javavm/export -I../../../../../src/share/javavm/include -I../../../../../src/ solaris/javavm/include -I../../../../../src/share/native/common -I../../../../.. /src/solaris/native/common -I../../../../../src/share/native/com/sun/java/util/j ar/pack -I../../../../../src/solaris/native/com/sun/java/util/jar/pack -Xlinke r -O1 -Wl,-soname=libunpack.so -z defs -L/usr/src/jdk-build/control/build/linux- i586/lib/i386 -static-libgcc /usr/src/jdk-build/control/build/linux-i586/tmp/s un/java.util.zip/zip/obj/zcrc32.o /usr/src/jdk-build/control/build/linux-i586/tm p/sun/java.util.zip/zip/obj/deflate.o /usr/src/jdk-build/control/build/linux-i58 6/tmp/sun/java.util.zip/zip/obj/trees.o /usr/src/jdk-build/control/build/linux-i 586/tmp/sun/java.util.zip/zip/obj/zadler32.o /usr/src/jdk-build/control/build/li nux-i586/tmp/sun/java.util.zip/zip/obj/zutil.o /usr/src/jdk-build/control/build/ linux-i586/tmp/sun/java.util.zip/zip/obj/inflate.o /usr/src/jdk-build/control/bu ild/linux-i586/tmp/sun/java.util.zip/zip/obj/infblock.o /usr/src/jdk-build/contr ol/build/linux-i586/tmp/sun/java.util.zip/zip/obj/infcodes.o /usr/src/jdk-build/ control/build/linux-i586/tmp/sun/java.util.zip/zip/obj/inftrees.o /usr/src/jdk-b uild/control/build/linux-i586/tmp/sun/java.util.zip/zip/obj
Re: Strange tar error while building jdk-1.5.0
Matthew Burgess: > I *think* this was a bug in tar-1.15. Upgrading to 1.15.1 should allow > jdk-1.5.0 to install correctly - I didn't have any problems with that > version anyway. The ChangeLog says that 1.15 had problems untarring from standard input. Just tried with 1.15.1, and everything's fine (again). Case closed. Regards, -- Hans-Joachim Widmaier -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Strange tar error while building jdk-1.5.0
Hans-Joachim Widmaier wrote: Sorry for the german locale. The tar error is "This doesn't look like a tar archive", "Skipping to next header". It took me some time to figure out that the culprit was tar-1.15. I *think* this was a bug in tar-1.15. Upgrading to 1.15.1 should allow jdk-1.5.0 to install correctly - I didn't have any problems with that version anyway. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Strange tar error while building jdk-1.5.0
I stumbled upon this several weeks ago, but, being finally subscribed to the list, thought I'd share it anyway, as I didn't see it mentioned. This happened while building jdk-1.5.0: --- rm -f /usr/src/jdk-build/control/build/linux-i586/lib/i386/client/Xusage.txt cp /usr/src/jdk-build/control/build/linux-i586/hotspot-i586/client/Xusage.txt /usr/src/jdk-build/control/build/linux-i586/lib/i386/client/Xusage.txt rm -f /usr/src/jdk-build/control/build/linux-i586/lib/i386/libnative_chmod.so (gunzip < ../../tools/crypto/jgss/i586/native_chmod.tar.gz) | (cd /usr/src/jdk-build/control/build/linux-i586/lib/i386; tar xf -) tar: Das sieht nicht wie ein ,,tar"-Archiv aus. tar: Springe zum nächsten Kopfteil. tar: Read 6144 bytes from - tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler. make[4]: *** [/usr/src/jdk-build/control/build/linux-i586/lib/i386/libnative_chmod.so] Fehler 2 make[4]: Leaving directory `/usr/src/jdk-build/j2se/make/java/redist' make[3]: *** [optimized] Fehler 2 make[3]: Leaving directory `/usr/src/jdk-build/j2se/make/java/redist' make[2]: *** [all] Fehler 1 make[2]: Leaving directory `/usr/src/jdk-build/j2se/make/java' make[1]: *** [all] Fehler 1 make[1]: Leaving directory `/usr/src/jdk-build/j2se/make' make: *** [j2se-build] Fehler 2 savong:/usr/src/jdk-build/control/make$ gunzip < /usr/src/jdk-build/j2se/make/tools/crypto/jgss/i586/native_chmod.tar.gz | tar tvf - tar: Das sieht nicht wie ein ,,tar"-Archiv aus. tar: Springe zum nächsten Kopfteil. -rw-r--r-- seemam/green 39571 2003-02-23 06:43:00 libnative_chmod_g.so tar: Read 6144 bytes from - tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler. savong:/usr/src/jdk-build/control/make$ gunzip -t /usr/src/jdk-build/j2se/make/tools/crypto/jgss/i586/native_chmod.tar.gz savong:/usr/src/jdk-build/control/make$ tar tvf /usr/src/jdk-build/j2se/make/tools/crypto/jgss/i586/native_chmod.tar.gz -rw-r--r-- seemam/green 5511 2003-02-23 06:42:56 libnative_chmod.so -rw-r--r-- seemam/green 39571 2003-02-23 06:43:00 libnative_chmod_g.so savong:/usr/src/jdk-build/control/make$ tar xvf /usr/src/jdk-build/j2se/make/tools/crypto/jgss/i586/native_chmod.tar.gz libnative_chmod.so libnative_chmod_g.so --- Sorry for the german locale. The tar error is "This doesn't look like a tar archive", "Skipping to next header". It took me some time to figure out that the culprit was tar-1.15. When I replaced it with an old 1.13.whatever I found on an old lfs root partition, the build succeeded. In case it matters: My system is an "almost 6.0" BLFS (built shortly before the 6.0 release), kept mostly current with BLFS dev. This being my first posting, please don't be too angry if there's something wrong with it. ;-) -- Hans-Joachim Widmaier -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: jdk-1.5.0 mismatched quotes
El Miércoles, 11 de Mayo de 2005 10:02, Wiliam Harrington escribió:
>Found mismatched quotes in the jdk.sh line 17.
>
> CLASSPATH="${CLASSPATH}:.:${AUTO_CLASSPATH_DIR}
>
> change to
>
> CLASSPATH="${CLASSPATH}:.:${AUTO_CLASSPATH_DIR}"
Thanks, fixing it now.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com
TLDP-ES: http://es.tldp.org
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
jdk-1.5.0 mismatched quotes
Hello all,
Found mismatched quotes in the jdk.sh line 17.
CLASSPATH="${CLASSPATH}:.:${AUTO_CLASSPATH_DIR}
change to
CLASSPATH="${CLASSPATH}:.:${AUTO_CLASSPATH_DIR}"
user will notice errors when /etc/profile is sourced.
bash: /etc/profile.d/jdk.sh: line 22: unexpected EOF while looking for matching
`"'
bash: /etc/profile.d/jdk.sh: line 27: syntax error: unexpected end of file
William Harrington (Ratrophy)
1.21 Gigawatts?!?!?! Great scott!!
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: jdk-1.5.0
Robert Connolly wrote: > Hi. I get: > > /sources/sun_java/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o(.text+0xd7c): > > In function `.L93': > main.cpp: undefined reference to `gunzip::init(unpacker*)' > /sources/sun_java/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o(.text+0xd8e):main.cpp: > > undefined reference to `gunzip::start(int)' > collect2: ld returned 1 exit status > make[7]: *** > [/sources/sun_java/jdk-build/control/build/linux-i586/bin/unpack200] Error 1 > > from jdk-1.5.0. I'm using lfs-unstable. > > robert New one for me and I've built it 6 times in the past week. By any chance did you log the output? A little more of the text above could be helpful, like mabye the actual compiler command line if visible. -lz??? -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: jdk-1.5.0
Robert Connolly wrote these words on 04/26/05 14:41 CST: > On April 26, 2005 03:13 pm, Randy McMurchy wrote: > >>Because I'm not sure what lfs-unstable is now, could you tell us >>what version of GCC you're using. I've compiled the JDK-1.5.0 >>several times on 3 different x86 platforms using GCC-3.4.3 without >>any issues. > > gcc-3.4.3, glibc-2.3.5 Thanks for the info, Robert. However, I really don't have anything to help you out with other than to suggest that perhaps you overlooked removing some optimizations? I don't have a clue whether or not the newer Glibc has anything to do with it. Perhaps others have some better information for you. When you do get it figured out, please pass along what you had to do so that when we finish with BLFS-6.1, and target LFS-SVN, we'll know what we need to do. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 14:54:00 up 24 days, 14:27, 2 users, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: jdk-1.5.0
On April 26, 2005 03:13 pm, Randy McMurchy wrote: > Because I'm not sure what lfs-unstable is now, could you tell us > what version of GCC you're using. I've compiled the JDK-1.5.0 > several times on 3 different x86 platforms using GCC-3.4.3 without > any issues. gcc-3.4.3, glibc-2.3.5 robert -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: jdk-1.5.0
Robert Connolly wrote these words on 04/26/05 14:00 CST: > /sources/sun_java/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o(.text+0xd7c): > In function `.L93': > main.cpp: undefined reference to `gunzip::init(unpacker*)' > /sources/sun_java/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o(.text+0xd8e):main.cpp: > > undefined reference to `gunzip::start(int)' > collect2: ld returned 1 exit status > make[7]: *** > [/sources/sun_java/jdk-build/control/build/linux-i586/bin/unpack200] Error 1 > > from jdk-1.5.0. I'm using lfs-unstable. Because I'm not sure what lfs-unstable is now, could you tell us what version of GCC you're using. I've compiled the JDK-1.5.0 several times on 3 different x86 platforms using GCC-3.4.3 without any issues. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 14:11:01 up 24 days, 13:44, 2 users, load average: 0.10, 0.03, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
jdk-1.5.0
Hi. I get: /sources/sun_java/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o(.text+0xd7c): In function `.L93': main.cpp: undefined reference to `gunzip::init(unpacker*)' /sources/sun_java/jdk-build/control/build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o(.text+0xd8e):main.cpp: undefined reference to `gunzip::start(int)' collect2: ld returned 1 exit status make[7]: *** [/sources/sun_java/jdk-build/control/build/linux-i586/bin/unpack200] Error 1 from jdk-1.5.0. I'm using lfs-unstable. robert -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
DJ Lucas wrote:
> Bruce Dubbs wrote:
>
>
>>
>>3. It seems to be an interaction issue between KDE and OO that may well
>>show up with our build. I was just asking if someone else had seen it.
>
> So I did miss the point to some extent! ;-) To be honest I don't use
> KDE. I do have it installed, but can't start it ATM. I'll check my
> existing build in KDE before installing the new one and report back. A
> question though, what exactly are the symptoms? In the original message
> it started in 4 seconds, but something else was running correct? Is it
> just startup notification hanging around maybe? And what about top or
> ps or other system monitoring utils, any hints there? It'll be
> interesting to see if the problem still exists with the source build.
>
> Also, as previously mentioned, differences in the KDE environment and
> xterm environment? I'm not entirely well versed here as I don't use
> them, but I _think_ I remember reading or hearing something of
> differences between {G,K,X}DM's environment and term environment fairly
> recent. Beyond those, I can't think of any other ideas right now. If
> it's there after source build, then anything you can dig now up will
> certainly be helpful.
OK. This is getting too far off topic. I don't want to waste time
trying to solve what is essentially a non-blfs issue. It is a minor
thing. IF it shows up when I do the build, I'll bring it up again.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: JDK-1.5.0
Bruce Dubbs wrote:
>
>
> 3. It seems to be an interaction issue between KDE and OO that may well
> show up with our build. I was just asking if someone else had seen it.
So I did miss the point to some extent! ;-) To be honest I don't use
KDE. I do have it installed, but can't start it ATM. I'll check my
existing build in KDE before installing the new one and report back. A
question though, what exactly are the symptoms? In the original message
it started in 4 seconds, but something else was running correct? Is it
just startup notification hanging around maybe? And what about top or
ps or other system monitoring utils, any hints there? It'll be
interesting to see if the problem still exists with the source build.
Also, as previously mentioned, differences in the KDE environment and
xterm environment? I'm not entirely well versed here as I don't use
them, but I _think_ I remember reading or hearing something of
differences between {G,K,X}DM's environment and term environment fairly
recent. Beyond those, I can't think of any other ideas right now. If
it's there after source build, then anything you can dig now up will
certainly be helpful.
As far as jdk-1.5, if anyone wants to build that, look at the patches
project. Get all the patches in j2sdk/jdk-1.5.0* except the gcc one.
The good gcc patch is jdk/jdk-1.5.0_gcc-3.4.2+-2.patch. It builds by
the book instructions with the exception of the version number and make
line. According to the install docs, 'make scsl' builds motif first so
no need to do the three lines for motif, but they won't hurt either, I
still used them last time. I put up the fop patch locally so we don't
have the report till it goes into the book.
LFS.org/~dj/patches/fop_0.20.5-jdk_1.5.0-1.patch
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: JDK-1.5.0
Randy McMurchy wrote: > Bruce Dubbs wrote these words on 04/18/05 21:38 CST: > I'm not trying to be crusty, but really, Bruce, how does this fit > in? 1. DJ brought up OO in a comment. 2. I stated (well at least implied) that I was waiting for his updates to build Java and OO. 3. It seems to be an interaction issue between KDE and OO that may well show up with our build. I was just asking if someone else had seen it. 4. I did state that the issue ws minor. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
Archaic wrote these words on 04/18/05 22:52 CST: > Get off your high horse, Randy. He explicitly stated why he did it and > it did not involve avoiding the use of BLFS. If he needs the package for > use now before he has the chance to build it, who are you to judge him > for it? > > Just chill out, please. What is with you, Archaic? It's like you've been to a sensitivity class and need to put everyone in their place. Please, just mind your own business. I realize what I'm typing. I'm downright surprised that the BLFS Editor would come out on the development list and say that he didn't want to build one of the BLFS packages and used the precompiled version instead. [okay, just went and had a smoke, thought about things] I'm still convinced that Bruce should not have announced his problems with a precompiled version of a BLFS package without trying to at least build it first. I mean really, what does this say about our book, when the Editor doesn't even use it? -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 22:56:00 up 16 days, 22:29, 3 users, load average: 0.26, 0.24, 0.14 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
Archaic wrote these words on 04/18/05 22:37 CST: > On Mon, Apr 18, 2005 at 09:46:56PM -0500, Randy McMurchy wrote: >>I'm not trying to be crusty, but really, Bruce, how does this fit >>in? > > Because it may very well affect the compiled version as well. I see it > as trying to discern whether there may be a bigger problem that isn't > necessarily related to binary vs. source. No reason to dismiss the email > (and from the book editor and list moderator of all people). And was exactly why I was so surprised to see this message. I take offense to the Editor of the BLFS book coming onto the -dev list with problems he's having with a precompiled version of OpenOffice. It's as if our instructions aren't worthy of building. To me, it is advertisement to dismiss the BLFS instructions and install the precompiled version. This is, after all, BLFS. Those last two letters of the acronym being "From Scratch". Untarring a precompiled version of anything hardly qualifies. I suppose it just caught me off-guard that the Editor of the book, would come on to the -dev list with an issue concerning a precompiled version of something the book provides instructions on how to build from scratch. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 22:40:00 up 16 days, 22:13, 3 users, load average: 0.02, 0.06, 0.07 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
On Mon, Apr 18, 2005 at 09:46:56PM -0500, Randy McMurchy wrote: > > I'm not trying to be crusty, but really, Bruce, how does this fit > in? Because it may very well affect the compiled version as well. I see it as trying to discern whether there may be a bigger problem that isn't necessarily related to binary vs. source. No reason to dismiss the email (and from the book editor and list moderator of all people). -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
Bruce Dubbs wrote these words on 04/18/05 21:38 CST: > Speaking of OO, I have a minor issue. While waiting for your update, I > went ahead and installed a binary version. With all due respect, and with the utmost consideration for your issue, how does this fit into a -dev issue? Problems with a binary version of *anything* should probably go to -support. This thread is centered on getting BLFS to the JDK-1.5 version. Support issues on a binary version of Ooo doesn't seem to fit here. I'm not trying to be crusty, but really, Bruce, how does this fit in? -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 21:41:00 up 16 days, 21:14, 3 users, load average: 0.04, 0.04, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
DJ Lucas wrote: > So left is only OpenOffice, which had a few more enums, plus > the jurt fix I forgot about in my conglomeration patch that I made last > night. I deleted my original patches so I had to go find it again. > Anyway, it's compiling unohelper now so not much longer... Speaking of OO, I have a minor issue. While waiting for your update, I went ahead and installed a binary version. In KDE, I can create an icon and it starts in about 4 seconds. However, there is something else happening that indicates a second process is starting for about 30 seconds and then stops. This behavior does not occur when starting from an xterm. I've found that 30 second delays usually indicate a dns timeout, so I started ethereal and watched. There are no packets being sent from the system so that isn't it this time. Any ideas? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
Randy McMurchy wrote: > DJ Lucas wrote these words on 04/17/05 22:55 CST: > >>Okay guys, fop appears to be good now and blfs.pdf looks good. > > > I can confirm this. I had created a patch for FOP to fix the 'enum' > issue but the Graphics2D thing stopped me a long time ago. I never > got the urge to go back and figure out how to fix it. > > I used your patch instead, DJ, and FOP compiles just fine using the > JDK-1.5, and works as it should. > Awesome. So left is only OpenOffice, which had a few more enums, plus the jurt fix I forgot about in my conglomeration patch that I made last night. I deleted my original patches so I had to go find it again. Anyway, it's compiling unohelper now so not much longer... -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
Randy McMurchy wrote: > DJ Lucas wrote these words on 04/17/05 22:55 CST: > >>Okay guys, fop appears to be good now and blfs.pdf looks good. I'm >>reworking the OOo to install the large jdk-1.5 patch, and testing again. >> Also checking berkelydb now since I had no idea whether the problem >>still exists. Anyone have any additional objections that have not been >>discussed yet? > > > There is an entry in the JDK bug in Bugzilla about the JRE moz/firefox > plugin. Is this still an issue? > No...that was my screwup. I had inadvertantly left in a patch from 1.4.2 that had been fixed in a different way. The gcc-3.4.2+-2 patch eliminated that issue. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
DJ Lucas wrote these words on 04/17/05 22:55 CST: > Okay guys, fop appears to be good now and blfs.pdf looks good. I can confirm this. I had created a patch for FOP to fix the 'enum' issue but the Graphics2D thing stopped me a long time ago. I never got the urge to go back and figure out how to fix it. I used your patch instead, DJ, and FOP compiles just fine using the JDK-1.5, and works as it should. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 14:44:00 up 16 days, 14:17, 3 users, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
DJ Lucas wrote these words on 04/17/05 22:55 CST: > Okay guys, fop appears to be good now and blfs.pdf looks good. I'm > reworking the OOo to install the large jdk-1.5 patch, and testing again. > Also checking berkelydb now since I had no idea whether the problem > still exists. Anyone have any additional objections that have not been > discussed yet? There is an entry in the JDK bug in Bugzilla about the JRE moz/firefox plugin. Is this still an issue? -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 11:17:02 up 16 days, 10:50, 3 users, load average: 0.24, 0.14, 0.04 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: JDK-1.5.0
DJ Lucas wrote: > Also checking berkelydb now since I had no idea whether the problem > still exists. Just checking back, but no change necessary to db except that passing LIBSO_LIBS and LIBXSO_LIBS to make is no longer necessary. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
JDK-1.5.0
Okay guys, fop appears to be good now and blfs.pdf looks good. I'm reworking the OOo to install the large jdk-1.5 patch, and testing again. Also checking berkelydb now since I had no idea whether the problem still exists. Anyone have any additional objections that have not been discussed yet? If not, I will submit a text rundown and links to the necessary patches to this list no later than Wednesday evening (CST) for another round of tests by anyone who has a _lot_ of spare CPU time. :-) I'm really shooting for tomorrow evening, but I don't know if It'll be done yet...depends on whether I have things in as good of shape as I think I do (IOW, whether or not I caught all the enum changes in OOo since I don't want to use the -source parameter for javac). If anyone is interested in these changes before then for whatever reason, drop me a line and I'll give you what I have so far. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
OpenOffice-1.1.4 & JDK-1.5.0
Okay it works...and startup time is considerably faster, though I've changed some build options from what is in the book. Which brings me to a couple of quick questions. jdk-1.5.0: The sed works, with about 150 or so javac warnings. Thanks to Ximian's 64 bit build of OOo-1.1.4, there are jdk-1.5.0 patches availible. We need at least two patches from thier patchset either way, but one gigantic patch, or a much smaller patch with an added sed and lots of warnings from javac. Which is better? gpc vs libart: I can't see a good reason for gpc over libart. If somebody can point me to a discussion, that would be great, else I'm thinking libart since it's already in BLFS. STL-Port will be upgraded to 4.6.2 because of gcc-3.4 issues, and will be installed durring the OOo build. The installation requests a motif2.1's libmawt.so. This is installed with the jdk/jre but is not found in the library search path. Since it's needed at runtime, I'd immagine a symlink in /usr/lib in the jdk installation instructions would be appropriate, but I figured I'd ask if anyone has problems with this approach before it's done. I can't see any problems, but it seems that I've seen this lib many times before, but I can't place it and it was not in the usual places on my system. Comments are greatly appreciated. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
