title: Launching CYGWIN-built executable from Java on Windows 7 fails with "error while loading shared libraries: ?: No such file or directory"
body: <p>The code in question has worked in more or less the exact same configuration on earlier releases of Windows, however, it is not known to have run on Windows 7 YET! That's what I need to solve now.</p>
  
  <p>Briefly, some C code performs some configuration and security checks before launching a java program, passing some data that would be neigh-into-impossible to do easily in Java. The Java in turn, at the appropriate time launches the same C code which then itself launches a different Java program. The second program launch needs to be completely independent, (think nohup) hence the second launch. </p>
  
  <p>What's happening now is that the C program launches the Java program in the ordinary way, but when the Java tries to launch the C program, it errors out like this:</p>
  
  <blockquote>
    <p>/cygdrive/c/opt/ST/v3.3/bin/ST.exe: error while loading shared
    libraries: ?: cannot open shared object file: No such file or
    directory</p>
  </blockquote>
  
  <p>Because Windows has been such a bear over the years, the C code is written in the posix environment of Cygwin, but all it really does is ordinary C types of things (nothing about it is unique to Cygwin and, indeed, in the past it has been built with Microsoft's development tools, but that environ is not available at present). The Cygwin environ adds a lot of other great benefits, like command-line management of services (cygrunsrv) and a full-on 'nix-like environment (bash, etc). In fact, because Windows has changed how one launches a program from Java so many times, Cygwin helps standardize the Java launch code. Here's an excerpt:</p>
  
  <pre><code>  if (ClientOS.indexOf("Windows") != -1)
    {
       if (ClientOS.equals("Windows 95"))
       {
          cmd = "command.com /C ";
       } else if (ClientOS.equals("Windows 98"))
       {
          cmd = "command.com /C ";
          //cmd = "cmd.exe /C ";
       } else if (ClientOS.equals("Windows NT"))
       {
          cmd = "cmd.exe /C ";
       } else if (ClientOS.equals("Windows 2000"))
       {
          cmd = "cmd.exe /C ";
       } else if (ClientOS.equals("Windows XP"))
       {
          cmd = "cmd.exe /C ";
       } else {
          cmd = "cmd.exe /C ";
       }
       if (cygwin)
       {
          cmd += Shell+" '"+Command+"'";
       } else {
          cmd += Command;
       }
    } else {
       cmd = Command;
    }
  </code></pre>
  
  <p>(Yes, the if structure could be better optimized.)</p>
  
  <p>In this case, "Shell" equals: </p>
  
  <pre><code>Shell=C:/cygwin/bin/bash -c
  </code></pre>
  
  <p>And, there's a test program to ensure the above and supporting code works OK - it runs a bit of shell program and ensures it got back what it thought it should. It says:</p>
  
  <blockquote>
    <p>Checking the ability to run a program using a shell...
           Yes, shell programs work fine.</p>
  </blockquote>
  
  <p>The final contents of cmd look something like this:</p>
  
  <blockquote>
    <p>cmd.exe /C C:/cygwin/bin/bash -c '/cygdrive/c/opt/ST/v3.3/bin/ST.exe'</p>
  </blockquote>
  
  <p><strong>WHAT I SUSPECT:</strong></p>
  
  <p>I suspect what's going on is that the Cygwin1.DLL file isn't being found properly. It lives in C:/cygwin/bin/cygwin1.dll</p>
  
  <p><strong>NOTE THAT</strong> both the system-level PATH and the Cygwin PATH include the path to the cygwin .dll files. Moving a copy of cygwin1.dll to the bin directory where the target executable lives didn't work either.</p>
  
  <p>Would LD_LIBRARY_PATH lend any help here? If so, any idea how it is to be set?</p>
  
  <p>Other ideas?</p>
  
  <p>Thanks.</p>