The 14 April 2012 build (7932) is out.

[MortenMacFly]

??

Nope, this slipped in by accident as it seems. The correct way would be:

Code

             if (extensionPolicy == tgfpPlatformDefault)
             {
                 wxFileName fname(outputFileName);
                 if (fname.HasExt()) fname.ClearExt();
                 outputFileName = fname.GetFullPath();
             }

Sorry for that, I am playing with that feature and this snippet was not supposed to be committed. Will fix...

[headkase]

Build issue still exists in SVN 7948.

[ollydbg]

Build issue still exists in SVN 7948.

I can confirm that this issue still exists in rev 7948. 

[ollydbg]

@morten:

Code

@@ -100,7 +100,7 @@ void CompileTargetBase::SetImportLibraryFilename(const wxString& filename)
 {
     if (filename.IsEmpty())
     {
-        m_ImportLibraryFilename = _T("$(TARGET_NAME)");
+        m_ImportLibraryFilename = _T("lib$(TARGET_OUTPUT_BASENAME).a");
         SetModified(true);
         return;
     }
@@ -114,7 +114,7 @@ void CompileTargetBase::SetDefinitionFileFilename(const wxString& filename)
 {
     if (filename.IsEmpty())
     {
-        m_DefinitionFileFilename = _T("$(TARGET_NAME)");
+        m_DefinitionFileFilename = _T("$(TARGET_OUTPUT_BASENAME).def");
         SetModified(true);
         return;
     }

I believe this cause the issue.

I have debugged how the link command was generated, and found that:

Code

switch (target->GetTargetType())
    {
        case ttDynamicLib:
            {
                TargetFilenameGenerationPolicy PrefixPolicy;
                TargetFilenameGenerationPolicy ExtensionPolicy;
                target->GetTargetFilenameGenerationPolicy(PrefixPolicy, ExtensionPolicy);

                wxString importLibraryFileNameString(target->GetDynamicLibImportFilename());
                Manager::Get()->GetMacrosManager()->ReplaceMacros(importLibraryFileNameString, target);
                wxFileName importLibraryFileName(importLibraryFileNameString);

                // apply prefix if needed
                if (   (PrefixPolicy == tgfpPlatformDefault)
                    && !importLibraryFileName.GetName().StartsWith(compiler->GetSwitches().libPrefix) )
                    importLibraryFileName.SetName(compiler->GetSwitches().libPrefix + importLibraryFileName.GetName());

                // apply extension if needed
                if (ExtensionPolicy == tgfpPlatformDefault)
                {
                    wxString current_ext   = importLibraryFileName.GetExt();
                    wxString requested_ext = compiler->GetSwitches().libExtension;

                    if (!current_ext.IsSameAs(requested_ext, false))
                        importLibraryFileName.SetFullName(importLibraryFileName.GetFullName() + wxFILE_SEP_EXT + requested_ext);
                }
                result = UnixFilename(importLibraryFileName.GetFullPath());
                QuoteStringIfNeeded(result);
                FixPathSeparators(compiler, result);
                m_StaticOutput[target] = result;

Here, the target is sdk, and I see the importLibraryFileNameString is "lib$(TARGET_OUTPUT_BASENAME).a", which finally becomes "libcodeblocks.a", and finally the command generator have such code:

Code

"g++.exe -shared -Wl,--output-def=$def_output -Wl,--out-implib=$static_output -Wl,--dll -Lbase\\tinyxml -LE:\\code\\cb\\wxWidgets-2.8.12\\lib\\gcc_dll -Ldevel -Lsdk\\scripting\\lib -Lsdk\\propgrid  .objs\\sdk\\co"...

and the value $static_output is replaced by "libcodeblocks.a", but it should be "devel\libcodeblocks.a" before rev7940.


BTW:
When debugging, I found a some code when the command generator try to generate the compile command, but I see for each file, there is always some function call like:

Code

macro.Replace(_T("$static_output"), m_StaticOutput[target]);

The interesting thing is, the value "macro" is always "g++.exe", and I believe it have no change to do a replacement actually. So it just waste some CPU cycles. Any comments.

[MortenMacFly]

...should be fixed in SVN now.

[ollydbg]

...should be fixed in SVN now.

I can confirm the fix in rev7949. Thanks.

[stahta01]

...should be fixed in SVN now.

I can confirm the fix in rev7949. Thanks.

Not fixed for me; I still am getting libcodeblocks.a and libwxpropgrid.a in the src folder instead of the devel folder.

I will try testing it again and see if I get different results.

Edit: I must have edited the codeblocks project file when checking it for causing the problem.
Once, I reverted all my project edits, the issue was fixed.

Tim S.

[headkase]

Using TDM-GCC 4.6.1 32-bit
Using wxWidgets 2.8.12 Unicode
Using Boost 1.49.0

Update SVN checkout to Code::Blocks SVN 7950.

Using SVN 7932 Nightly, build C::B SVN 7950.  Build successful, both project and plugins.
Using C::B SVN 7950, as built in previous step, build C::B SVN 7950.  Build successful, both project and plugins.

* libcodeblocks.a does get correctly placed into \devel when building with SVN 7950.
* both builds started with an untouched SVN source tree.
* both builds started with a default user-environment (deleted: AppData/Roaming/CodeBlocks).

Gentlemen, thank you: we have the technology.. Again..

Edit: @stahta01, just checked with a quick build of 7950 project only with 7950: libwxpropgrid.a and libwxscintilla_cb.a are also both present in \devel upon completion of the project build.

[stefanos_]

can someone check if there's a problem with indentation within nested code blocks please? It does awkward things occasionally. for example, if i type for() and press enter, it does not move the cursor at right; it just places it beneath f character...

[oBFusCATed]

stefanos_: As I said in IRC - provide exact steps to reproduce the problem, because it almost works here, but there is no way to reproduce it. For me it happens only once and then it works (for the 'for' example).

[stefanos_]

After I restarted Code::Blocks, I have tried to reproduce it and unfortunately could not; but it does so once in a while unexpectedly leaving me clueless of why is doing so.

Anyway, I will consider it as "false alarm".

My apologies.

[ham]

hi,

im working on Win7 32bit and always get this strange error, even if im in admin mode

Linking executable: ..\..\bin\Win32-gcc\My.exe
c:/home/firestarter/dev/sdk/mingw-tdm-4.6.1/bin/../lib/gcc/mingw32/4.6.1-dw2/../../../../mingw32/bin/ld.exe: reopening ..\..\bin\Win32-gcc\My.exe: Permission denied
c:/home/firestarter/dev/sdk/mingw-tdm-4.6.1/bin/../lib/gcc/mingw32/4.6.1-dw2/../../../../mingw32/bin/ld.exe: final link failed: Permission denied

this always! occures after i tested the exe, and is now locked by something, and my guess is CodeBlocks or Windows, theres nothing else im running, no AntiVir etc

EDIT:

i tried 10x to login this forum, but it didnt tell me to enable Cookies.

[Freem]

Check if your program is still running as a zombie.
When a program is running you can not modify it.

[oBFusCATed]

ham: Read this - http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28errors%29#Q:_My_build_fails_in_the_compile.2Flink.2Frun_step_with_a_Permission_denied_error.3F

[ham]

its definetly code::blocks

my app is returning with 0, theres no process with my name anywhere, but there is still a handle
left with PID 4 --> System that gets killed after a while (like 2min. or so)

furthermore

i also get this error without running the app, just pressing rebuild many times !!! Its not my fault, its CB.