#12 wrong filename for libcodeblocks in Makefile.in

[Mojca Miklavec]

When compiling Code::Blocks on OS X I need to use the following workaround:

--- src/src/Makefile.in.orig
+++ src/src/Makefile.in
@@ -416,7 +416,7 @@ AM_CPPFLAGS = $(WX_CXXFLAGS) \

 # wxAUI uses GTK+ libraries on wxGTK
 # codeblocks_LDFLAGS = $(WX_GTK2_LIBS)
-codeblocks_LDADD = ../sdk/libcodeblocks.la \
+codeblocks_LDADD = ../sdk/.libs/libcodeblocks.dylib \
            $(WX_LIBS) \
            $(WX_GTK2_LIBS)

The code has been recently changed (r9132 by jenslody in June 2013; previously the Makefile used "-L../sdk -lcodeblocks" which didn't work properly), but the hardcoded library name and extension should be fixed to work properly on Mac (I'm not familiar enough with autotools to know how to fix this properly without hardcoding names).

[Morten MacFly]

Assigned to jenslody. Hopefully he will take care...

[Jens Lody]

We use the *.la-construct in several Makefiles in our source-tree.
Is this the only place where the issue occurs ?
Does the libcodeblocks.la-file exist ?
If yes, what is the content (it's a text-file).
What is the exact error message you get ?

[Mojca Miklavec]

It was in version 13.12 (released 1.5 years ago). Or at least that was the only place where I had to make a patch of this particular type back then (there were numerous other problems reported in subsequent tickets).

I need to check how the latest version behaves.

[Mojca Miklavec]

Regarding other questions about .la files: I can test (should I test version 13.12 or the latest SVN checkout?), but from what I remember .la files are usually deleted after the build (by the package manager) even if some files are created during the build process.

See also https://trac.macports.org/ticket/38010 and https://wiki.debian.org/ReleaseGoals/LAFileRemoval

[Mojca Miklavec]

It took me a while to be able to start testing on the latest version because none of the bugs from 8 to 13 have been resolved so far, but luckily at least the code didn't diverge too much, so it wasn't so painful to use the old patches.

While working on this report, can you please also take a look at these?

https://sourceforge.net/p/codeblocks/tickets/8/
https://sourceforge.net/p/codeblocks/tickets/9/
https://sourceforge.net/p/codeblocks/tickets/10/
https://sourceforge.net/p/codeblocks/tickets/11/
https://sourceforge.net/p/codeblocks/tickets/13/
http://forums.codeblocks.org/index.php?topic=18394.0

It's a bit inconvenient to build your software when it needs so many patches and the tickets stay open "forever".

[Mojca Miklavec]

There exists a file src/sdk/libcodeblocks.la:

# libcodeblocks.la - a libtool library file
# Generated by libtool (GNU libtool) 2.4.6
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname='libcodeblocks.0.dylib'

# Names of this library.
library_names='libcodeblocks.0.dylib libcodeblocks.dylib'

# The name of the static archive.
old_library=''

# Linker flags that cannot go in dependency_libs.
inherited_linker_flags='  -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL'

# Libraries that this one depends upon.
dependency_libs=' -L/opt/local/lib -L/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib -lwx_osx_cocoau_aui-3.0 -lwx_osx_cocoau_propgrid-3.0 -lwx_osx_cocoau_richtext-3.0 -lwx_osx_cocoau_xrc-3.0 -lwx_osx_cocoau_webview-3.0 -lwx_osx_cocoau_html-3.0 -lwx_osx_cocoau_qa-3.0 -lwx_osx_cocoau_adv-3.0 -lwx_osx_cocoau_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lpthread -ldl'

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libcodeblocks.
current=0
age=0
revision=1

# Is this an already installed library?
installed=no

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/opt/local/lib'

There is a tiny chance that I just tried to adapt the patch that I absolutely needed in earlier versions of Code::Blocks when upgrading to a newer version some time in the past. I probably thought that .la was a library (.a / .so) that needed to be renamed to .dylib on Mac anyway and didn't even test whether the new code works without modifications.

(Previously there was a defunct "-L../sdk -lcodeblocks" in the code). It might be that this patch is actually not needed at all. This would probably also explain why it works everywhere else. I did a clean rebuild without the patch, but now the build throws an error at

mainframe.cpp:434:29: error: use of undeclared identifier 'wxStandardPathsBase'
  wxString config_folder =  wxStandardPathsBase::Get().GetUserDataDir();
                            ^
1 error generated.

So I cannot tell whether it works or not without solving that new problem first.

[Mojca Miklavec]

Ok, the other problem was solved with

--- a/src/tools/cb_share_config/mainframe.cpp
+++ b/src/tools/cb_share_config/mainframe.cpp
@@ -9,6 +9,7 @@

 #include "mainframe.h"

+#include <wx/stdpaths.h>
 #include <wx/file.h> // wxFile, wxTempFile
 #include <wx/filedlg.h>
 #include <wx/msgdlg.h>

and after that the build succeeded.

Feel free to close this ticket as invalid and thanks a lot for pointing it out to me that I was doing the wrong thing ever since the sources were fixed a while ago.

(But you can fix that other wx-related problem by adding stdpaths.h. Or should I open a new ticket?)

[Morten MacFly]

Applied the (non-related) patch in SVN - thanks.
Closed this one marking it invalid.
Nag us with the other stuff in the forums, if you like... There are not much Mac devs around for C::B, unfortunately.