Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Cygwin path problem

Hi Rekha,

 

Yes, you should see this error. Never the less all the CDT process launch functionality should remain working since it will default to using java API.

The other thing that confused me is that you seem to not using the latest CDT/Eclipse sources since the ManagedBuildCPathEntryContainer is not used any more in the CDT 4.0 version.

 

What version of CDT/Eclipse are you using?

 

Thanks,

Mikhail

 


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Rekha Deshmukh
Sent: Tuesday, April 03, 2007 12:41 PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Cygwin path problem

 

Hi Mikhail,

 

Thank you for the reply.

When I renamed the directory the program successfully compiled but with the following error -java.lang.UnsatisfiedLinkError: no spawner in java.library.path

      at java.lang.ClassLoader.loadLibrary(Unknown Source)

      at java.lang.Runtime.loadLibrary0(Unknown Source)

      at java.lang.System.loadLibrary(Unknown Source)

      at org.eclipse.cdt.utils.spawner.ProcessFactory.<init>(ProcessFactory.java:35)

      at org.eclipse.cdt.utils.spawner.ProcessFactory.getFactory(ProcessFactory.java:47)

      at org.eclipse.cdt.utils.spawner.EnvironmentReader.getEnvVars(EnvironmentReader.java:52)

      at org.eclipse.cdt.core.CommandLauncher.getEnvironment(CommandLauncher.java:77)

      at org.eclipse.cdt.make.internal.core.scannerconfig2.DefaultRunSIProvider.setEnvironment(DefaultRunSIProvider.java:206)

      at org.eclipse.cdt.make.internal.core.scannerconfig2.DefaultRunSIProvider.invokeProvider(DefaultRunSIProvider.java:118)

      at org.eclipse.cdt.managedbuilder.internal.scannerconfig.ManagedBuildCPathEntryContainer$1.run(ManagedBuildCPathEntryContainer.java:147)

      at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)

      at org.eclipse.core.runtime.Platform.run(Platform.java:843)

      at org.eclipse.cdt.managedbuilder.internal.scannerconfig.ManagedBuildCPathEntryContainer.calculateEntriesDynamically(ManagedBuildCPathEntryContainer.java:156)

      at org.eclipse.cdt.managedbuilder.internal.scannerconfig.ManagedBuildCPathEntryContainer.getPathEntries(ManagedBuildCPathEntryContainer.java:191)

      at org.eclipse.cdt.internal.core.model.PathEntryManager.getResolvedPathEntries(PathEntryManager.java:457)

      at org.eclipse.cdt.internal.core.model.PathEntryManager.getResolvedPathEntries(PathEntryManager.java:429)

      . . .

I am still confused as about the role of the environment variables in running any proc. Why spawner failed on my machine is also an intriguing question for me.

 

Regards,

Rekha

------------------------------

Original Message

Message: 4

Date: Tue, 3 Apr 2007 11:44:19 +0400

From: "Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>

Subject: RE: [cdt-dev] Cygwin path problem

To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>

Message-ID:

      <B868AC247BCBC441B1B4F378A325E47DEC7846@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Content-Type: text/plain; charset="us-ascii"

 

Hi Rekha,

 

 

 

> I have observed that on the other machines which can compile the

programs have env with all the variables listed in it. But on my machine it is only 'PWD' and 'CWD' variables in the env.

 

This could be again the problem in the spawner since it is used to obtain the list of system environment variables defined that is then adjusted by adding PWD, CWD and some other variables.

 

Could you try to remove the spawner (i.e. you could either remove the

org.eclipse.cdt.core.win32 plug-in or remove the contents in the

os/win32/x86 directory of that plug-in (e.g. by temporary renaming the "x86" directory to something different)) and let me know whether you still see the same problem with the spawner removed or not?

 

 

 

Thanks,

 

Mikhail

 

 

 

________________________________

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]

On Behalf Of Rekha Deshmukh

Sent: Monday, April 02, 2007 8:44 AM

To: cdt-dev@xxxxxxxxxxx

Subject: [cdt-dev] Cygwin path problem

 

 

 

Hi All,

 

 

 

I don't know whether my problem and Mike's problem is the same. But I am too facing similar kind of issue.

 

On my machine I am not able to compile C program. It gives me 'Build error (Exec error:%1 is not a valid Win32 application.)'.

 

When I debugged I found that while exec it is crashing as pid returned is -1.

 

Is it related to env object which is passed to the exec? I have observed that on the other machines which can compile the programs have env with all the variables listed in it. But on my machine it is only 'PWD' and 'CWD' variables in the env.

 

 

 

Please guide me on this.

 

 

 

Regards,

 

Rekha

 

 

 

  

 

 

 

------------------------------------------------------

 

Original Message

 

Date: Fri, 30 Mar 2007 10:43:09 +0100

 

From: "Michael Wrighton" <mikew@xxxxxxxxxxxxxx>

 

Subject: [cdt-dev] Cygwin path problem

 

To: <cdt-dev@xxxxxxxxxxx>

 

Message-ID:

 

      <B2E1E83609061340B13D8A7B0FF9F7C2048B7D@xxxxxxxxxxxxxxxxxxxxxxx>

 

Content-Type: text/plain; charset="us-ascii"

 

 

 

Please let me know if I have targeted the wrong mailing list but I have come across an issue when trying to run the latest CDT on windows/cygwin and just wanted to find out if anyone can tell me what the problem could be.

 

 

 

 

 

 

 

To make it clear, I have two windows machines both running eclipse 3.3 M6, latest CDT, cygwin and java 1.5.0_06. One of the machines works fine and can build cygwin projects, the other one cannot locate any of the tools. I have debugged it and found that the root of the problem is that

 

ProcessFactory.exec() throws an exception every time it's called, so is unable to run regedit to get the cygwin path. What I cannot understand is why this is happening (I believe it's actually the Spawner.exec0() native method that is failing). If anyone's familiar with this code I would be grateful for any insight. I'm hoping/expecting it's something silly in my environment.

 

 

 

 

 

 

 

Thanks,

 

 

 

Mike W

 


Back to the top