Problems building extensions/java/xpcom

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems building extensions/java/xpcom

Eric Swenson-2
I pulled the mozilla tree from cvs and attempted to build it using the
following .mozconfig under cygwin:

. $topsrcdir/xulrunner/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/compiled

The build failed trying to build
extensions/java/xpcom/nsAppFileLocProviderProxy.cpp because the header
file nsJavaXPTCStubWeakRef.h uses the type "jweak" and there appears to
be no header file in the include path that defines this type.

Now, the latest several versions of jni.h from Sun's J2SE SDKs do define
a typedef for "jweak". However, this definition is not in the
dist/include/java/jni.h (nor in most of the other instances of jni.h in
the mozilla source tree -- it turns out there is one version of jni that
defines jweak, but it is not in the include path when builidng this file
but is in the plugin/oji/MRJCarbon/MRJSDK/JavaFrameworks/JavaVM/jni.h
version).

The problem turned out to be that while I had a $JAVA_HOME environment
variable pointing that the latest version of the 1.4 Sun JDk
(c:\j2sdk1.4.2_11), the code in configure uses cygpath -u `cygpath -m -s
"$JAVA_HOME"` to turn this into a unix-style path. However, and here's
the bug, if you have c: mounted as /c (as I do), cygpath -u will turn
the path into something that looks like /c/J2SDK~1.2_1, rather than a
path with a /cygdrive/c prefix. The cygwing command line wrapper
(mozilla/build/cygwin-wrapper) will not map this path syntax into a
pathname that VC++ will accept, but instead leaves it as /c/J2SDK~1.2_1.
cl will ignore this invalid path. Consequently, the version of jni.h in
dist/include/java will be found. This is an old version that doesn't
define the jweak type.

I was able to get around the problem by doing an "unmount /c", but the
build instructions should be updated to include a discussion of this. It
should probably give a test command line that should be executed by
cygwin users to make sure that cygpath -u will use the /cygdrive/ prefix
rather than any custom users mounts (which cygwin-wrapper won't know
about). While there is already a discussion of the need to use /cygdrive
paths, this is a hidden side effect that will likely be missed (it was
by me, and I'm a seasoned cygwin/unix/windows user).
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Problems building extensions/java/xpcom

Benjamin Smedberg
Eric Swenson wrote:

> I was able to get around the problem by doing an "unmount /c", but the
> build instructions should be updated to include a discussion of this. It
> should probably give a test command line that should be executed by
> cygwin users to make sure that cygpath -u will use the /cygdrive/ prefix
> rather than any custom users mounts (which cygwin-wrapper won't know
> about). While there is already a discussion of the need to use /cygdrive
> paths, this is a hidden side effect that will likely be missed (it was
> by me, and I'm a seasoned cygwin/unix/windows user).

Write it! though I maintain the build docs, the content is for the most part
provided by the community.

--BDS
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Problems building extensions/java/xpcom

Chris Seawood
In reply to this post by Eric Swenson-2
Eric Swenson wrote:

> The problem turned out to be that while I had a $JAVA_HOME environment
> variable pointing that the latest version of the 1.4 Sun JDk
> (c:\j2sdk1.4.2_11), the code in configure uses cygpath -u `cygpath -m -s
> "$JAVA_HOME"` to turn this into a unix-style path. However, and here's
> the bug, if you have c: mounted as /c (as I do), cygpath -u will turn
> the path into something that looks like /c/J2SDK~1.2_1, rather than a
> path with a /cygdrive/c prefix. The cygwing command line wrapper
> (mozilla/build/cygwin-wrapper) will not map this path syntax into a
> pathname that VC++ will accept, but instead leaves it as /c/J2SDK~1.2_1.
> cl will ignore this invalid path. Consequently, the version of jni.h in
> dist/include/java will be found. This is an old version that doesn't
> define the jweak type.
>
> I was able to get around the problem by doing an "unmount /c", but the
> build instructions should be updated to include a discussion of this. It
> should probably give a test command line that should be executed by
> cygwin users to make sure that cygpath -u will use the /cygdrive/ prefix
> rather than any custom users mounts (which cygwin-wrapper won't know
> about). While there is already a discussion of the need to use /cygdrive
> paths, this is a hidden side effect that will likely be missed (it was
> by me, and I'm a seasoned cygwin/unix/windows user).

IIRC, it's already documented that we do not support using random
non-standard mount points.  However, we do support changing the default
cygmount prefix so there should be nothing that specifically requires
/cygdrive to be used.  If you changed your cygmount prefix to /, then
you would get the same effect as mounting /c and that should just work.
 If not, please file a bug.

- cls
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Problems building extensions/java/xpcom

Eric Swenson-2
Christopher Seawood wrote:
> IIRC, it's already documented that we do not support using random
> non-standard mount points.  However, we do support changing the default
> cygmount prefix so there should be nothing that specifically requires
> /cygdrive to be used.  If you changed your cygmount prefix to /, then
> you would get the same effect as mounting /c and that should just work.
>  If not, please file a bug.

I guessed I missed where it said that we don't support standard mount
points.  I recall that it said that one had to use /cygdrive/xxx when
specifying the top source directory (i.e. you had to cd to a
/cygdrive/xxx directory before building), but I didn't realize that it
also said that one couldn't have other mount points.  I think that is a
bit onerous of a restriction because it means breaking the rest of the
environment (there could be lots of dependencies of mount points in
other applications/environments that are being used on the machine).  In
my case, I simply did a "umount /c" and got things working, however, all
the rest of my paths/environment variables/scripts that depended on the
/c mount point now were broken.

I think we could write a smarter version of cygwin-wrapper that looks at
all the mount points in effect and postprocesses the output of `cygwin
-u xxx` to see which ones did NOT resolve to /cygdrive/xxx paths and
then see if these did resolve to a non-standard mount point.  In this
case, the mount table could be consulted to turn these into
/cygdrive/xxx paths (and the normal processing of these in
cygwin-wrapper could then proceed).

If I get a chance I'll try doing this.

Also, your suggestion to use the / prefix rather than /cygdrive, while
it would work in this case, is NOT recommended by the cygwin folks and
results in the "polluting" of the cygwin-visible root file system (with
all the cruft that Windows ends up having in the root directory of
drives).

But thanks for your suggestions -- I'll see if I can come up with a
better solution and will post it.

-- Eric
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Problems building extensions/java/xpcom

Chris Seawood
Eric Swenson wrote:

> Christopher Seawood wrote:
>> IIRC, it's already documented that we do not support using random
>> non-standard mount points.  However, we do support changing the default
>> cygmount prefix so there should be nothing that specifically requires
>> /cygdrive to be used.  If you changed your cygmount prefix to /, then
>> you would get the same effect as mounting /c and that should just work.
>>  If not, please file a bug.
>
> I guessed I missed where it said that we don't support standard mount
> points.  I recall that it said that one had to use /cygdrive/xxx when
> specifying the top source directory (i.e. you had to cd to a
> /cygdrive/xxx directory before building), but I didn't realize that it
> also said that one couldn't have other mount points.  I think that is a
> bit onerous of a restriction because it means breaking the rest of the
> environment (there could be lots of dependencies of mount points in
> other applications/environments that are being used on the machine).  In
> my case, I simply did a "umount /c" and got things working, however, all
> the rest of my paths/environment variables/scripts that depended on the
> /c mount point now were broken.
>
> I think we could write a smarter version of cygwin-wrapper that looks at
> all the mount points in effect and postprocesses the output of `cygwin
> -u xxx` to see which ones did NOT resolve to /cygdrive/xxx paths and
> then see if these did resolve to a non-standard mount point.  In this
> case, the mount table could be consulted to turn these into
> /cygdrive/xxx paths (and the normal processing of these in
> cygwin-wrapper could then proceed).
>
> If I get a chance I'll try doing this.
>
> Also, your suggestion to use the / prefix rather than /cygdrive, while
> it would work in this case, is NOT recommended by the cygwin folks and
> results in the "polluting" of the cygwin-visible root file system (with
> all the cruft that Windows ends up having in the root directory of drives).
>
> But thanks for your suggestions -- I'll see if I can come up with a
> better solution and will post it.

Wrt non-standard mount points, see bug 158920.  The win32 build pages
have been rewritten so many times by so many different people because
they're always wrong in some fashion.  This time is no exception.

Having other mount points isn't a problem as long as you aren't building
on or from them.

Unfortunately, all of that extra processing to find all mount points is
sure to slow down the execution of cygwin-wrapper, which is run at least
once for each source file in the tree.  Bug 206643 was all about
speeding up cygwin-wrapper.

I'm suggesting using / as the prefix, not the mount point.  You still
need to use the drive letter to access the tree outside of the cygwin
root.  So c:\autoexec.bat is still /c/autoexec.bat , not /autoexec.bat.
 /c doesn't show up in the cygwin root dir any more than /cygdrive/c
would.  We've been using this for years and have never seen any pollution.

- cls
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|

Re: Problems building extensions/java/xpcom

Eric Swenson-2
Christopher Seawood wrote:

> Unfortunately, all of that extra processing to find all mount points is
> sure to slow down the execution of cygwin-wrapper, which is run at least
> once for each source file in the tree.  Bug 206643 was all about
> speeding up cygwin-wrapper.
>
> I'm suggesting using / as the prefix, not the mount point.  You still
> need to use the drive letter to access the tree outside of the cygwin
> root.  So c:\autoexec.bat is still /c/autoexec.bat , not /autoexec.bat.
>  /c doesn't show up in the cygwin root dir any more than /cygdrive/c
> would.  We've been using this for years and have never seen any pollution.
>
> - cls

Thanks much, Christopher.  I understand now.  I'll give it a try.

-- Eric
_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds