I am trying to setup ISPConf3 on Fedora 20. This is a non-production server that is at my desk, so no hosting issues are involved. The FC20 installation was from a LiveDVD and included KDE & Gnome desktop environments. I use this server to learn web site development, server management for Linux and Windows (using VMs) and learning PHP/MySQL. I used "The Perfect Server - Fedora 15 x86_64 [ISPConfig 3]" as a guide. I previously setup "The Perfect Server - Fedora 13 x86_64 [ISPConfig 2]" on this server, with no problems and it ran for many years. But I felt it was way overdue for an upgrade, so I backed up my websites and config files and started from scratch. courier-authlib-0.66.1.tar.bz2 I have tried courier-authlib versions 0.64.0, 0.65.0, 0.66.0 and 0.66.1 and all get the same exact errors when the rpmbuild fails: Code: Making all in libs/gdbmobj In file included from testgdbm.C:1:0: gdbmobj.h:45:18: fatal error: string: No such file or directory #include <string> ^ compilation terminated. So, I uncompressed the package and edited libs/gdbmobj.h and changed line 45 from this: Code: #include <string> to this: Code: #include <string.h> I compressed the file, cleaned up the /root/rpmbuild directories and ran rpmbuild again: Code: sudo rpmbuild -ta courier-authlib-0.66.1.tar.bz2 Then I get the error: Code: In file included from testgdbm.C:1:0: gdbmobj.h:57:16: error: 'std::string' has not been declared int Open(std::string filename, const char *mode) ^ and 26 similar errors, but this is the first error received. I have followed the gdbmobj.h modification stated above on each version of courier-authlib and all get the exact same error. I have repeatedly read through the install docs in the courier-authlib package and on the courier website and have checked my build environment three times for all the neccessary prerequisites, and can find nothing to be missing. The output of rpmbuild does not list any log file(s) that might have more information in them. I opened the header file in Kdevelope and hovering the mouse over the line: Code: #include <string.h> , Kdev pops up a window stating all the functions in string.h which is located on /usr/include, along with a lot of other header files, so this makes me think that the build environment is sane and that changing <string> to <string.h> was the correct thing to do. Anyone have any ideas as to what is wrong, needs changed or added? Thanks
Got past the string problem and std:string error, but still doesn' build Think I need to try and actually create a 'Hello World' project in Kdevelope to check my build system. Created a new project: 1. Category: standard, Type:Terminal w/ 'Cmake C++', no version control, accepted default Cmake settings. 2. Immediately I get an error stating that iostream can not be found 3. I typed a new line '#include <string>;' and string cannot be found 4. I changed <string> to <string.h> and string(.h) is found. 5. After a while of Googling i realized that string and string.h are not the same thing. 1. string is the newer and conventional method for specifying an include file for c++ 2. string.h is used with c, not c++ and is considered not to be portable OK, this tells me that the gdbmobj.h file is most likely correct as '#include <string>;' and the problem is indeed with my build. Doing 'yum search', 'yum info' and repoquery didn't reveal to much. I did find a directory '/user/include' that did in fact include *.h files, but I also found '/user/include/c++/4.8.2' which I believed should have contained iostream and string, but didn't. Well, looks like it's time to reinstall. COMMAND:yum remove gcc This also removed: gcc-c++, libtool, systemtap, systemtap-devel Then I installed gcc, gcc-c++ (which requires libstdc++-devel), libtool and systemtap (which requiries systemtap-devel) Now I go back to Kdevelope and close and reopen my 'Hello World' project and the red squiggle underlining '#include <iostream>;' and '#include <string>;' are gone. I looked in '/user/include/c++/4.8.2' and immediately I can see that more files are present, including iostream and string. Looks like it is time to try running rpmbuild on courier-authlib again. Well the build got a lot further now and no red 'error' messages on the quickly scrolling text. There were no warning or error messages, but the rpm was not built the last few lines of the build are: Code: make[3]: *** [strpidt.lo] Error 2 make[3]: *** Waiting for unfinished jobs.... libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wall -c strhtimet.c -o strhtimet.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wall -c strinot.c -o strinot.o >/dev/null 2>&1 libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./.. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wall -c strofft.c -o strofft.o >/dev/null 2>&1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.2KTGnW (%build) Bad exit status from /var/tmp/rpm-tmp.2KTGnW (%build) RPM build errors: So no obvious warnings or error messages, but no rpm file left standing either,
That line #include <string> is indeed correct as it is for C++ I had no issue building the package with rpmbuild: Wrote: /home/bas/rpmbuild/SRPMS/courier-authlib-0.66.1-1.fc20.src.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-0.66.1-1.fc20.x86_64.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-devel-0.66.1-1.fc20.x86_64.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-userdb-0.66.1-1.fc20.x86_64.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-ldap-0.66.1-1.fc20.x86_64.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-mysql-0.66.1-1.fc20.x86_64.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-sqlite-0.66.1-1.fc20.x86_64.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-pgsql-0.66.1-1.fc20.x86_64.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-pipe-0.66.1-1.fc20.x86_64.rpm Wrote: /home/bas/rpmbuild/RPMS/x86_64/courier-authlib-debuginfo-0.66.1-1.fc20.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.f5b5s8 + umask 022 + cd /home/bas/rpmbuild/BUILD + cd courier-authlib-0.66.1 + rm -rf /home/bas/rpmbuild/BUILDROOT/courier-authlib-0.66.1-1.fc20.x86_64 + exit 0 $ rpm -qf /usr/include/c++/4.8.2/string libstdc++-devel-4.8.2-7.fc20.x86_64 So I would say, check your install. Did you ran "yum update"? Maybe there was a bug in the default install and it is fixed now. My system is up to date with testing repositories enabled. Hope you find the cause of the problem soon.
SOLVED - Fedora 20 - courier-authlib - problem running rpmbuild Finally got it to compile and the answer was indeed very weird! I repeated the build over 30 times using the 5 latest version of courier-authlib, but mostly version 0.66.1, looking for a common issue. Before each build I would manually cleanup the /root/rpmbuild directories and log out of the terminal session then open a new session to ensure the environmment variables are recreated. I expected doing it this way would eventually reveal a pattern of failures. But the patterns I expected to see never manifested. Instead my 'pattern' seemed t be randomness, OK i realize that sounds like an oxymoron, but bear with me. The errors did not always occur in the same module or on the same line of code. The pattern I saw was the lack of consistency, but even in this was I noticed was that the errors seemed to occur when libtool ran, and about half of the times that the error occured in libtool the error message was the same but the error occured in different '.c' of '.h' header files. I also noticed the at the end of the build process there were lines such as: blah...blah make[3] blah...blah make[2] blah...blah make[1] blah...blah make So I thought that maybe the numver were indicated different threads being run on different cores. So to me it seemed that some 'randomness' was getting injected somwehere, and where better for that to happen than in a cpu core. I used Gnome System Monitor to monitor the cpus, it's a quad core server, and saw that all four cores were in fact being used when rpmbuild was running. So I disabled all but one core. During boot I pressed the tab key to edit the boot command line and added 'maxcpus=1'. After the boot finished Gnome System Monitor confirmed that only one core was being used. I re-ran rpmbuild and it compiled on the first try. I repeated the process using either one core or all four cores and every time four cores were used the build would fail and every time only one core was used the build would succeed! The remaining builds I did using only one core and every one ofd those builds, byuilt the rpm without any errors and did so on the first try! Whoop! Whoop!
The Perfect Server Fedora 20 w/GUI My project to build the perfect Fedora 20 Server is nearly finished. The ISPConfig3 user interface comes up and I can indeed create web sites. Can't open phpMyAdmin yet, but php is working on the server, confirmed by using phpinfo().
