C::B new releases hung on linkage in cygwin

[littlegene]

I suppose, while having
/usr/bin:/cygdrive/c/Program Files/Common Files/NetSarang:/cygdrive/c/Program Files/NVIDIA Corporation/PhysX/Common:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/d/Program Files/Bazaar:/cygdrive/c/Program Files/Microsoft SQL Server/100/DTS/Binn:/usr/local/bin:/cygdrive/c/Program Files/TortoiseSVN/bin:/cygdrive/d/Dev-Cpp/bin

on entry
you should not result in
/usr/bin:/:/usr/local/bin

on exit.

May be this is in SetupEnvironment method (or before)?

Unfortunately I havent look at C::B sources much.

[MortenMacFly]

May be this is in SetupEnvironment method (or before)?

HELLO! ANYBODY OUT THERE??? SAMPLE PROJECT, PLEASE!

How often shall I ask for this again? If you don't provide one next time I am locking this topic. It seems you don't want help, isn't it?

[stahta01]

May be this is in SetupEnvironment method (or before)?

HELLO! ANYBODY OUT THERE??? SAMPLE PROJECT, PLEASE!

How often shall I ask for this again? If you don't provide one next time I am locking this topic. It seems you don't want help, isn't it?

Sample Project with Sample Makefile that has the problem you are complaining about.

The exact version of Cygwin DLL and GCC installed in Cygwin is also likely needed.
Make version is really needed because this sounds like an make exe issue to me.

Tim S.

[littlegene]

Which is the way of providing the test project?
(I have no idea except for forum code tags (that is not sufficient) to provide it)

Attachments ?

[oBFusCATed]

Yes, you can zip it and then you can attach it to your post.
Or you can use a pastebin type of service,
or even a filesharing service.

[littlegene]

Here is the "test" project

Suppose, it consists of one dummy main.cpp (superfluous) executable and 2 librariers that have to be built as well.
One library named "replace" provided as a sample of good build even in the case Morten McFly modifies the PATH env var in C::B (incl. for "custom" makefile).
The other is an "xml-rpc" lib that is successfully built only inside cygwin console with native, unmodified PATH. "xml-rpc" lib, however, hangs when
building goes via a PATH that is modified in C::B.

You should have in the most recent Cygwin (now 1.7.16):
1. autotools (libtool, automake, autoconf)
2. make utility
3. g++ 4 version of compiler
4. Maybe something else...


Step-by-step after unpacking the test project to a cygwin user directory:

1. Execute cygwin console and go to the project directory
2. sh bootstrap
Now configure script is ready
3. sh runconfigure
Now makefiles all over the directories are ready

4. make all

You should see on entering (or exiting) each particular build directory the current right value of PATH env variable
You should also see that all executables (replace, xml-rpc, and main ) are compiled and built fine.



Step-By-step for building through the custom makefiles (obtained before) in C::B

1. Move testp.conf into the /Users/<user>/AppData/Roaming/codeblocks.
2. With the most recent C::B (eg. rev. 8394) open the testp.cbp project files:
codeblocks /p=ask (choose testp personality)
3. Open testp project (please ignore offers of START PAGE)
4. Correct compiler and linker disk settings already written in, compiler path, ...
I suppose, testp project has custom makefile and compiler full log turned on.
5. Choose MAKEALL build target and Press Ctrl+F11

The project should start rebuilding and during this process you can see current value of PATH env variable at build log as well.
My question is whether the xml-rpc in hung now on your own ? And what do you observe in the PATH value output at build log?

(PATH value now (in 8394 rev) is almost (not fully, as it was in 7801 rev) correct, but the author added (in 7802 rev) '/' directory that breaks the build  )

[MortenMacFly]

Here is the "test" project

It fails to compile/configure, as all sub-folders are empty. Isn't it possible to reduce it to a minimal hello world example? W/O the need of bootstrap, auto-foo and alike?

[MortenMacFly]

...btw: I can debug anything compiled with Cygwin just fine (on windows). hence I am using a proper non-makefile based project file and the default debugger. I just set a BP in your (Cygwin based) hello world app and it stopped there just fine.

Maybe you are doing things too complicated?! I mean: You have an IDE here, use its power!

[littlegene]

Thank you for your reply.
The correct test project will be posted  (size < 128k) tomorrow again. If it is not time consuming, please check it then.
I am rather doubt in my mind: None of things you wrote does not work at me:
1. I prefer use autotools and need a outer makefile (and of course in tha same project I also have several native C::B build targets  (specially for debug purpose) which are completely nice )
2. I have to apply (each time) well known patches for gdb in cygwin and force C::B to really work in debugging
3. Now cygwin has a problem that establishing BP in mount-like style (as C::B does: /cygdrive/c/cygwin/home/user/....) succeeds only if debugging project is on the other logical disk that Cygwin deploy folder...
(for item 3: I have (checked) 3 computers with that state : one job computer and 2 notebooks )

How you succeed in these 3 things - enigma for me )

talk to this place later.

thanks, again.

[littlegene]

Here is the "test" project

It fails to compile/configure, as all sub-folders are empty. Isn't it possible to reduce it to a minimal hello world example? W/O the need of bootstrap, auto-foo and alike?

Unfortunately, autotools withdrawal is quite complicated for me... And Hello world example always compiles fine. Remember: we have to watch the situation then C::B PATH env var substitution *influences* on cygwin compilation bugs in some cases.

Adusted test project is right underneath.

Again, please use
sh bootstrap
sh runconfigure
make all

and after that, check "make all" (for testp.cbp) in C::B...




[attachment deleted by admin]

[littlegene]

...btw: I can debug anything compiled with Cygwin just fine (on windows). hence I am using a proper non-makefile based project file and the default debugger. I just set a BP in your (Cygwin based) hello world app and it stopped there just fine.

I bet... you dont' use WIN 7... On XP C::B is just fine on debug cygwin programs. And it always was capable.
On windows 7 CBplugin (or so) still can't sync  BP with the point in editor and can't open the file in editor.
Without a patch. (I am not presenting here the patch because i use it for me, with no taking into accont all other debuggers can be, besides cygwin, because I NEVER use or used mingw at all)

The main difference (Win XP vs Win 7 on recent cygwin 1.7.16 and recent C::B v.8401) in the both full debugger's logs:

[debug][New Thread 2804.0x850]
[debug][New Thread 2804.0xe8c]
[debug]Breakpoint 1, main () at c:/test1/test1/main.cpp:7
[debug]/cygdrive/c/test1/test1/main.cpp:7:62:beg:0x40117e
[debug]>>>>>>cb_gdb:

At c:/test1/test1/main.cpp:7

against:

[debug][New Thread 2420.0x990]
[debug][New Thread 2420.0xd04]
[debug]Breakpoint 1, main () at C:/test1/main.cpp:7
[debug]/cygdrive/c/test1/main.cpp:7:62:beg:0x40117e
[debug]>>>>>>cb_gdb:

Cannot open file: /cygdrive/c/test1/main.cpp
At /cygdrive/c/test1/main.cpp:7

[stahta01]

FYI:

I just tried to debug Cygwin using MinGW GDB.exe (Debugger name and version: GNU gdb (GDB) 7.4) and it worked under Windows 7 32 bit.
Note: I do not normally use the debugger, so the only thing I tested is that it stopped on a break point.
I did see that Cygwin GDB.exe failed to stop on a break point.

CB Self built against wx 2.9 truck; CB SVN 8404.

I am now updating Cygwin to see if that breaks it.



Tim S.

[littlegene]

I did see that Cygwin GDB.exe failed to stop on a break point.

Here is how you can avoid it and force BP be established

1. If your recent cygwin (1.7.16, from 20 july 2012  - check "uname -a") is on the C DISK (C:\CYGWIN), then
place your cygwin project on the other disk, say D: (ex: D:\somedir\someproj\....)

2. If your recent cygwin (1.7.16, from 20 july 2012  - check "uname -a") is on the D DISK (D:\CYGWIN), then
place your cygwin project on the other disk, say C: (ex: C:\somedir\someproj\....)

Then rebuild the program and after that debugging will work.

In other words - a project to debug should lay on the other logical(or phisical) disk than the Cygwin deploy folder...
It is a bug of cygwin, not even discussed so far on cygwin forums, because they IGNORE this notice conserning to this bug...


*BUT* Keep in mind, that after BP in cygwin debug is fired, you could check in C::B (what I wrote about) that:

Cannot open file: /cygdrive/c/test1/main.cpp
At /cygdrive/c/test1/main.cpp:7


As you can see ("At /cygdrive/c/test1/main.cpp:7") BP is workable, but C::B opening of source file break. (Win7 only)