I'm trying to compile a 13.12 rpm on CentOS 6.5 (Final) x86_64 and it runs for quite some time then fails on the help_plugin. I'm going to try to gether as much information as I think is needed here, but if i miss anything, please ask:
Source file was obtained from http://www.codeblocks.org/downloads/25
System is running CentOS 6.5 (Final)
/bin/arch => x86_64
gcc -v => gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
make -v => GNU Make 3.81
- What's the problem? & - What did you do to when it happened?
After unpacking the src.rpm and issuing 'rpmbuild -bb SPECS/codeblocks.spec' the compile runs for a while then errors out while working the help_plugin:
libtool: link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbeginS.o .libs/help_common.o .libs/HelpConfigDialog.o .libs/help_plugin.o .libs/man2html.o .libs/MANFrame.o -Wl,-rpath -Wl,/root/rpmbuild/BUILD/codeblocks-13.12-9501/src/sdk/.libs ../../../sdk/.libs/libcodeblocks.so -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -lbz2 -lz -lpthread -ldl -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtfastmath.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crtn.o -m64 -mtune=generic -Wl,--no-undefined -pthread -pthread -Wl,-soname -Wl,libhelp_plugin.so -o .libs/libhelp_plugin.so
.libs/MANFrame.o: In function `MANFrame::GetManPage(wxString, int)':
/root/rpmbuild/BUILD/codeblocks-13.12-9501/src/plugins/contrib/help_plugin/MANFrame.cpp:360: undefined reference to `gzopen64'
collect2: ld returned 1 exit status
make[5]: *** [libhelp_plugin.la] Error 1
make[5]: Leaving directory `/root/rpmbuild/BUILD/codeblocks-13.12-9501/src/plugins/contrib/help_plugin'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/root/rpmbuild/BUILD/codeblocks-13.12-9501/src/plugins/contrib/help_plugin'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/root/rpmbuild/BUILD/codeblocks-13.12-9501/src/plugins/contrib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/rpmbuild/BUILD/codeblocks-13.12-9501/src/plugins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/rpmbuild/BUILD/codeblocks-13.12-9501/src'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.HGXajM (%build)
- Can you reproduce it? How?
Yep, rerun rpmbuild again. Or even, manually trying to compile it (run rpmbuild -bp first, then make)
- What release of Code::Blocks are you using?
13.12
- Which was the latest release that did not have this problem?
Unknown as this is the first (and only) source install I'm trying.
POSSIBLE REASON:
It appears that the version of zlib that comes with CentOS (and Ubuntu) does not contain gzopen64(). The most recent rpm that's available is 1.2.3-29.el6 and does not appear to have any reference anywhere for a gzopen64(). Grabbing the most recent 1.2.8 version from zlib.net does have gzopen64 in it. So it appears I'll have to install a more recent version of zlib from source for the help_plugin to compile. There isn't any recent rpm for it, at least not from the official channels ...
Can the developers verify this somehow?
Have you tried to build the latest trunk?
./bootstrap
./configure
make dist
Are the commands needed to produce s tar.bz2 which contains a working spec file.
That didn't work. Let me explain:
After having installed zlib-1.2.8 as a system library, C::B did compile successfully. However, because several system utilities rely specifically on zlib 1.2.3, I started getting errors with both yum and rpm, so installing the newly compiled C::B proved fruitless. In order for yum/rpm to work, I had to rollback zlib to 1.2.3 at which point installing C::B would fail because the correct library version was no longer on the system. Well pooh ... I think the solution is to install zlib1.2.8 as an additional library (as opposed to replacing the system one) and recompiling C::B that way.
Moving on, following what you suggested above. I downloaded the .tar.gz source file, uncompressed, ran bootstrap, followed by configure. But, when I tried to compile I got this:
[6] 19:25:33 <root@elysium:/usr/local/src/codeblocks-13.12> make dist
{ test ! -d "codeblocks-13.12-0" || { find "codeblocks-13.12-0" -type d ! -perm -200 -exec chmod u+w {} ';' && rm -fr "codeblocks-13.12-0"; }; }
test -d "codeblocks-13.12-0" || mkdir "codeblocks-13.12-0"
(cd src && make top_distdir=../codeblocks-13.12-0 distdir=../codeblocks-13.12-0/src \
am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[1]: Entering directory `/usr/local/src/codeblocks-13.12/src'
make[1]: *** No rule to make target `exchndl.dll', needed by `distdir'. Stop.
make[1]: Leaving directory `/usr/local/src/codeblocks-13.12/src'
make: *** [distdir] Error 1
[7] 19:26:28 <root@elysium:/usr/local/src/codeblocks-13.12>
For the record, the configure command ran with no problems. When it started, it displayed these three lines at the very top:
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
So it's a bit of a mystery to me why it's trying to build a windows .dll ... unless that's part of the distro building.
Does this have to do more with wxWidgets than it does C::B? I have the official 2.8.12 rpm installed, but I also have 3.0.0 and 3.0.1 compiled from source and installed in /usr/local/src. During C::B's configure phase it finds 3.0.1 and fails miserably to compile (which I would kinda expect since 3.0.1 was just released and unless there's a bunch of robots working 24/7 on C::B, that would not have been implemented just yet):
Making all in src
make[1]: Entering directory `/usr/local/src/trunk/src'
Making all in include
make[2]: Entering directory `/usr/local/src/trunk/src/include'
rm -f ../../src/include/sdk_precomp.h.gch
g++ -DHAVE_CONFIG_H -I/usr/local/lib/wx/include/gtk2-unicode-3.0 -I/usr/local/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -I../../src/include/mozilla_chardet/mfbt -I../../src/include/mozilla_chardet/nsprpub/pr/include -I../../src/include/mozilla_chardet/xpcom -I../../src/include/mozilla_chardet/xpcom/base -I../../src/include/mozilla_chardet/xpcom/glue -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -o ../../src/include/sdk_precomp.h.gch -xc++-header ./sdk_precomp.h
In file included from ./sdk_common.h:140,
from ./sdk_precomp.h:13:
./logmanager.h: In function ‘wxString F(const wxChar*, ...)’:
./logmanager.h:24: error: cannot convert ‘const wxStringCharType*’ to ‘const wxChar*’ in assignment
In file included from ./sdk_common.h:144,
from ./sdk_precomp.h:13:
./toolsmanager.h: At global scope:
./toolsmanager.h:46: error: ‘ToolsList::Node’ has not been declared
make[2]: *** [../../src/include/sdk_precomp.h.gch] Error 1
make[2]: Leaving directory `/usr/local/src/trunk/src/include'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/trunk/src'
make: *** [all-recursive] Error 1
I ended up completely removing 3.0.0 and 3.0.1 as they were just test installs. In retrospect, I should've just told the configure command where wx was (in /usr as opposed to having it look in /usr/local) and it probably would've worked just fine.
However, it does bring up the question of why is it finding the newer one in /usr/local but it would not find the newer zlib, also in the same location. Does that have more to do with wx and pkg-config, or just the way C::B's configure script looks for libraries, specifically wx ones?
Anyway, it's compiling the svn source right now and that's going to take a bit because I triggered one thread only instead of all 8 ... I hate interruptions at my office.
Oops, I hit post too soon. It just bombed:
/bin/sh ../../libtool --tag=CXX --mode=link g++ -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -Wl,--no-undefined -o codeblocks app.o appglobals.o backtracedlg.o breakpointsdlg.o compilersettingsdlg.o cpuregistersdlg.o crashhandler.o debugger_interface_creator.o debuggermenu.o debuggersettingscommonpanel.o debuggersettingsdlg.o debuggersettingspanel.o disassemblydlg.o dlgabout.o dlgaboutplugin.o editkeywordsdlg.o editorconfigurationdlg.o environmentsettingsdlg.o examinememorydlg.o find_replace.o infopane.o main.o notebookstyles.o prefix.o printdlg.o projectmanagerui.o projectdepsdlg.o projectoptionsdlg.o recentitemslist.o scriptconsole.o scriptingsettingsdlg.o splashscreen.o startherepage.o switcherdlg.o threadsdlg.o virtualbuildtargetsdlg.o watchesdlg.o ../sdk/libcodeblocks.la -pthread -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8 -pthread -L/usr/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lpthread -ldl
libtool: link: cannot find the library `=/usr/local/lib/libpng16.la' or unhandled argument `=/usr/local/lib/libpng16.la'
make[3]: *** [codeblocks] Error 1
make[3]: Leaving directory `/usr/local/src/trunk/src/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/trunk/src/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/trunk/src'
make: *** [all-recursive] Error 1
Again, it's using libraries located in /usr/local/lib as opposed to those in /usr, but even so, that specific file does exist.
Looks like I'm going to have to remove all of my custom libraries out of /usr/local/lib so it only uses the system installed ones.