User forums > Nightly builds

The 27 February 2022 build (12727) is out.

(1/3) > >>

killerbot:
We switched to wx 3.1.5 --> download the new wx dll's see link below

If you tested the 22 january nightly you may find your compiler executable has changed from gcc.exe to mingw32-gcc.exe and g++.exe to mingw32-g++.exe. Please correct this, you won't be asked again.

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.

A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx315_2D_gcc810-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z


The 27 February 2022 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2022/CB_20220227_rev12727_win64.7z
  - Linux :
   none

The current SDK version is : 2.16.0

Resolved Fixed:


* wxSmith: Export only needed symbols (last part of ticket #1206)
* Restore --export-all-symbols in wxContribItems projects (removed in previous commit)
* Add C::B manual to Linux help menu like Windows (ticket #1211, thanks Andrew Cottrell)
Regressions/Confirmed/Annoying/Common bugs:

Pecan:
The Clangd_Client for this nightly can be downloaded at
https://sourceforge.net/projects/cb-clangd-client/files/Plugin_Install_Package/Windows_x64/ClangdClientForCBNightly20220227_rev12727_win64.zip/download

Unzip and copy the included clangd_client.zip to <YourCodeBlocksNightlyFolder>\share\CodeBlocks\clangd_client.zip

Copy the included clangd_client.dll to <YourCodeBlocksNightlyFolder>\share\CodeBlocks\plugins\clangd_client.dll

Restart your CodeBlocks Nightly.

Install instructions for LLVM/clangd can be downloaded at:
https://sourceforge.net/p/cb-clangd-client/code/HEAD/tree/trunk/clangd_client/documentation-install/

Neo:
I have a strange problem with environment PATH value using getenv function (on Windows platform).

--- Code: ---#include <stdio.h>
#include <stdlib.h>
int main()
{
    puts(getenv("PATH"));
    return 0;
}

--- End code ---
If I run/debug the above program in CB, anything like "c:\some\dir" with surrounding quotes becomes something like \\"c\some\dir". Note the text is shown verbatim, and note the missing colon ( : ). It seems CB does not like leading quote char in PATH value.

If I run my program directly without CB IDE, the quoted path string is normal.

I verified this in old 17.12 which demonstrated same behavior. So it's an old bug but not disovered/reported by anyone.

Just curious, why does CB touch PATH value?

cyuyan:

--- Quote from: Neo on March 02, 2022, 09:18:09 am ---I have a strange problem with environment PATH value using getenv function (on Windows platform).

--- Code: ---#include <stdio.h>
#include <stdlib.h>
int main()
{
    puts(getenv("PATH"));
    return 0;
}

--- End code ---
If I run/debug the above program in CB, anything like "c:\some\dir" with surrounding quotes becomes something like \\"c\some\dir". Note the text is shown verbatim, and note the missing colon ( : ). It seems CB does not like leading quote char in PATH value.

If I run my program directly without CB IDE, the quoted path string is normal.

I verified this in old 17.12 which demonstrated same behavior. So it's an old bug but not disovered/reported by anyone.

Just curious, why does CB touch PATH value?

--- End quote ---

I tested your program, running it normally on Win7.

PB:

--- Quote from: Neo on March 02, 2022, 09:18:09 am ---If I run/debug the above program in CB, anything like "c:\some\dir" with surrounding quotes becomes something like \\"c\some\dir". Note the text is shown verbatim, and note the missing colon ( : ). It seems CB does not like leading quote char in PATH value.
Just curious, why does CB touch PATH value?

--- End quote ---
I can confirm the issue on Windows 10 with C::B 20.03. Quotation marks in PATH must be rare, I had none there and had to add such a path manually. I am not sure if those are even allowed there, as it seems paths with folders having spaces in them (e.g., "Program Files (x86)") work just fine without them.

If you take a look at the output of your program, it becomes clear why C::B modifies the PATH: It prepends the current folder alias as well as the compiler path and its bin subfolder to it, so in my case it prepended

--- Code: ---.;C:\msys64\mingw32\bin;C:\msys64\mingw32;
--- End code ---

Navigation

[0] Message Index

[#] Next page