Author Topic: Compiling 13.12 with rpmbuild fails with help_plugin (gzopen64 missing)  (Read 8834 times)

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
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:

Code
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Have you tried to build the latest trunk?

Code
./bootstrap
./configure
make dist
Are the commands needed to produce s tar.bz2 which contains a working spec file.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
I'll try that after this compile finishes. I updated zlib to the latest 1.2.8 version on the system (which gets rid of 1.2.3) and so far it's gone past compiling the help_plugin, so that's good. When this is done, I'll rollback zlib to the official 1.2.3 version, then try what you suggested.

Keep in mind that I'm not running configure myself, rpmbuild is doing it all. All I did was download the src.rpm, install it, then ran rpmbuild. Based on what you're suggesting, I think I have to grab the .tar.gz file and work off of that. Not sure if that will make an rpm but I guess I'll find out when I get there.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
When you have the tar.bz2 you can run rpmbuild -ta path/to/file.tar.bz2 and it should know what to do.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
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:
Code
[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:
Code
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.

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
Ok, so now I'm stuck. I have the newer zlib-1.2.8 library installed under /usr/local/{lib,include}. The system has the older 1.2.3 version installed because several system binaries rely on that. Nothing I can do there. But, running 'rpmbuild -bb codeblocks.spec' still uses the system zlib. How do I tell it to use the newer one instead?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Hm, I'm running centos 6.latest and I have no problems building packages from the svn head sources.
I've not used the latest version, but 979x and it worked fine.
I also have not installed any zlib library different from the standard one.

I've not tried the 13.12 packages to see if they work...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
Ok, let me try again tomorrow when I get back to the office. Right now the system is back to the default zlib package, which does not contain gzopen64() ... and the src.rpm does not compile because of that.

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
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):

Code
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.

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
Oops, I hit post too soon. It just bombed:
Code
/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.

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
So after removing all of my custom libraries under /usr/local, both the svn checkout as well as the tarballs available from the download pages compile without a hitch. I have a sneaky suspicion that because I had wxWidgets-3.0.0 and 3.0.1 installed and compiled against zlib-1.2.8, when I ran C::B's configure it was picking up that version of wx, but used the system's zlib (v1.2.3) and ran into problems. Only one way to test that which is to put the newer zlib and wx back on the system and see what happens ...

For the purpose of my original task, C::B is now compiled against all system libraries and I can install the rpms no problems.

For the purpose of finding out where it failed, that's just being a glutton for pain. :) Here I go ...

Offline kirash4

  • Multiple posting newcomer
  • *
  • Posts: 42
Ok, after a few recompiles with different libraries available I came to the following conclusion:
C::B will not compile against WxWidgets 3.0.x, at least not yet. So everything I said previously that related to that, ignore it.

HOWEVER, having zlib-1.2.8 installed in /usr/local will cause compiling C::B to fail, specifically the help_plugin is where it bombs complaining about gzopen64. As soon as I remove that library, C::B compiles just fine.

So I think it's safe to say that C::B does somewhere use that library, but fails when it comes to linking to it and I suspect because when it tries to link using -lz, it's trying to link against the system installed one, and not the newer one. And since the system one (1.2.3) does not have gzopen64, it fails.

So there you have it. I think I have now tried compiling C::B well over a dozen times, some with success, most not. As I said in my previous post, for the purpose of getting the rpm compiled and installed, that has been successful (but only after I removed all of my custom libraries from /usr/local.)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Compiling 13.12 with rpmbuild fails with help_plugin (gzopen64 missing)
« Reply #12 on: August 01, 2014, 09:56:36 am »
C::B will not compile against WxWidgets 3.0.x, at least not yet. So everything I said previously that related to that, ignore it.
SVN HEAD should be able to compile against wx3 at least using the -wx30 project files.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]