Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Unhappy with fixes for mac-compilation
Jenna:
I'm unhappy with some of the most recent patches for mac:
The first one https://cgit.jenslody.de/codeblocks/commit/?id=632970a8d8c4c0b798960c7152bb6c0a57714c1d doubles code for wx_osx, but only for hunspell, what about the other conditionals ?
Does it work, if we use the same conditionals for wx_gtk, wx_osx, wx_mac, etc ?
--- Code: (diff) ---diff --git a/configure.ac b/configure.ac
index f0ebdd4..dbaf6e3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -237,6 +237,27 @@ case $WX_BASENAME in
AC_CHECK_PROG(SETFILE, SetFile, SetFile, /Developer/Tools/SetFile)
MACSETFILE="\$(SETFILE)"
;;
+ *wx_osx*)
+ AC_MSG_RESULT(wxOSX)
+
+ if test "x$BUILD_SPELLCHECKER_TRUE" = "x" ; then
+
+ AC_CHECK_PROG(HAVE_PKG_CONFIG, pkg-config, yes, no)
+ ifdef([PKG_CHECK_MODULES],[],[
+ define([PKG_CHECK_MODULES],
+ [ echo "You don't have pkg.m4 properly installed" >&2
+ exit 1
+ ])
+ ])
+ PKG_PROG_PKG_CONFIG
+
+ if test "x$HAVE_PKG_CONFIG" = "xyes"; then
+ PKG_CHECK_MODULES([HUNSPELL], [hunspell])
+ fi
+ fi
+ CB_HUNSPELL_CFLAGS="$HUNSPELL_CFLAGS"
+ CB_HUNSPELL_LIBS="$HUNSPELL_LIBS"
+ ;;
*)
AC_MSG_RESULT(other)
;;
--- End code ---
This one removes flags that are not supported by clang (on mac?, which version). If I remember correctly, they are no problem on linux with clang.
A proper solution would be to remove them only for compilers, that do not support them.
https://cgit.jenslody.de/codeblocks/commit/?id=9613c554588da2d4851d6de9c16a0b5bce8b579c
--- Code: (diff) ---diff --git a/acinclude.m4 b/acinclude.m4
index 1a6d145..ed0820b 100644
--- a/acinclude.m4
+++ b/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
])
--- End code ---
I do not have a recent mac to test, I only have SnowLeopard on a VM, so that's the only stuff I can test.
But Apple changed/restricted so much in the last years (as far as I know), that it might work here, but not with newer releases.
oBFusCATed:
See this https://sourceforge.net/p/codeblocks/tickets/9/#e4a8 for the no-undefined issue.
The person that has reporting the problems for osx is very active and can test patches on osx.
So if you can think of changes that are better just post patches in the respective tickets and he'll happily test them, I think.
MortenMacFly:
Well the rationale to apply the first patch was:
We cannot test them as we don't have Mac devs.
It works obviously as stated in the mentioned ticket.
It does not harm the other build process
The rationale to apply the second patch them was:
Its not something that we need at runtime, its a check to verify that we did actually nothing wrong. So the correct way would be to fix the build in the first place and not build something that throws when you did it wrong. Its basically a Linux only thing, as on Windows this is of on use, too.
So to "re-implement" it I would encapsulate it into a Linux-only environment. However, the second remark in the ticket (that it overrides LDFLAGS completely) is certainly true. So there was an error in doing it the way it was anyway.
Also, on recent Mac's there is no GCC any longer, so sooner or later we have to face clang or basically abandon Mac. Itsnot a nice situation, but if Mac people find out that something works I think we should seriously consider to apply it... at least if it does no harm to the rest. :-)
Jenna:
This patch should (hopefully) fix it correctly (without overriding LDFLAGS):
diff removed
Jenna:
--- Quote from: MortenMacFly on May 03, 2015, 03:05:50 pm ---Well the rationale to apply the first patch was:
We cannot test them as we don't have Mac devs.
It works obviously as stated in the mentioned ticket.
It does not harm the other build process
--- End quote ---
But it blows up the code (or autoconf-files in this case) and is probably not needed, or we should add am own check-function for all the stuff we check in the wx_gtk-section.
This should be not so hard and less error-prone.
--- Quote from: MortenMacFly on May 03, 2015, 03:05:50 pm ---The rationale to apply the second patch them was:
Its not something that we need at runtime, its a check to verify that we did actually nothing wrong. So the correct way would be to fix the build in the first place and not build something that throws when you did it wrong. Its basically a Linux only thing, as on Windows this is of on use, too.
So to "re-implement" it I would encapsulate it into a Linux-only environment. However, the second remark in the ticket (that it overrides LDFLAGS completely) is certainly true. So there was an error in doing it the way it was anyway.
Also, on recent Mac's there is no GCC any longer, so sooner or later we have to face clang or basically abandon Mac. Itsnot a nice situation, but if Mac people find out that something works I think we should seriously consider to apply it... at least if it does no harm to the rest. :-)
--- End quote ---
Clang is indeed an option, no matter what Apple does.
But much more important is to get the wx3 stuff working because at least Debian 8 (actual stable) does no longer provide wx2.8 and I guess more distributions will follow (sooner or later).
So we should try to make a release as soon as possible and seriously start fixing the wx3 issues.
Navigation
[0] Message Index
[#] Next page
Go to full version