OOo, Xorg7.0 etc etc etc

Alan Lord wrote:

> 
> This was from a different message - not from me! I have
only installed 
> the JDK _06 binary.

Actually, I was replying to both messages at once. 
> 
> I do think that my attempts at building OOo were
*nearly* successful as 
> the build directory grew to about 3Gb during the
process and, like I 
> said, took about 4-5 hours to get there. My host is a
(quite old) 2.6Ghz 
> P4 (400Mhz FSB) with 256M RAMBUS RAM and 512M of swap.

Well, I was successful with jdk-1.5.0_05 build from source
and OOo 
build.  Unfortunately, the configure check is broken for BDB
in 
OOo-2.0.1, so I used the internal version without the db4.4
patch. 
Configure couldn't determine the version string, but I
don't imagine 
that'll be difficult to fix.  For patching, I used the
patches that had 
not been applied upstream from the original blfs patchset,
and then two 
additional jdk-1.5 changes.  I don't know how the xalan
stuff got back 
into xmlhelp, but it hasn't been needed for a while, so
just remove the 
imports there...and then also xmlhelp, three enums (changed
to 
uenum...doesn't really matter what you call them).

This was on slightly modified udev_update branch with
en_US-UTF8 and 
Xorg-6.9.0.  Had the minimum requirements for OOo with added
python, 
startup-notification, and cups.  I'm restoring my clean
system now to 
start on Xorg-7.0.  Just FYI, I'd have to review the
previous thread, 
but I believe the book will be moving the installation
directory default 
for Xorg-7.0.

Actually, Bruce, what was decided?  I can't find the thread
where we had 
discussed this before.  /usr/X11 as the default with /usr as
the option, 
similar to the way it is now.  :-/  I prefer the /usr method
as default 
now for the book as that is what the distros seem to be
doing...less 
chance for breakage that way later on down the road (but
I'll use a 
separate installation path for myself).  In either case,
both Xorg-6.9 
and 7.0 must be updated to account for this...(luit's
parser.h has a 
hardcoded reference to /usr/X11R6 as mentioned previously by
Alexander, 
and mesa code has 'em all over the place, the reason for
the blind, 
recursive sed in the mesa instructions in my homedir).

> 
> The last failures were something to do with
dictionaries or language 
> features I seem to recall, even though in my last
attempts I had removed 
> all "foreign" switches (UK lang and dict
options).
> 
> Hope this might help...
> 

It'll give me something to look at.  I had intended to give
the 
alternate provided languages/locales? some better coverage
anyway.

> Alan
> 
> PS - Glad your son is better. I hate it when my kids
get ill - nothing 
> worse in the world for making you worry!
> 

Thank you.  He's back to himself now....driving me nuts
with 'why?' as 
is the norm for a 3yo I'm told. 

-- DJ Lucas
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

DJ Lucas wrote:
> Alan Lord wrote:
> 
>>
>> This was from a different message - not from me! I
have only installed 
>> the JDK _06 binary.
> 
> 
> Actually, I was replying to both messages at once. 
> 
>>
>> I do think that my attempts at building OOo were
*nearly* successful 
>> as the build directory grew to about 3Gb during the
process and, like 
>> I said, took about 4-5 hours to get there. My host
is a (quite old) 
>> 2.6Ghz P4 (400Mhz FSB) with 256M RAMBUS RAM and
512M of swap.
> 
> 
> Well, I was successful with jdk-1.5.0_05 build from
source and OOo 
> build.  Unfortunately, the configure check is broken
for BDB in 
> OOo-2.0.1, so I used the internal version without the
db4.4 patch. 
> Configure couldn't determine the version string, but I
don't imagine 
> that'll be difficult to fix.  For patching, I used the
patches that had 
> not been applied upstream from the original blfs
patchset, and then two 
> additional jdk-1.5 changes.  I don't know how the
xalan stuff got back 
> into xmlhelp, but it hasn't been needed for a while,
so just remove the 
> imports there...and then also xmlhelp, three enums
(changed to 
> uenum...doesn't really matter what you call them).
> 
> This was on slightly modified udev_update branch with
en_US-UTF8 and 
> Xorg-6.9.0.  Had the minimum requirements for OOo with
added python, 
> startup-notification, and cups.  I'm restoring my
clean system now to 
> start on Xorg-7.0.  

Whoops.  I forgot to mention Firefox and system nspr/nss.  I
did have to 
symlink the include dirs for nspr and nss into the firefox
include dir 
with the current xmlsec-nomoz patch.  I'm not suggesting
that, or 
anything similar for the book.  I'll be changing the
configure check to 
use pkg-config variables, shortly after I work out an xorg7
build. 
It'll be interesting, however, to see if any other packages
that use 
nspr will make assumptions like that about where to find the
headers. 
Randy, I haven't caught up on -book yet, just marked
everything read. 
Have you already fixed anything like that already?

-- DJ Lucas
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

DJ Lucas wrote:
> /usr/X11 as the default with /usr as the option, 
> similar to the way it is now.  :-/  I prefer the /usr
method as default 
> now for the book as that is what the distros seem to be
doing...less 
> chance for breakage that way later on down the road

+1 for /usr please

Andy
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

DJ Lucas wrote:
> Well, I was successful with jdk-1.5.0_05 build from
source and OOo 
> build.  Unfortunately, the configure check is broken
for BDB in 
> OOo-2.0.1, so I used the internal version without the
db4.4 patch. 
> Configure couldn't determine the version string, but I
don't imagine 
> that'll be difficult to fix.  For patching, I used the
patches that 
> had not been applied upstream from the original blfs
patchset, and 
> then two additional jdk-1.5 changes.  I don't know how
the xalan stuff 
> got back into xmlhelp, but it hasn't been needed for a
while, so just 
> remove the imports there...and then also xmlhelp, three
enums (changed 
> to uenum...doesn't really matter what you call them).
DJ, do you have the time to be a little more specific?  I'm
completely 
in the dark about what you said here.  I'd like to try that
jdk build again.
>
> He's back to himself now....driving me nuts with
'why?' as is the norm 
> for a 3yo I'm told. 
>
Speaking from experience, those who are advising you are
right.  Just a 
preview of things to come.  My oldest was 3 twenty-nine
years ago, and 
she hasn't changed.   However,
she does have her own three-year-old 
now.  Sweet revenge.   

Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Dan McGhee wrote:

> DJ, do you have the time to be a little more specific? 
I'm completely 
> in the dark about what you said here.  I'd like to try
that jdk build 
> again.

Yes, but not yet.  The previous was against 6.9 in
/usr/X11R6.  I've not 
completed the build against 7.0.  I fell asleep at my desk
last night 
around 0400 in the middle of a /usr build of xorg7. 
Fortunately, in 
exchange for sleep, I'm being 'given' computer time by my
wife.  

Anyway, I'm installing the prereqs for JDK now.  Will
report back as 
soon as it's done (2.5 hours?)....and same with OOo.  Will
put up the 
new OOo patches up this afternoon/evening after testing them
with an 
unpolluted source tree.

These OOo patches do not yet include using system installed
db-4.4.  I 
haven't looked at it yet, but I'm hoping that the OOo
configure is basic 
autotooled, so we can just regenerate configure and have it
fixed with 
automagic.

-- DJ Lucas

On a side note, I fully intend to return to a /usr/X11 build
as well 
since this was the optional install target decided upon, but
fixes (if 
you call them that) so far have been limited to a blind,
recursive sed.

find ./ -type f -exec sed -i 's/usr/X11R6/usr/X11g'

I hope I typed that correct...I never use that syntax in
favor of a 
for,in,do loop.
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

DJ Lucas wrote:

> This was on slightly modified udev_update branch with
en_US-UTF8 and
> Xorg-6.9.0.  Had the minimum requirements for OOo with
added python,
> startup-notification, and cups.  I'm restoring my
clean system now to
> start on Xorg-7.0.  Just FYI, I'd have to review the
previous thread,
> but I believe the book will be moving the installation
directory default
> for Xorg-7.0.
> 
> Actually, Bruce, what was decided?  I can't find the
thread where we had
> discussed this before.  /usr/X11 as the default with
/usr as the option,
> similar to the way it is now.  :-/  I prefer the /usr
method as default
> now for the book as that is what the distros seem to be
doing...less
> chance for breakage that way later on down the road
(but I'll use a
> separate installation path for myself).  In either
case, both Xorg-6.9
> and 7.0 must be updated to account for this...(luit's
parser.h has a
> hardcoded reference to /usr/X11R6 as mentioned
previously by Alexander,
> and mesa code has 'em all over the place, the reason
for the blind,
> recursive sed in the mesa instructions in my homedir).

We didn't finalize a decision, but I'm leaning towards
/usr as the
default with an explanation on how (and why a user might
want) to put it
into another directory.

  -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Dan McGhee wrote:
> DJ, do you have the time to be a little more specific? 
I'm completely 
> in the dark about what you said here.  I'd like to try
that jdk build 
> again.
> 

I received the same error as your previous message Dan. 
Just removing 
XmImGetXIC from motif21.c will work, though I've not tested
that, but 
I've got to figure out why 'NeedWidePrototypes' differs
from using 6.9.0 
and 7.0.0 Xorg headers.  I think all previous builds of
Xorg7 might be 
slightly crippled.  What is happening is an if case in
XmIm.h for the 
type 'input_policy'.  In my 6.9 build, the error you had
seen the other 
day did not crop up as the types were both unsigned int (IOW

NeedWidePrototypes was defined).  With xorg-7 installed,
it's going to 
whatever XmInputPolicy is.

Defaulting to uint32_t should be okay globally...but I
don't know why 
it's not happening like that with our Xorg-7 installation. 
Find 
XmImGetXIC in both files side by side to get a better
understanding of 
the immediate problem.  Basically when building xproto, I
_think_ that 
we need to explicitly add --enable-wide-prototypes to the
configure 
line.  It is supposed to be autodetected by configure, but
configure 
defaults to 'no' for linux when auto is selected...which
differs from 
6.9's build...so now I'm off to find that in 6.9's cf
files.

Also, with X in /usr only, I've used the recursive find and
sed to get 
to a completed build first...now I can track down the xorg
prefix issues 
better.  Immediately, I know of only two so far, where the
change is 
needed so that the build system can find xmkmf, makedepend,
and imake 
(pretty much need all the utils to be installed in xorg7). 
They are 6 
instances each in motif/lib/Xm/Makefile and
motif/lib/Xm/util/Makefile. 
  Otherwise, I believe the strait /usr prefix will be safe
with JDK.  I 
will know for sure as soon as I track down why that define
is made in 
6.9.  And possibly rebuild X of course as the define is not
limited to 
the motif libs.  I'm not sure what else, after X, uses that
define 
either...may not be quite as big a deal as it seems right
now.  More to 
come.

-- DJ Lucas
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Bruce Dubbs wrote:

> 
> We didn't finalize a decision, but I'm leaning
towards /usr as the
> default with an explanation on how (and why a user
might want) to put it
> into another directory.
> 
>   -- Bruce

Having done the /usr build now, I think that it is best for
the default 
going forward.  It will cause only minor headaches using
/usr as opposed 
to /usr/X11R6. OTOH, anything but those two makes bigger
headaches, but 
nothing that a compatibilty symlink can't fix if the needed
configure 
switches aren't there (book only...devs and power users are
expected to 
suffer and fix upstream if we choose a standardised format
like the 
/usr/X11 prefix that sun will be using).  So can we call
this the 
_final_ decision on the matter until next time? 

-- DJ Lucas
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

DJ Lucas wrote:

> Basically when building xproto, I _think_ that 
> we need to explicitly add --enable-wide-prototypes to
the configure 
> line.  It is supposed to be autodetected by configure,
but configure 
> defaults to 'no' for linux when auto is
selected...which differs from 
> 6.9's build...so now I'm off to find that in 6.9's
cf files.

config/cf/Imake.tmpl says yes if it's not defined in the
monlithic tree, 
but linux.cf overrides it....that's strange.  I don't
understand why 
this isn't the default.  From this thread:
http://lists.freedesktop.org/archives/xorg/2
004-December/004970.html 
Keith Packard says imake correctly sets to no...and this is
the 
behaviour seen now.

But only imake handled this correctly before now.  However,
if the 6.9 
and 7.0 code is the same, then why are they interpreted 
incorrectly?!?!?!  After reading the thread, I think all is
well with 
our Xorg-7.0 build.  Unfortunately, that thread is all I
have been able 
to find on the issue.  I'll fix JDK the correct way and
we'll see if it 
bites us back later on, though I doubt it will.  At least
the difference 
is explained.

Dan, if you still have the old failed build tree around,
then just nix 
XmImGetXIC from motif21.c, and rerun make.  The build should
complete 
shortly.

-- DJ Lucas
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

DJ Lucas wrote:
> Dan, if you still have the old failed build tree
around, then just nix 
> XmImGetXIC from motif21.c, and rerun make.  The build
should complete 
> shortly.
Thanks for the info and the work, DJ.  I'll have to start
from scratch 
on the build and won't get to it until tonight or tomorrow.
 I'll post 
the results.

Thanks again.

Dan

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://
www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page