User forums > Using Code::Blocks

C::B new releases hung on linkage in cygwin

(1/6) > >>

littlegene:
Hello, dear developers.

I successfully use the latest "debugger branch" (rev 8020) of C::B with my projects and it completely fits my needs for now.
But I recently noted that newest branches (eg, 8300) built locally and curious for me in the future, can not suite me because I saw some particular project of mine does not want to compile well. I realize the cygwin environment often is out of C::B interests, however I would like to report there are problems on project linking stage, not appearing on the mentioned deb_branch of 8020 rev. That it to say - for example, I see the first linkage step of a project does not finish at all at C::B rev 8300. I work with standalone Makefile ("custom Makefile") generated by Autotools in this case, for example, but I think that this fact makes no difference.

Could you offer all possible directions of digging into the trouble from my side. I could give the necessary info of the local trouble if need be.

Thanks.

Gene.

oBFusCATed:
If you have the time and a fast machine you can try to bisect where the problem started.
Probably you can try several nightlies, first.

p.s. If you use custom makefile then there is something broken in the makefile or its expectations (environment variables), because C::B just calls make with your makefile as parameters.
p.s.s. I suppose you've enabled the full compiler log, if not please do so (see the FAQ at the wiki for details)

littlegene:

--- Quote from: oBFusCATed on September 07, 2012, 08:02:25 pm ---If you have the time and a fast machine you can try to bisect where the problem started.
Probably you can try several nightlies, first.


--- End quote ---
Thank you for your hint. I am in the middle of that proccess right now.
First of all, I would want to beg a pardon for some disinformation concerning my previous message: I had thought I had 8020 working revision of C::B because this branch was being kept by me as standalone set of sources of C::B. But yesterday I realized (after checking many nightly builds) that when compiling that workable version several mounts ago I was at the version *not very close* to 8020 rev. And because I had't have svn.exe utility in the PATH variable (and thus having "SVN 0" rev. in the product banner) I could not say for sure which particular version I was using for the period.

Now, it all is more clear.
For now the affairs is:
- the mentioned trouble of mine with linkage resides in the revisions range from  7800 to 7850.
- Now I keep trying to bisect further and detect the waterline (the two particular adjacent revisions).

will let you know ASAP for the word for further actions.

littlegene:
Hello!

I've revealed that problem starts from 7802.
I checked these versions: 7850, 7830, 7815, 7808, 7803(failed to compile), 7802, 7801. (Each time I press Ctrl-F11 for cleanup)
Days ago I tried the newest, as I mentioned, unsuccessfully as well.
7801 - is the latest one where there is no compile(link) trouble. The problem starts (in cygwin) from the next rev. I did not try Linux compilation through C::B for now, though. (In linux I just created new project of this project  from sources and not tried native automake-created makefile.)

svn  Diff and log says there were changes to only compiler plugin.

And  indeed, if I (re)place compiler.dll to 7850, 7830, 7815, 7808 plugins directories, I can successfully compile the project from within these versions ;-)

Any ideas? Should I go on myself or let you check towards this subject?
Here is that line (from build log excerpt):
/bin/sh ../libtool --tag=CXX    --mode=link g++-4   -Wall -g  -fexceptions -all-static -no-undefined   -L/lib/qt3/lib -o libXmlRpc.la -rpath /usr/local/lib strncasecmp.lo XmlRpcClient.lo  XmlRpcDispatch.lo XmlRpcServer.lo XmlRpcServerConnection.lo  XmlRpcServerMethod.lo XmlRpcSocket.lo XmlRpcSource.lo  XmlRpcUtil.lo XmlRpcValue.lo ../replace/libreplace.la


thanks.

oBFusCATed:
What is the difference between the executed commands, if there is a difference?
Also have you tried to put an env command in you makefile to see, if the environment variables are the same with the working and with the broken versions?
Also is the working directory for make the same?

Navigation

[0] Message Index

[#] Next page