Did you get your conflicts in configure and nsprpub\configure?
This is normal because we do our own autoconf.
Just delete them after the pull and rebuild.
Also, the nspr fixes for EMX should be in the build now.
Mike Kaply
IBM
"J. Robinson" wrote:
> On Sun, 22 Mar 3901 18:44:54, Ian Harvey <[EMAIL PROTECTED]>
> wrote:
>
> Well, thanks to both suggestions I've received so far (didn't really
> have much time to work on stuff until the weekend) I've gotten
> significantly further.
>
> As Henry pointed out (and much to my chagrin) I had the wrong version
> of pwd.exe, so this was certainly a big part of the problem right
> there. Yes, yes... I know there was a BOLD "New build instructions"
> on the ports page, but when messing with so many different tools in my
> config, I guess my record-keeping suffered a bit and I didn't get
> everything squared away appropriately.
>
> After replacing pwd.exe with the correct one, and then renaming the
> os/2 sort.exe to get it out of the way, I had a lot more success. I
> still had the makefile terminating during the work on nsprpub, so then
> tried Ian's suggestion of running autoconf to generate the makefile
> for there.
>
> Now, everything was up and running quite happily. Though,
> unfortunately, my first build was a titanic failure considering that I
> ran out of hard drive space about halfway through, which must've had
> something to do with not being able to write my os2.ini and loosing
> all the loose icons on my desktop! (@WHEE!)
>
> Anyways, everything else seems to be back together and working well,
> though now I run into the roadblock of having a CVS conflict when I
> try to do a 'pull_all'. Now, I s'pose it comes down to having to
> learn more about CVS. (Just to satisfy my curiosity, I even wiped my
> Mozilla directory, un-tarred the source again, and ran 'pull_all' on
> it, just to make certain I hadn't really junked something up).
>
> But at least I have the feeling I'm getting somewhere.
>
> Many thanks for the help so far.
>
> Jeff
>
> > Manually creating nsprpub/configure by running autoconf yourself (run it
> > under gbash) in the nsprpub directory before you start the build will
> > avoid the problem.
> >
> > Henry Sobotka wrote:
> > >
> > > The problem is coming from this line in configure:
> > >
> > > echo "running ${CONFIG_SHELL-/bin/sh} $ac_sub_configure
> > > $ac_sub_configure_args --cache-file=$ac_sub_cache_file
> > > --srcdir=$ac_sub_srcdir"
> > >
> > > For some reason $ac_sub_configure is being set to
> > > ./build/autoconf/configure instead of /MOZILLA/nsprpub/configure a few
> > > lines early by these blocks:
> > >
> > > case "$srcdir" in
> > > .) # No --srcdir option. We are building in place.
> > > ac_sub_srcdir=$srcdir ;;
> > > /* | [A-Za-z]:*) # Absolute path.
> > > ac_sub_srcdir=$srcdir/$ac_config_dir ;;
> > > *) # Relative path.
> > > ac_sub_srcdir=$ac_dots$srcdir/$ac_config_dir ;;
> > > esac
> > >
> > > # Check for guested configure; otherwise get Cygnus style configure.
> > > if test -f $ac_sub_srcdir/configure; then
> > > ac_sub_configure=$ac_sub_srcdir/configure
> > > elif test -f $ac_sub_srcdir/configure.in; then
> > > ac_sub_configure=$ac_configure
> > > else
> > > echo "configure: warning: no configuration information is in
> > > $ac_config_dir" 1>&2
> > > ac_sub_configure=
> > > fi
> > >
> > > It looks like you're falling into the ac_sub_configure=$ac_configure
> > > block because near the top of configure you'll find:
> > >
> > > ac_configure=$ac_aux_dir/configure # This should be Cygnus configure.
> > >
> > > $ac_aux_dir is build/autoconf.
> > >
> > > A few things you might try:
> > > - setting MOZ_OBJDIR to the subdirectory in which you're building
> > > (assuming you're building in an objdir; if not, try creating a
> > > subdirectory off mozilla, cd into it and run ../configure [options] from
> > > there);
> > > - setting SHELL=gbash;
> > > - making sure the first pwd in your path is the one whose output
> > > includes the driveletter.
> > >
> > > autoconf'd nsprpub builds are new territory for emx so problems are to
> > > be expected.
> > >
> > > The confdefs.h failure appears to be the result of your having
> > > os2\sort.exe first in your path.
> > >
> > > h~
>
> ----------------
> Whatza JamochaMUD? http://jamochamud.anecho.mb.ca
> Or other stuff: http://www.anecho.mb.ca/~jeffnik
