#9 clang's linker doesn't know the option --no-undefined

[Mojca Miklavec]

When compiling CB with clang on OS X the compilation breaks with

ld: unknown option: --no-undefined

The following workaround worked for me, but a better solution is needed (you either need to check whether the linker supports that flag or only conditionally include it where it is really needed – I don't know enough about compilers to be able to judge).

--- acinclude.m4.orig
+++ acinclude.m4
@@ -69,12 +69,10 @@ AC_ARG_ENABLE(debug, [AC_HELP_STRING([--enable-debug], [turn on debugging (defau
     if test "x$enable_debug" = "xyes"; then
         CFLAGS="-g -DDEBUG -DCB_AUTOCONF $CFLAGS"
         CXXFLAGS="-g -DDEBUG -DCB_AUTOCONF $CXXFLAGS"
-        LDFLAGS="-Wl,--no-undefined"
         AC_MSG_RESULT(yes)
     else
         CFLAGS="-O2 -ffast-math -DCB_AUTOCONF $CFLAGS"
         CXXFLAGS="-O2 -ffast-math -DCB_AUTOCONF $CXXFLAGS"
-        LDFLAGS="-Wl,--no-undefined"
         AC_MSG_RESULT(no)
     fi
 ])
--- configure.orig
+++ configure
@@ -11932,13 +11932,11 @@ fi
     if test "x$enable_debug" = "xyes"; then
         CFLAGS="-g -DDEBUG -DCB_AUTOCONF $CFLAGS"
         CXXFLAGS="-g -DDEBUG -DCB_AUTOCONF $CXXFLAGS"
-        LDFLAGS="-Wl,--no-undefined"
         { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
 $as_echo "yes" >&6; }
     else
         CFLAGS="-O2 -ffast-math -DCB_AUTOCONF $CFLAGS"
         CXXFLAGS="-O2 -ffast-math -DCB_AUTOCONF $CXXFLAGS"
-        LDFLAGS="-Wl,--no-undefined"
         { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
 $as_echo "no" >&6; }
     fi

Another problem of the current code is that any user-defined LDFLAGS get overridden. The setting should probably be something like:

LDFLAGS="<your additions> $LDFLAGS")

[Morten MacFly]

Applied in trunk. Thank you!

[Mojca Miklavec]

Thank you very much. (I hope that the patch won't affect other platforms as I don't know why that particular flag was needed in the first place.)

[Teodor Petrov]

In fact this is very useful flag for debugging broken builds.
It is needed to fail the linking of a dynamic library if there are undefined references in it. It finds problems at link time and not at load time.

@Jens: Could this be enabled conditionally for linux and disabled for osx?

[Mojca Miklavec]

If you do it conditionally, maybe just check whether the flag is supported with some autotools magic. That should be more robust than making it conditional on Mac. (I have no idea what other OSes have the same "problem")

[Teodor Petrov]

Probably this is better, but I don't know if it is possible, my autofu is limited.

[Mojca Miklavec]

Maybe something like

AX_CHECK_LINK_FLAG([--no-undefined], [LDFLAGS="$LDFLAGS --no-undefined"])

See: http://www.gnu.org/software/autoconf-archive/ax_check_link_flag.html

I don't know where to get the required m4 macro, so I copy-pasted the contents from the link into m4/ax_check_link_flag.m4 and that worked.

I noticed that cygwin already adds those flags:

case $host in
*-*-cygwin* | *-*-mingw*)
   SHARED_FLAGS="-shared -no-undefined -Xlinker --export-all-symbols"

   PLUGIN_FLAGS="-shared -no-undefined -avoid-version"

[Jens Lody]

Can you please test the attached patch (against actual trunk) ?

[Mojca Miklavec]

I first had to manually add the missing function to m4 as explained above.

After that this is what I get written out by configure:

checking for gawk... (cached) gawk
checking whether the linker accepts -Wl,--no-undefined... no
checking whether to enable debugging... no
checking for dirent.h that defines DIR... yes

However it might help to actually set the variable to no ;), from:

AX_CHECK_LINK_FLAG([-Wl,--no-undefined],[HAVE_NO_UNDEFINED=yes],[HAVE_NO_UNDEFINED=yes])

to

AX_CHECK_LINK_FLAG([-Wl,--no-undefined],[HAVE_NO_UNDEFINED=yes],[HAVE_NO_UNDEFINED=no])

[Mojca Miklavec]

I have to complete the compilation, but so far it looks good.

[Jens Lody]

Ooops, should be no in second case.
I attach a new patch, that also includes the (renamed) macro, and the shorter version of (re-)defining LD_FLAGS you have used in one of your comments.
That avoids unneeded if-clauses in acinclude.

[Mojca Miklavec]

I just wanted to say that CB compiled successfully with the previous patch (which is what I expected anyway). The configure phase of this patch works as expected and doesn't need external macros. I didn't try the complete build yet, but there's no --no-undefined in Makefiles and I get

checking whether the linker accepts -Wl,--no-undefined... no

so I'm pretty sure that the patch is ok. Thank you.

[Giancarlo Fissore]

Can you please specify which version of Mac OS you are using? This doesn't seem to work on 10.10 Yosemite.

Thanks!

[Mojca Miklavec]

On Mon, May 18, 2015 at 12:57 AM, Giancarlo Fissore wrote:

Can you please specify which version of Mac OS you are using? This doesn't
seem to work on 10.10 Yosemite.

I'm using 10.7, but from what I can remember there were no problems on
10.10. I can try again just in case.

(Just to be clear: I'm not claiming that CodeBlocks compiles
out-of-the-box on Yosemite. We still use a couple of other patches.)

Mojca

[Giancarlo Fissore]

(Just to be clear: I'm not claiming that CodeBlocks compiles out-of-the-box on Yosemite. We still use a couple of other patches.)

I tried to compile SVN revisions 10255 and 10303 but I got errors in both cases. So the patches you're talking about are not included in recent commits?

I could open a thread on the official CB forum to discuss building problems on Yosemite. Does that sound good to you?

Thank you again!

Giancarlo

[Jens Lody]

This issue, not (all) other Mac-issues, should be fixed in trunk.
Did you run the "bootstrap"-script after checking out the sources ?

@Mojca Miklavec: did you test it ?
If it does not work, can you look for lines containing "checking whether the linker accepts -Wl,--no-undefined" in config.log or a possible build-log ?

[Giancarlo Fissore]

This issue, not (all) other Mac-issues, should be fixed in trunk.

Indeed, this specific issue is fixed but other errors are coming out during the build process. However, Mojka wrote she was able to compile successfully after applying the patch, but this doesn't seem to be the case on Yosemite. Sorry if I didn't make this point clear in my precedent post.

Did you run the "bootstrap"-script after checking out the sources ?

Yes, I did.

[Mojca Miklavec]

On Tue, May 19, 2015 at 7:41 PM, Jens Lody wrote:

@Mojca Miklavec: did you test it ?

Yes, it works like a charm.

I wasn't even aware that the patch was already applied in the SVN
(along with many other patches like ticket #11 that hasn't been
closed; and one issues with pch that I probably didn't even report).

Actually, CB compiles for me without any patches now . Yay!

I think that plugins are currently not found, but I still need to
investigate that a bit. It used to help to set

ConfigManager::plugin_path_global = res_path + _T("/lib/codeblocks/plugins");

but now it doesn't, so I need to check what changed or what I misconigured.

I will send the latest version from SVN to the buildbots now to see
whether any other versions of OS X now fail to build CB. Building CB
against wxgtk 3.0 is broken, but that one looks more like a bug in
wxWidgets (I don't think that wxgtk gets much testing on OS X) and is
not really important.

Jens & others, many many many thanks for solving all the burning issues.

In any case this ticket can be closed.

[Mojca Miklavec]

It has nothing to do with this particular ticket, but the build on
10.9 and 10.10 indeed fails:

In file included from debuggergdb.cpp:10:
In file included from ../../../src/include/sdk.h:17:
In file included from ../../../src/include/sdk_precomp.h:13:
In file included from ../../../src/include/sdk_common.h:43:
../../../src/include/prep.h:33:75: error: use of overloaded operator
'==' is ambiguous (with operand types 'const
std::__1::shared_ptr<GDBWatch>' and 'int')
template<typename T=""> bool equals(T const& rhs) const { return
rhs == 0; }
~~~ ^ ~

See:
https://build.macports.org/builders/buildports-yosemite-x86_64/builds/3900

But anyway this is not related to this ticket. A new one should be opened.