WINDOWS_NATIVE_COMPILE_ENVIRONMENT is wrong with 32-bit cygwin

Robin & Di Hayman robinndi at aol.com
Thu Jan 8 03:10:42 UTC 2015


I am trying to build JavaFX with native media enabled.  For background, 
read *The initial problem* below.  I run gradle in a mintty window.

So I am stuck in build.gradle ( line 2392 for me)  in def buildGlib{ 
.... I have progressed somewhat since the initial problem and understand 
the problem but not the root cause.  I have put a few (Java) debugging 
lines using the code below and summarised the result here.

Findings:
This is just a path problem.
I have 32-bit cygwin installed and the DOS path is correct .

/        Initial DOS path==========
         C:\cygwin\usr\local\bin;   C:\cygwin\bin; 
C:\ProgramData\Oracle\Java\javapath;   C:\Tcl\bin;/ etc

*WINDOWS_NATIVE_COMPILE_ENVIRONMENT is wrong:*

/        WINDOWS_NATIVE_COMPILE_ENVIRONMENT=======[ ...., PATH:; .
         ...;C:/Program 
Files/TortoiseHg/;C:/MinGW/msys/1.0/bin;C:/MinGW/bin;
e:/robins_root/Gradle/gradle-1.8-all/gradle-1.8/bin;C:/cygwin64/bin; 
,INCLUDE .../

As a result      make $(shell cygpath ...  can't work!

To help me understand the problem, my code below creates a /newEnv 
/which /make /uses to buildGlib without error ( although 
buildWinGStreamer still fails since I only fixed the local environment 
for buildGlib not the global WINDOWS_NATIVE_COMPILE_ENVIRONMENT.
I have tried to find which code is turning /C:\cygwin\bin /into 
/C:/cygwin64/bin/ but so far I have not seen where this is done.  I have 
looked in build.gradle & buildSrc\win.gradle and did not see anything there.

I also tried installing cygwin-64.  But then I got errors where mintty 
was looking for bash in c:\cygwin when it was in c:cygwin64!

Then I tried loading Red Hat cygwin-32 using installer 2.844.  It copied 
all the files into c:\rhcygwin , the installer then created a desktop 
shortcut pointing to c:\rhcygwin\mintty. As soon as I clicked it I got 
an error saying Can't find c:\cygwin\bash.exe! So I renamed the folder 
to cygwin!

A can of 32-bit & 64-bit worms.


Who is taking c:\cygwin and turning into c:\cygwin64?  There is no such 
folder.

  Thanks

robinH

P.S.
It would be helpful if the page Building OpenJFX 
<https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX> was 
more specific about the versions of /Cygwin /& /make /which should be 
used as it is quite specific for most of the other tools. /Cygwin/make/ 
has been making changes in how they deal with DOS paths so perhaps they 
broke something. Perhaps something on tools 64 vs 32 too.

-------------------------------------------- code 
---------------------------------------------------
in def buildGlib{ , thus
                def buildGlib = task("build${t.capital}Glib", dependsOn: 
[buildResources]) {
                     enabled = IS_COMPILE_MEDIA
             //RBH
             System.out.println( "\n\nInitial DOS path=======" + 
System.getenv().get("PATH")  )
             System.out.println( 
"\n\nWINDOWS_NATIVE_COMPILE_ENVIRONMENT====="
                                  + WINDOWS_NATIVE_COMPILE_ENVIRONMENT  )
             Map newEnv = new HashMap(WINDOWS_NATIVE_COMPILE_ENVIRONMENT)
             thePath =  newEnv["PATH"]
             thePath = thePath.replace("cygwin64","cygwin")
             newEnv["PATH"] = thePath
               System.out.println( "\n\nnewEnv=================" + newEnv )
                     doLast {
                         exec {
//environment(WINDOWS_NATIVE_COMPILE_ENVIRONMENT)
                             environment(newEnv)
                             commandLine ("make", "${makeJobsFlag}", 
"-C", "${nativeSrcDir}/gstreamer/projects/${projectDir}/glib-lite")
                             args("OUTPUT_DIR=${nativeOutputDir}", 
"BUILD_TYPE=${buildType}", "BASE_NAME=glib-lite",
                                  IS_64 ? "ARCH=x64" : "ARCH=x32", 
"RESOURCE=${nativeOutputDir}/${buildType}/${WIN.media.glibRcFile}")
                         }
                     }
                 }
----------------------------------------------



------------------------------------------------- The initial problem 
-------------------------------------------------------------------------

I find JFX media HLS is not working well for me. It dies after about 30s 
whereas VLC can pick up the 'dead' m3u8 and continue playing fine, so I 
decided to build from source to try to see what is going on.  I have 
followed Michael Berry's efforts extending media codecs too. Also,  I 
found this 
<https://coaxion.net/blog/2014/05/http-adaptive-streaming-with-gstreamer/>(November 
26, 2014 at 15:04 
<https://coaxion.net/blog/2014/05/http-adaptive-streaming-with-gstreamer/comment-page-1/#comment-28467>) 
comment interesting in response to the question "Is there any support on 
gstreamer 0.10 for Adaptive Streaming – Smooth Streaming, Dash etc. ?" . 
'Slomo' replied /"There is some initial support for HLS but don’t use 
0.10 for anything really. It’s no longer maintained since more than 2 
years and a lot has happened since then"/. The rest of his blog ('*HTTP 
Adaptive Streaming with GStreamer*') seemed to indicate he had some 
knowledge in this area.  So I decided to build from source to see more 
of what is going on.

I chose to build 8u-dev/rt from Hg, although that may not have been the 
best choice.
The initial build went fine (without native).  It was */easy/*. 
Congratulations!

Then I made a gradle.properties and set COMPILE_MEDIA = true and got 
errors.  These are in of build.gradle ( line 2392 for me)  in def 
buildGlib{ ....
This exec's the makefile in 
E:\robins_root\software\JavaFX\modules\media\src\main\native\gstreamer\projects\win\glib-lite.
The errors look like:
/bin/sh: cygpath: command not found
/    Makefile:71: recipe for target '/libglib-2.28.8.lib' failed/ /( I 
have messed up the line numbers ignore 71)/
And make returns 2 and error 127.  Now from the cywin window, I can do

/Robin at MY-PC /cygdrive/e/robins_root/software/JavaFX//
//$ cygpath --help//
//cygpath --help//
//Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME.../
etc
and also
/$ echo $SHELL//
//echo $SHELL//
//C:\cygwin\bin\bash.exe/
and echo path starts off
/usr/local/bin:
/usr/bin:
/cygdrive/c/ProgramData/Oracle/Java/javapath:
/cygdrive/c/Tcl/bin:
/cygdrive/c/Windows/system32:
/cygdrive/c/Windows:
...
If I manually run the makefile from its folder, fixing up any needed  
variables, it seemed to run OK.  ( Although my VS2010 was initially 
damaged. I had to set up the INCLUDE environment variable since I was 
getting windows.h not found.  I think this is caused somehow by having 
VS2010, VS2011 & VS2012 originally, then removing all three and doing a 
clean install of VS2010. I googled reports of others having this problem 
of corrupted include path.)

My installation is unusual (?) in that all my JFX builder folders are on 
e: whereas Cywgin is on c:  .  I need to use both paths /cygdrive/e/ 
and  /cygdrive/c/.

The detailed build instructions are detailed about versions for most 
programs, but not for cygwin & make. I wonder which version you use in 
your builds?

Does Gradle change the SHELL variable?  Does Gradle/cygwin/make assume 
all programs are on say a C: drive?  mintty has no problem finding 
cygpath.  Is Gradle looking for cygpath on e: instead of c:?

Now I have been playing with PATH & SHELL but nothing I do seems to help.

Any suggestions?

---------------------------------------------------------------------------
I am using:
Gradle 1.8   Build time: 2013-09-24 07:32:33 UTC  Revision: 
7970ec3503b4f5767ee1c1c69f8b4186c4763e3d  Groovy:1.8.6
Ant:          Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy:          2.2.0
JVM:          1.8.0_05 (Oracle Corporation 25.5-b02)
OS:           Windows 8.1 6.3 x86
$uname -a   CYGWIN_NT-6.3-WOW64 ROBIN-PC 1.7.33-2(0.280/5/3) 2014-11-13 
15:45 i686 Cygwin
make -v   GNU Make 4.0  Built for i686-pc-cygwin
cygwin install, version 2.859
I used CygWin setup-x86.exe so I presume this is 32-bit Cygwin
JAVA_HOME points to (X86) jdk1.8.0.05
JRE_HOME  (X86) jre8
My machine also has 64-bit jdk1.8.0_25 & jdk1.8.0_05in Program Files


More information about the openjfx-dev mailing list