Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
A link to the unicode windows wxWidget dll for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc481-TDM.7z
The 30 August 2014 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2014/CB_20140830_rev9884_win32.7z
- Linux :
none
Resolved Fixed:
- debugger: Expand macros in the Additional GDB commands
- SmartIndentHDL: do correctly unindent architecture", "entity" and "configuration".
- CC: call SmartIndentPlugin->OnCCDone() when CC is done through the event system
- fix for bug #36 Path slashes in project file flip on save between windows and nix
- SpellChecker: - update hunspell to version 1.3.3 (only used on MSW)
- CC: apply patch by Huki to avoid the recursive call of Tokenizer::Peek() function, and reset the TokenIndex correctly when handling C preprocessor conditional directive. The related discussion is in http://forums.next.codeblocks.org/index.php/topic,18315.msg133639.html#msg133639 and the following three replies.
- compiler: Add propgrid to the compiler flags dialog
- compiler: Extract some flags from the warnings category to the general category in the common-warnings file
- EditorTweaks: Add menu item for controlling if the whitespace characters should be visible (fixes issue #39)
- CC: remove the task pool queue, it was used for priority header file parsing, but we now use recursive paring of the header files instead.
Regressions/Confirmed/Annoying/Common bugs:
Packages for openSUSE (http://codeblocks.esy.es) (binaries and sources) for 32-bit and 64-bit.
i fonund that no ubuntu series packages for a long time
I have try to build the svn build 9894, but the fortranproject was not present in the packages which downloaded from sf.
edit:
I know the reason now(it seems googlecode was banned in here).
Let's check out last summer release...
Quote from: mynameis on September 01, 2014, 06:48:13 AM
i fonund that no ubuntu series packages for a long time
You can try my (debian-)repo. They can work for ubuntu, but depends on the ubuntu-version.
By the way:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc19, fc20 and rawhide), RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) and RedHat/CentOS 7 packages (only 64-bit at the moment) can be found in my rpm-repo (http://rpm.jenslody.de).
If stripping of whitespaces on saving is enabled and tab char used for indents, there is a little bug - when cursor is on blank line with one or more tabs i'm pressing Ctrl-S - tabs are stripped - i'm starting to type and line is filling by spaces to cursor position, but there must be tab characters.
Can you add a ticket in the tracker on sf.net?
Please include a bit more detailed explanation.
Quote$ dpkg-buildpackage -us -uc
dpkg-buildpackage: source package codeblocks
dpkg-buildpackage: source version 13.12svn9513
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Jens Lody <jens@codeblocks.org>
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build git
dpkg-checkbuilddeps: Unmet build dependencies: libstdc++6-4.3-dev | libstdc++6-4.4-dev | libstdc++6-4.5-dev | libstdc++6-4.6-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
obf@obf-VirtualBox ~/codeblocks/git $ sudo apt-get install libstdc++-dev
[sudo] password for obf:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libstdc++-dev is a virtual package provided by:
libstdc++6-4.6-dev 4.6.4-6ubuntu2
libstdc++6-4.4-dev 4.4.7-8ubuntu1
libc++-dev 1.0~svn199600-1
libstdc++6-4.7-dev 4.7.3-12ubuntu1
libstdc++-4.8-dev 4.8.2-19ubuntu1
You should explicitly select one to install.
E: Package 'libstdc++-dev' has no installation candidate
Isn't it possible to make this command pick the appropriate libstdc++ library for my compiler (4.8.1 in my case)?
This is a mint-lastest installation inside virtual box.
Quote from: mynameis on September 01, 2014, 06:48:13 AM
i fonund that no ubuntu series packages for a long time
I am on Kubuntu, and I found it convenient to build C::B from Jens Lody's preconfigured source tarball. Works every time.
Just follow the few simple steps at http://forums.next.codeblocks.org/index.php/topic,18580.msg127254.html#msg127254
Quote from: oBFusCATed on September 01, 2014, 09:15:05 PM
Quote$ dpkg-buildpackage -us -uc
dpkg-buildpackage: source package codeblocks
dpkg-buildpackage: source version 13.12svn9513
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Jens Lody <jens@codeblocks.org>
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build git
dpkg-checkbuilddeps: Unmet build dependencies: libstdc++6-4.3-dev | libstdc++6-4.4-dev | libstdc++6-4.5-dev | libstdc++6-4.6-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
obf@obf-VirtualBox ~/codeblocks/git $ sudo apt-get install libstdc++-dev
[sudo] password for obf:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libstdc++-dev is a virtual package provided by:
libstdc++6-4.6-dev 4.6.4-6ubuntu2
libstdc++6-4.4-dev 4.4.7-8ubuntu1
libc++-dev 1.0~svn199600-1
libstdc++6-4.7-dev 4.7.3-12ubuntu1
libstdc++-4.8-dev 4.8.2-19ubuntu1
You should explicitly select one to install.
E: Package 'libstdc++-dev' has no installation candidate
Isn't it possible to make this command pick the appropriate libstdc++ library for my compiler (4.8.1 in my case)?
This is a mint-lastest installation inside virtual box.
It should work if you remove the line completely from debian/control.
g++ should depend on the correct libstdc++-dev automatically,
and g++ is a dependency of the build-essential-package which is an automatic dependency of the debian build-system.
I don't know if it also works for older revisions of debian-based distro's, but on wheezy it seems to work.
Quote from: oBFusCATed on September 01, 2014, 08:45:49 PM
Can you add a ticket in the tracker on sf.net?
Please include a bit more detailed explanation.
Yes, i can. By the way, do you understand my english easily or with problems? =)
Your English is fine...
Quote from: cacb on September 01, 2014, 09:41:38 PM
Quote from: mynameis on September 01, 2014, 06:48:13 AM
i fonund that no ubuntu series packages for a long time
I am on Kubuntu, and I found it convenient to build C::B from Jens Lody's preconfigured source tarball. Works every time.
Just follow the few simple steps at http://forums.next.codeblocks.org/index.php/topic,18580.msg127254.html#msg127254
thanks a lot,it seems a little complex for me(a Linux learner),but i will try it :)
Avast antivirus is complaining there is a virus/malware in this binary (for Windows).
Quote from: RomanV on September 03, 2014, 11:03:48 AM
Avast antivirus is complaining there is a virus/malware in this binary (for Windows).
Search the forum.
My (very personal) opinin:
there is a malware on your system called avast.
Hello Everybody.
I use Norton 360 from Symantec as virus-scanner and I can confirm that you get an arlarm with a nightly. And to be honest Roman and I are not the only people facing this problem. If you search through your forum, you will find some more comments around this.
My Norton calls the reason of detection "heuristic" and it is associated with the file "CbLauncher.exe" in the archive "CB_YYYYMMDD_revXXXX_win32.7z". Since this heuristic warning comes with every nightly since I use Norton 360 (end of last year), I replaced date by YYYYMMDD and revision-number by XXXX. I don't realy know, what "heuristic" realy means. But I think it means that the virus-scanner tries to estimate if a program may be a problem. This means not that the programm is realy corrupted but the scanner is not able to exclude the possibility.
Symantec offers to register such cases to avoid detecting trustable programs as a problem on its webside. Therfore I had to give them the associated download location. For some reasons (perhaps a problem between my ears whyle filling the online formular) they where not able to download. I tried to send them some more details but until now they didn't react. If you are intersted, I may send you the content of the emails. Perhaps we find to gether what I did wrong (except sending them a file they deteted as a potential virus).
How ever, in my case the problem is the file "CbLauncher.exe". When I download a nightly at my company, I have no problem since we use an other virus-scanner. Thus I unpack the download there and put it on a stick. In this unpacked state I can transfer it to my computer at home, where "CbLauncher.exe" will be still deleted by my Norton-360. But as I see everyday, for the normal use "CbLauncher.exe" is not neccessary. Thus I would propose to offer "CbLauncher.exe" in an own package as long as this virus-scanner problem is not solved.
Best regards,
Eckard.
Stupid heuristic analyzer. All anti-viruses are useless shit. Use firewalls and java-script blockers in browsers and you'll never catch a virus.
Hello SteelRat.
??? Stupid ???
I don't know. If you have to maintain a tool like a virus-scanner it is hard to define exactly that an unknown programm that looks in some parts similar to a virus is not a virus. I think there is no other posibility to register the software (or to let it register) to become the status as known what means trusted software. Since Code::Blocks is an open source project this should be no normaly no problem.
Best regards,
Eckard.
Yep, but it's nightly build, not official release. It does not need to be registered anywhere.
Hello SteelRat.
Since Code::Blocks is freeware it has to be registered no where even it is an oficial release.
To register it in a list of an virus-scanner provider as "False Positive detected" means to give him a chance to update his product. Otherwise every user with this virus-scanner may have problems to download a nightly, since it is not posible to download it without the "CbLauncher.exe".
I think today there are good reasons to have a virus-scanner. And I think it is not realy a good idea to skip it since it has problems with only one application.
Regards,
Eckard.
Quote from: jens on September 01, 2014, 10:28:18 PM
It should work if you remove the line completely from debian/control.
g++ should depend on the correct libstdc++-dev automatically,
and g++ is a dependency of the build-essential-package which is an automatic dependency of the debian build-system.
I don't know if it also works for older revisions of debian-based distro's, but on wheezy it seems to work.
It worked, but it didn't pick the revision number correctly...
Quote from: jens on September 03, 2014, 11:11:31 AM
Quote from: RomanV on September 03, 2014, 11:03:48 AM
Avast antivirus is complaining there is a virus/malware in this binary (for Windows).
Search the forum.
My (very personal) opinin:
there is a malware on your system called avast.
I agree. I personally think it's False Positive result of Avast's heuristics. Avast only complained about this build. I usually install all nightly builds. And it was the first time Avast complained about the build.
But Avast itself is not top-level antivirus. I have many friends in IT security field which do not seriously think about Avast.
I posted my initial message because I just wanted other people to know about it to Code::Blocks community. Because I think some other users of Code::Blocks also use Avast and they may encounter the same false positive result of the scan.
hey... avast! is quite good ;) There aren't that much more AV's that are better (and free)
And what is more important to me then the count of viruses/malware it detects is simply the performance. And avast! is also good with that one. Its features and feeling is quite good ;) (or at least was, it's been a few years since I last used an AV or software firewall)
And complaining about an AV because of false positives is also not a really good idea. They at least increase your security to some point ;) Plus you can easily bypass them if you're really sure everything is ok. Just use your AV right.
It's also the user of the AV who needs to take actions and report that false positive, not the developer of the software. Because you've got the AV, you've got the tools to report the false positive not the dev. (well some offer an online form without using their AV, but others don't. Also, why should a dev really care if only 1 AV got problems he didn't directly cause?)
P.S. avast! doesn't seem to report it anymore: https://www.virustotal.com/en/file/c892433b6092890716e76ee662877eb566ee43fdafc6e821ec9f602364c3f0ce/analysis/1409915475/
Hello Everybody.
I agree that the user of the anti virus software has to report the "false positive" detection to his av-scanner provider. But I think it would be helpful if there would be a topic in the forum of code::blocks, that can be used to post information about this. It may be useful, if every kind of anti virus software has its own sub-topic. Other users can see, what is already reported if the reporter posts the ticket-number.
In my case I found in the forum the post http://forums.next.codeblocks.org/index.php/topic,19182.0.html (http://forums.next.codeblocks.org/index.php/topic,19182.0.html), where I learned that afb45 already reported a similar "false positive" detection under the ticked number " submission [3491738]" in April. But his detection reported the detection of "Trojan.Gen.SMH" while in my case the "Suspicious.Cloud.7.F" was detected. For some reasons my first report to Symantec under the ticket-number "submission (3590276)" last month was not successful. Thus I reported it new today under the ticket-number "submission (3613580)".
I hope this information is helpful for other users of Symantec which have a similar problem.
Best regards,
Eckard.
Quote from: eckard_klotz on September 07, 2014, 06:32:49 PM
Hello Everybody.
I agree that the user of the anti virus software has to report the "false positive" detection to his av-scanner provider. But I think it would be helpful if there would be a topic in the forum of code::blocks, that can be used to post information about this. It may be useful, if every kind of anti virus software has its own sub-topic. Other users can see, what is already reported if the reporter posts the ticket-number.
In my case I found in the forum the post http://forums.next.codeblocks.org/index.php/topic,19182.0.html (http://forums.next.codeblocks.org/index.php/topic,19182.0.html), where I learned that afb45 already reported a similar "false positive" detection under the ticked number " submission [3491738]" in April. But his detection reported the detection of "Trojan.Gen.SMH" while in my case the "Suspicious.Cloud.7.F" was detected. For some reasons my first report to Symantec under the ticket-number "submission (3590276)" last month was not successful. Thus I reported it new today under the ticket-number "submission (3613580)".
I hope this information is helpful for other users of Symantec which have a similar problem.
Best regards,
Eckard.
I think it would be better to have only a single thread on the subject.
And, have a Wiki page on the subject with sub-pages to the Wikipage as needed.
But, I am NOT a CB Dev; they are the ones to decide.
And, I have forgot the little I learned on doing Wiki pages; so, I have no plans to start a Wiki page.
I would think subpages for each DLL or EXE in CB Blocks would be nice with page sections for each AV.
Tim S.
Hello Everybody.
This time I was successfull. Symantec answered:
QuoteIn relation to submission [3613580].
Upon further analysis and investigation we have verified your submission and, as such, the detection(s) for the following file(s) will be removed from our products:
854E5D01E60235E3ACFA0AFAD2AADC36 - cblauncher.exe
The updated detection(s) will be distributed in the next set of virus definitions, available via LiveUpdate or from our website at http://securityresponse.symantec.com/avcenter/defs.download.html
Decisions made by Symantec are subject to change if alterations to the Software are made over time or as classification criteria and/or the policy employed by Symantec changes over time to address the evolving landscape.
If you are a software vendor, why not take part in our whitelisting program?
To participate in this program, please complete the following form: https://submit.symantec.com/whitelist
First of all they agree that this was realy a wrong detection.
But second, they offer a more longlasting posibility to avoid such problems in the futute if you follow the link "https://submit.symantec.com/whitelist" you will reach a dialog that allows you to register Code::Blocks and its components in their white-list. But since this establishes a connection between symantec and the C::B project using this posibility is not the decision of a user it is a decision of the developers.
Thus, dear deveoplers of Code::Blocks please think about. As far as I understand it, with every new virus that behaves in some aspects like a component of Code::Blocks we the user have to report a new wrong detection again. With this offer you have the chance to make Code::Blocks known.
Best regards,
Eckard.
Bleh... so we'll have to upload every cb release we do to every av software vendor?
Hello C::B Developers.
Quote... so we'll have to upload every cb release we do to every av software vendor? ...
Some body has to do. OK, I agree that it is a great effort for the project to inform all possible av software publisher about every new nightly. And it may be easier, if the user is doing this to share this effort. But I still think that this topic should be supported with an own sub-forum to give us useres a central place to share the information, what files and realeases are allready reported to which vendor and with what result.
Best regards,
Eckard.
Actually, uploading it to Google's VirusTotal should be enough :P
One of the benefits of VirusTotal are that results are shared among AV companies. This means if someone detects something but others do not, it's possible for those others to get samples and fix their detection... Well this was meant for non detected viruses, but I'm certain that it might also work with false positives^^
But I don't know how automatic that all works... or if false positives are handled at all... Still maybe better then nothing :P
Otherwise, uploading CB to every AV vendor on every release (nightly or not) can only be done by having it done automated... and even then it requires a lot of time (to upload it) unless you're using a server to do that :P
Anyway, I'm still saying the user is responsible for his AV, and every user should be able to handle false positives anyway or they should use a different AV. It's their PC that has a problem with it ;)
P.S. you'll never know if a report is indeed a false positive ;) Because the developers PC could be corrupted or the upload somehow was.. so best is to use VirtusTotal if unsure and then... well guessing if you want to trust it if only 1 or 2 report it and others don't... could be still infected :P
And false positives don't disappear by the first report, to have a false positive to disappear a lot of people have to report it. Why should the AV company trust the first one to report it? Why should it really be a false positive? You only know if you've got enough data.
I don't even think they'll trust developers blindly, it will just give them a hint.. also note their note about signing the executables... that costs a lot of money which Microsoft wants to receive just to have it signed. So not even near possible for Code::Blocks.
BTW I submitted this build to VirusTotal. See the result:
https://www.virustotal.com/en/file/b187b0b7cf24dc67740f5e8d844bd0d43e6f81ecf7590a6630b9a0cf2b4d39bc/analysis/1410267798/
So it's clean. Strange, but even Avast shows it as clean. While on desktop Avast (with latest updates) shows:
Infection blocked
URL
hxxp://softlayer-dal.dl.sourceforge.net/project/codeblocks/Binaries/Nightlies/2014/CB_20140830_rev9884_win32.7z|CbLauncher.exe
Infection
Win32:Evo-gen [Susp]
Hello White-Tiger
QuoteAnd false positives don't disappear by the first report, to have a false positive to disappear a lot of people have to report it. Why should the AV company trust the first one to report it? Why should it really be a false positive? You only know if you've got enough data.
If you report a false positive detection you also have the podibility to upload the effacted file. Thats how I did it.
Best regards,
Eckard.
PS.: How ever, I miss in this discussion the comments of the developers and/or the forum admin. Even if I accept, that I have to do the report and upload for my av-software, I still think an own sub-forum to post information about this for other users would be a great help for all of us.
Quote from: RomanV on September 09, 2014, 03:10:42 PM
[...]
So it's clean. Strange, but even Avast shows it as clean. While on desktop Avast (with latest updates) shows:
Infection blocked
[...]
well... avast! doesn't just do some on-access scan as most simple and free AV's do, it also checks HTTP,SMTP, etc. traffic and intercepts things before they even arrive on your HDD / PC
And I guess it's basically blocking the URL... so if you had the file on your local PC, it wouldn't even complain...
It's actually weird that it behaves this differently... and it looks like the traffic filter isn't up-to-date^^
Anyway, did you try to manually check for updates for avast!? Maybe you're even using an older version :P VirusTotal is kinda up-to-date in that regard
Quote from: eckard_klotz on September 09, 2014, 03:30:00 PM
PS.: How ever, I miss in this discussion the comments of the developers and/or the forum admin.
You've asked for it: I wouldn't have bothered to do this even if I was using windows... I'm not so I can't care less.
If you don't trust us, then build everything from the sources...
Hello Developers.
QuoteIf you don't trust us, then build everything from the sources...
For me this is not question of trusting your work. If I would not trust you I would not user Code::Blocks. Don't ask me why av-tools detect C::B parts as potential viruses. Furthermore if you report them the "false positive" with an upload of the binary detected as suspicious, they agree that it was a "false positive" and set it on their white-list until they start to search for a new virus that behaves like a part of C::B. Then you get the next "false positive" and a new report has to be done.
Even this is a never ending story, we have to deal with it and this means when ever a "false positive" detection occures, somebody has to report it and share the report as well as the result with the community. The reason why I ask for a sub-forum is, that this makes it easier for the useres to share information about reporting "fasle positive" detections. If we the user have to do it, it would be extremly helpful to know if sombody already has done it for a specific detection-case and for a specific av-tool. An other advantage may be that this gives us the chance to collect some historical data. Symantec offers the posibility to add some additional information. Thus I noted down all available ticket-numbers I found here in the forum associated with cblauncher in the hope to animate them to find a more longlasting solution.
I don't want to blame you for the fact that av-tools detect C::B bianries as suspicious. My intention is to help you and other useres to deal in a constuctive way with this wrong detections.
Best regards,
Eckard.
I don't see that much demand for a sub-forum, you can start a topic about this and if people start posting in it then we can pin it at the top.
Also, keep in mind that past experiences have shown that most users fail to find what they need (either without even searching for it or either because the forum's search functionality is not very good) and instead start a new topic at a random sub-forum.
Quote from: White-Tiger on September 09, 2014, 04:54:25 PM
well... avast! doesn't just do some on-access scan as most simple and free AV's do, it also checks HTTP,SMTP, etc. traffic and intercepts things before they even arrive on your HDD / PC
And I guess it's basically blocking the URL... so if you had the file on your local PC, it wouldn't even complain...
It's actually weird that it behaves this differently... and it looks like the traffic filter isn't up-to-date^^
Anyway, did you try to manually check for updates for avast!? Maybe you're even using an older version :P VirusTotal is kinda up-to-date in that regard
Did you read my message? I said I was using Avast with latest updates (program updates and virus definitions). The result is not only because of traffic interception. I turned off live shield of Avast. downloaded build's file (it was saved on my drive). Then I turned on shield. So I got the same message from Avast.
I repeat: I think it's false positive.
In reality what I did: it decided the following: I skip this build. I will wait for another build. That's all. Because I don't have time to find out how to turn off this Avast false positive. I should disable something in Avast heuristics I guess. But it may be useful in some situations. So I will wait to the next build.
And I think developers of Code::Blocks do not have to spend their time and submit nightly builds to different virus check sites. Nightly build - as it's said "nightly build". Cautious users must use "yearly" build or something. And for these rare build maybe virus check makes sense. But it's not the case for nightly builds. It's better to spend more time on development of new features or issue corrections.
Hello Everybody.
Just to bring it to an end (or better temporary end):
I don't want to stress the points who has to do what and why any more since I learned in the last days that this is not really helpful as long as it does not result into a constructive solution. But pleas allow me to post the what I was able to do to solve my current anti virus problem just as an example for others and I hope that this is what all others expect from me if they write about things which are not the job of the project but by the users.
Like RomanV and other users I have an anti virus software on my computer (in my case Norton 360 from Symantec) that detected a part of Code::Blocks as suspicious. Like other users I use Code::Blocks on other systems also and I have no problems there. Thus I think it is a false positive detection.
My anti virus software provider offers me to report this, what contains the possibility to upload the involved files to let it test. Once the test from my provider is passed, the file will be set on a white list and will not be detected as being a specific virus.
As I posted in this nightly discussion, I did this and I've got the agree from my anti virus software provider, that the file is really clean. Furthermore they updated their detection profiles. Yesterday evening I started a complete system scan and I've got no false positive detection associated with a part of Code::Blocks any more.
What did I learn:
The only way to solve a false positive detection is to report it. Otherwise the anti virus software provide will not know about. If a project like Code::Blocks is not able to upload every nightly on Websites of every anti virus software, it should be plausible that the provider of an anti virus software is not able to react on every nightly or other releases of every open-source-project in the world.
Even you may have the impression that heuristic scan-procedures are not really intelligent, you have to face the fact that this kind of scan-procedures is used nearly by all modern anti virus programs. The reason is that this procedure seems to be the best compromise between speed and quality of detection, what not means that the quality is the very best.
But at the end you have to decide between 2 evils:
- On the one side you may have a security system you have to maintain together with its provider.
- On the other side you may have an wide open system for all kind of shit or an totally closed one by disabling really everything.
As far as I know now heuristic scan means to observe only some aspects of every file and to compare it with known viruses.
What looks like a known virus and behaves like a known virus is a virus as long as nobody proves that it is not a virus.
Unfortunately today's virus developers use the look and feel of already existing programs to mask their bad software. The result is, with every new virus, that is using a part of Code::Blocks as camouflage, we got a new false positive detection.
Since Code::Blocks is not the only affected project you can imagine that the number of false positive reports may be as high as the number of posts in this forum (or higher). And even they try to atomize a lot of actions, it may need some more communication between the reporter and the anti virus software provider. I started to report my current case in August and until some days ago it took 12 mails and 3 reports to solve the problem (what may be an other argument for the project, that this is better done by single persons out side of the project. But it may an argument to have a central place to share this information to minimize this effort also).
The discussion shows, that we can not expect from the developers some support in this special point. Most of them didn't react and the one who did made clear that this can not be the job of the project. Even that this fits not with my personal proposals, I think we have to accept this. Since Code::Blocks is a project run by volunteers which have founded this great project to publish this IDE with out expecting some revenue, I can understand that they don't see it as their responsibility to solve problems caused by criminals (where I'm talking about those who developed the viruses and not about the anti virus software providers).
RomanV, you decided to wait for the next nightly. As long nobody reports the false positive to your anti virus software provider this will not help you. Since your scanner does not detect a real infection of a file but only an alikeness with an infected one. This alikeness is part of the strategy used by the developer of a real virus to mask his bad software. Thus the best you can do, is finding out how you can report the false positive detection together with an upload of the file detected as suspicious. If you don't do it, who else should.
Best regards,
Eckard.
PS.: Dear Code::Blocks team. For some reasons I have the feeling that stressing this special problem is not really welcome what I can understand. Thus please accept my apologize if my posts may contain unreasonable expectations or something like this. This was not my intention.
Based on Jens' source tarball found here (http://apt.jenslody.de/testing/pool/main/c/codeblocks/) , I have successfully built this Nightly (svn9884) under raspbian for the Raspberry PI. It took around 14 hours to complete, but it worked :) It seems to me that this nightly runs faster than the old nightly that I got from someone else in January. I have not found up to date builds of C::B for raspbian elsewhere.
I'd be willing to upload the binaries to some place where others can access it, assuming that I don't break any rules by doing that. Please advice if you are interested.
LLVM Clang does not support -mwindows any more, so please update the switch of GUI Application in options_clang.xml:
from:
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -mwindows"/>
to:
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -Wl,--subsystem,windows"/>
Patch?
Quote from: oBFusCATed on September 15, 2014, 09:23:11 PM
Patch?
Sorry, I dont how to make a patch(I am a rookie here), but the file is locale here:
src\devel\share\CodeBlocks\compilers\options_clang.xml
The content need to change is in line 188.
update:
src\plugins\compilergcc\options_clang.xml
http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29
Quote from: oBFusCATed on September 16, 2014, 10:58:00 AM
http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29
I don't know how to use svn ... :
QuoteG:\cb_svn\src\plugins\compilergcc\resources\compilers>svn add options_clang.xml
svn: warning: W150002: 'G:\cb_svn\src\plugins\compilergcc\resources\compilers\op
tions_clang.xml' is already under version control
svn: E200009: Could not add all targets because some targets are already version
ed
svn: E200009: Illegal target for the requested operation
Quote from: edison on September 16, 2014, 03:22:50 PM
Quote from: oBFusCATed on September 16, 2014, 10:58:00 AM
http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29
I don't know how to use svn ... :
QuoteG:\cb_svn\src\plugins\compilergcc\resources\compilers>svn add options_clang.xml
svn: warning: W150002: 'G:\cb_svn\src\plugins\compilergcc\resources\compilers\op
tions_clang.xml' is already under version control
svn: E200009: Could not add all targets because some targets are already version
ed
svn: E200009: Illegal target for the requested operation
I think running the command "svn diff > my.patch" should be enough to create the patch file.
Thanks, it works.
Can you review and submit it ?
Index: options_clang.xml
===================================================================
--- options_clang.xml (revision 9916)
+++ options_clang.xml (working copy)
@@ -185,7 +185,7 @@
<Command name="LinkNative"
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -Wl,--subsystem,native"/>
<Command name="LinkExe"
- value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -mwindows"/>
+ value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -Wl,--subsystem,windows"/>
<Command name="LinkDynamic"
value="$linker -shared -Wl,--output-def=$def_output -Wl,--out-implib=$static_output -Wl,--dll $libdirs $link_objects $link_resobjects -o $exe_output $link_options $libs"/>
</if>
Quote from: oBFusCATed on September 16, 2014, 10:58:00 AM
http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29
Update this wiki page to point to SF.
@edison: Which version of clang is the last one that supported the old switch?
@alpha: Can we make this parse the version of clang and then pass the appropriate option?
Quote from: oBFusCATed on October 22, 2014, 10:27:42 PM
@edison: Which version of clang is the last one that supported the old switch?
@alpha: Can we make this parse the version of clang and then pass the appropriate option?
I think going with the first clang version to support the new switch is also an option.
Tim S.
Oops, must have missed this. Yes, I should be able to add a quick regex. Will do some testing this weekend to see what is necessary.
Quote from: oBFusCATed on October 22, 2014, 10:27:42 PM
@edison: Which version of clang is the last one that supported the old switch?
I don't know...
http://comments.gmane.org/gmane.comp.compilers.clang.devel/38114
Reid Kleckner said:
QuoteI doubt we ever recognized this argument. This probably changed because we started rejecting unknown -m flags.
Quote from: Alpha on October 23, 2014, 06:23:51 AM
Oops, must have missed this. Yes, I should be able to add a quick regex. Will do some testing this weekend to see what is necessary.
Just keep in mind that dumpversion doesn't do anything useful - always returns 4.2.1 (at least on linux and osx)
From my experimentation, it seems neither of these flags are necessary.
<Command name="LinkExe"
- value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -mwindows"/>
+ value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -Wl,--subsystem,windows"/>
I will soon commit the equivalent of (for all versions of clang)
<Command name="LinkExe"
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs"/>
if there are no reported issues with it.
Quote from: Alpha on October 30, 2014, 02:32:45 AM
I will soon commit the equivalent of (for all versions of clang)
<Command name="LinkExe"
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs"/>
if there are no reported issues with it.
This will cause a console window below the gui window, make it not a "GUI application".
Quote from: edison on October 30, 2014, 09:40:33 AM
This will cause a console window below the gui window, make it not a "GUI application".
Oh dear... flawed test cases. I am so embarrassed. :-[
I think I must be spending too much time under linux.
(Thank you.)