It failed when I ran cmake. I never ran make after the failure when I was compiling manually.
During all of this testing I compiled from the 5.0.1 and the 5.0.2 tar files. cmake gives a nice summary table when it's done (Configure results (user options):) and 5.0.2 does not. See the end of the output below. Is there any way to get the nice output from 5.0.2 and when compiling from git? I like the table format, it's much easier to read. ================ 5.0.1 ================ -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success -------- KMyMoney 5.0.0 -------- Configure results (user options): -------------------------------------------- GpgME Encryption: yes KDE PIM holidays: yes KDE PIM addressbook: yes OFX plugin: yes OFX supports CLIENTUID: yes KBanking plugin: yes weboob plugin: no iCalendar export plugin: yes SQLCipher plugin: no QWebEngine: no -------------------------------------------- Configure results (developer options): -------------------------------------------- Qt-Designer library support: no Generate modeltest code: no Generate API documentation with Doxygen: yes Build type: RelWithDebInfo -- Configuring done -- Generating done -- Build files have been written to: /usr/local/src/kmm/temp/kmymoney-5.0.1/build ================ ================ ================ 5.0.2 ================ -- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success Build type: RelWithDebInfo -- The following REQUIRED packages have not been found: -- The following OPTIONAL packages have not been found: -- The following features have been enabled: * Encryption, It allows encrypting your financial data. * Doxygen, Generate API documentation with Doxygen (for devs only). * Address book, It allows fetching payee information from KDE PIM system. * Holidays, It allows fetching holidays from KDE PIM system. * Forecast view, It adds possibility to calculate forecasts. * Reports view, It adds possibility to display chart and table reports. * Budget view, It adds possibility to plan a budget. * Online job outbox view, It adds outbox for sending online jobs. * SQL Storage, It allows storing your financial data in SQL database. * OFX Importer, It allows importing OFX files (have client uid version: yes) * KBanking, Interface for the following online banking protocols: HBCI, EBICS, OFX Direct Connect, Paypal * iCalendar, iCalendar integration. * QIF Importer, It allows importing QIF files. * QIF Exporter, It allows exporting QIF files. * GNC Importer, It allows importing GNUCash files. * CSV Importer, It allows importing CSV files. * CSV Exporter, It allows exporting CSV files. -- The following features have been disabled: * SQLCipher, It allows encrypting your SQLite3 database. * IBAN/BIC data, Adds predefined IBAN/BIC numbers to KMyMoney (note: doesn't work yet). * Weboob, Online banking interface using Weboob. * Model test, Generate modeltest code (for devs only). * QtDesigner, Qt-Designer library support (for devs only). -- Configuring done -- Generating done -- Build files have been written to: /usr/local/src/kmm/temp/kmymoney-5.0.2/build ---- Brendan Coupe ---- Brendan Coupe On Mon, Nov 12, 2018 at 4:57 PM Jack <ostrof...@users.sourceforge.net> wrote: > > The build option that is not supported is doing the build right in the > top source dir, called an "in source" build. Having the build dir > below that or outside that are both OK as far as I can tell. Both are > called "out of source builds" or something like that. If you build > from tar or clean up the whole thing after building from a git clone, > then your way make perfect sense. I maintain my copy of the git > repository, and alternately check out master and 5.0 branches. I have > several build directories - for master vs. 5.0, for debug on or off, > for testing ninja vs. make, etc. I actually have more than one > directory to install different versions at the same time. In my case > making build directories within the repository would probably work, but > I prefer to keep the source tree clean. I'm also not sure if I would > need to put anything in .gitignore to keep "git status" from pointing > out all the "extraneous" stuff. > > The thing that changed might have been either cmake or make. It is > make that is failing, but it is possible that cmake changed how it > writes out that makefile. As long as we now know what the issue is, we > can avoid it, and recognize it if anyone else complains in the future. > I wish I had enough spare time to try it with various versions of both > make and cmake, but reality says that is not going to happen. > > Jack > > On 2018.11.12 18:15, Brendan Coupe wrote: > > I agree, something appears to have changed in the most recent version > > of cmake. > > > > My build directory has always been added to the source directory. I > > think you've questioned that before but Thomas is the one that told > > me to do it that way and he came to the rescue and said it's fine and > > I think it's how he does it. cmake is what fails. I can try moving > > the build directory outside of the source with the : in the directory > > name for the source but not the build but I'm pretty tired of > > compiling it right now:-) It's not a great long term option since I > > compile fairly often and have to clean up the old versions. That > > would double my clean up. > > > > I'm back to running a fresh build from the master so I'm happy. > > > > ---- > > Brendan Coupe > > > > > > On Mon, Nov 12, 2018 at 2:55 PM Jack Ostroff <ostrof...@aya.yale.edu> > > wrote: > > > > > On 2018.11.12 16:27, Jack wrote: > > > > OK, I've now been able to duplicate it - it does NOT happen if the > > > > build directory is not under the source directory. It does > > happen if > > > > the build directory is under the source directory. I still > > haven't > > > > figured out exactly what is failing, but I finally do see the > > > > relevant files left under CMakeFiles/CMakeTmp. > > > Got it (sort of). the relevant error occurs when cmake runs gmake > > > (symlink from make) on the Makefile it creates to compile the cxx > > > program which tests for the presence of libIcal. > > > > > > gmake[2]: Entering directory > > > > > > > > '/local/data/jack/KDE/KMM/kmymoney-MASTER-2018.11.12-13:15:37/build/CMakeFiles/CMakeTmp' > > > CMakeFiles/cmTC_98fb0.dir/build.make:64: *** target pattern > > contains no > > > '%'. Stop. > > > > > > A bit of googling says that error is perhaps not well worded, but > > does > > > occur because of the colon in the path name in line 64 of that > > > build.make file (buried under CMakeTmp.) The colon confuses the > > make > > > about what rule it is trying to deal with on that line. > > > > > > Because your script has worked for years, I suspect either something > > > may have changed in a recent version of make, or perhaps you have > > moved > > > the build dir from outside to under the src dir? > > > > > > > On 2018.11.12 15:24, Brendan Coupe wrote: > > > >> I figured it out. After trying many manual and script based > > builds I > > > >> started to see a pattern. It only failed to build when it was in > > the > > > >> directory that my script created with a date/time stamp. I've > > been > > > >> using this script for 10+ years without a problem. The download > > > >> directory names looked like this: > > > >> > > > >> kmymoney-MASTER-2018.11.12-13:15:37 > > > >> > > > >> Simply changing the : to . solve the cmake problem. > > > >> > > > >> kmymoney-MASTER-2018.11.12-13.15.37 > > > >> > > > >> Sometimes I really hate computers. > > > >> > > > >> Thanks for all of your help Jack. > > > >> > > > >> ---- > > > >> Brendan Coupe > > > >> > > > >> > > > >> On Sun, Nov 11, 2018 at 4:53 PM Jack > > > >> <ostrof...@users.sourceforge.net> > > > >> wrote: > > > >> > > > >> > On 2018.11.10 20:25, Brendan Coupe wrote: > > > >> > > I'm not sure I explained what I've tried well enough for you > > to > > > >> > > understand. While I normally use compile and install scripts > > > >> that I > > > >> > > wrote a long time ago (used with cvs and svn) I tried > > compiling > > > >> from > > > >> > > the official tar file for the recently released 5.0.2. It > > worked > > > >> fine > > > >> > > on both my older upgraded (F28 to F29) and on my new clean > > F29 > > > >> > > install. > > > >> > > > > > >> > > I think this means my systems are fine. > > > >> > > > > > >> > > I just manually downloaded both the master and 5.0 branches > > from > > > >> the > > > >> > > KMM git web site. Both compile fine. When I run the git clone > > > >> command > > > >> > > that is in my script and then run cmake, it fails just like I > > > >> > > mentioned in my original email. Except for how I download the > > > >> source > > > >> > > code, I'm running the exact same steps that I use for the > > > >> manually > > > >> > > downloaded zip versions of KMM (5.0.2 release, 5.0 branch & > > > >> master > > > >> > > branch) and they all succeed. > > > >> > > > > > >> > > When I compare the size of the source code directories, all > > of > > > >> the > > > >> > > zip files result in about 21k of source files. The git > > downloaded > > > >> > > folder is about 70k. I suspect git is the problem and it may > > not > > > >> be > > > >> > > related to F29 since I started having problems compiling from > > > >> source > > > >> > > several weeks before I upgraded to F29. There is a .git > > > >> directory in > > > >> > > the git clone directory that is about 49k so it's probably > > the > > > >> > > difference. > > > >> > You could do a diff -r comparing the source dir from the > > zip/tar > > > >> and > > > >> > the source downloaded from git. The only difference (off the > > top > > > >> of my > > > >> > head) should be the presence of the .git directory, as you > > > >> suspect. If > > > >> > there are other differences, see what they are. Be sure that > > the > > > >> zip > > > >> > and git are both at the same commit of the same branch, which I > > > >> think > > > >> > you are already doing correctly. > > > >> > > > > >> > > The git command that worked until 4 to 6 weeks ago is: > > > >> > > > > > >> > > git clone git://anongit.kde.org/kmymoney $BRANCH $KMMDIR > > > >> > > > > > >> > > Is this correct? > > > >> > I don't think so. I don't think (but am not absolutely > > certain) > > > >> that > > > >> > you shouldn't specify the branch. Do the git clone first > > > >> (specifying > > > >> > the directory is ok) and then do "git checkout branch" to > > switch. > > > >> > Looking at "git clone --help" however, you could also do "git > > > >> clone URL > > > >> > --branch $BRANCH" to not need to do the checkout. > > > >> > > > > > >> > I'm also still curious whether there is any hint of what went > > > >> wrong in > > > >> > those files or folder after the cmake fails. > > > >> > > > > >> > In theory, the git and tarball/zip of the same branch/commit > > > >> should be > > > >> > identical, so the issue may be either that the git clone does > > have > > > >> some > > > >> > difference, or that cmake is possibly aware it is running in a > > git > > > >> > repository and doing something different. (I think the latter > > is > > > >> > unlikely, but I'm grabbing at straws here.) > > > >> > > > > >> > Jack > > > >> > > ---- > > > >> > > Brendan Coupe > > > >> > > > > > >> > > > > > >> > > On Sat, Nov 10, 2018 at 3:44 PM Jack > > > >> <ostrof...@users.sourceforge.net> > > > >> > > wrote: > > > >> > > > > > >> > > > On 2018.11.10 13:35, Brendan Coupe wrote: > > > >> > > > > I downloaded the source for 5.0.2 and compiled it > > without any > > > >> > > > > problems. I > > > >> > > > > tried the 5.0 and master branches again and they failed > > on > > > >> iCal > > > >> > > again. > > > >> > > > > Seems that there is something off with the source on > > git??? > > > >> > > > I doubt there is actually anything "wrong." I suspect > > some bad > > > >> > > > interaction caused by F29 using a newer version of some > > tool. > > > >> > > Again - > > > >> > > > right after you get the failure, have you checked the > > files and > > > >> > > > directory I suggested? I'll also try compiling from git > > head > > > >> with > > > >> > > gcc > > > >> > > > 8. > > > >> > > > > > > >> > > > > > > > >> > > > > ---- > > > >> > > > > Brendan Coupe > > > >> > > > > > > > >> > > > > > > > >> > > > > On Thu, Nov 8, 2018 at 11:44 AM Jack > > > >> > > <ostrof...@users.sourceforge.net> > > > >> > > > > wrote: > > > >> > > > > > > > >> > > > > > I am able to run cmake (3.11.4) with gcc 8.2.0, with > > either > > > >> > > make or > > > >> > > > > > ninja, with no errors. In your build directory, is > > there > > > >> > > anything > > > >> > > > > > useful in CMakeFiles/CMakeOutput.log or CMakeError.log? > > > >> Also > > > >> > > look > > > >> > > > > in > > > >> > > > > > CMakeTmp/ > > > >> > > > > > > > > >> > > > > > Another possible approach: cmake > > --all-other-parameters > > > >> > > > > > > > > >> --trace-source=/path/to/source/cmake/modules/FindLinical.cmake > > > >> > > > > > --debug-trycompile /path/to/source > > > >> > > > > > Then see if anything useful shows up in the above > > places. > > > >> > > > > > > > > >> > > > > > On 2018.11.07 20:29, Brendan Coupe wrote: > > > >> > > > > > > Fedora got 5.0.1 to compile so there must be some > > hope:-) > > > >> > > > > > > > > > >> > > > > > > I added the --debug-output option to cmake. The > > output > > > >> from > > > >> > > just > > > >> > > > > after > > > >> > > > > > > the weboob errors are copied below: > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > =========================================================================== > > > >> > > > > > > > > > >> > > > > > > CMake Warning (dev) at > > cmake/modules/FindLibical.cmake:59 > > > >> > > > > (try_run): > > > >> > > > > > > Policy CMP0066 is not set: Honor per-config flags > > in > > > >> > > > > try_compile() > > > >> > > > > > > source-file signature. Run "cmake --help-policy > > > >> CMP0066" > > > >> > > for > > > >> > > > > policy > > > >> > > > > > > details. Use the cmake_policy command to set the > > > >> policy and > > > >> > > > > > > suppress this > > > >> > > > > > > warning. > > > >> > > > > > > > > > >> > > > > > > For compatibility with older versions of CMake, > > > >> try_compile > > > >> > > is > > > >> > > > > not > > > >> > > > > > > honoring > > > >> > > > > > > caller config-specific compiler flags (e.g. > > > >> > > > > CMAKE_C_FLAGS_DEBUG) > > > >> > > > > > > in the > > > >> > > > > > > test project. > > > >> > > > > > > Call Stack (most recent call first): > > > >> > > > > > > CMakeLists.txt:242 (find_package) > > > >> > > > > > > This warning is for project developers. Use > > -Wno-dev to > > > >> > > suppress > > > >> > > > > it. > > > >> > > > > > > > > > >> > > > > > > Called from: [2] > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindLibical.cmake > > > >> > > > > > > [1] > > > >> > > > > > > > > > >> > > > > > >> > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt > > > >> > > > > > > CMake Warning (dev) at > > cmake/modules/FindLibical.cmake:59 > > > >> > > > > (try_run): > > > >> > > > > > > Policy CMP0056 is not set: Honor link flags in > > > >> try_compile() > > > >> > > > > > > source-file > > > >> > > > > > > signature. Run "cmake --help-policy CMP0056" for > > > >> policy > > > >> > > > > details. > > > >> > > > > > > Use the > > > >> > > > > > > cmake_policy command to set the policy and suppress > > > >> this > > > >> > > > > warning. > > > >> > > > > > > > > > >> > > > > > > For compatibility with older versions of CMake, > > > >> try_compile > > > >> > > is > > > >> > > > > not > > > >> > > > > > > honoring > > > >> > > > > > > caller link flags (e.g. CMAKE_EXE_LINKER_FLAGS) in > > > >> the test > > > >> > > > > > > project. > > > >> > > > > > > Call Stack (most recent call first): > > > >> > > > > > > CMakeLists.txt:242 (find_package) > > > >> > > > > > > This warning is for project developers. Use > > -Wno-dev to > > > >> > > suppress > > > >> > > > > it. > > > >> > > > > > > > > > >> > > > > > > Called from: [2] > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindLibical.cmake > > > >> > > > > > > [1] > > > >> > > > > > > > > > >> > > > > > >> > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt > > > >> > > > > > > CMake Warning (dev) at > > cmake/modules/FindLibical.cmake:59 > > > >> > > > > (try_run): > > > >> > > > > > > Policy CMP0067 is not set: Honor language standard > > in > > > >> > > > > try_compile() > > > >> > > > > > > source-file signature. Run "cmake --help-policy > > > >> CMP0067" > > > >> > > for > > > >> > > > > policy > > > >> > > > > > > details. Use the cmake_policy command to set the > > > >> policy and > > > >> > > > > > > suppress this > > > >> > > > > > > warning. > > > >> > > > > > > > > > >> > > > > > > For compatibility with older versions of CMake, > > > >> try_compile > > > >> > > is > > > >> > > > > not > > > >> > > > > > > honoring > > > >> > > > > > > language standard variables in the test project: > > > >> > > > > > > > > > >> > > > > > > CMAKE_CXX_STANDARD > > > >> > > > > > > CMAKE_CXX_STANDARD_REQUIRED > > > >> > > > > > > CMAKE_CXX_EXTENSIONS > > > >> > > > > > > > > > >> > > > > > > Call Stack (most recent call first): > > > >> > > > > > > CMakeLists.txt:242 (find_package) > > > >> > > > > > > This warning is for project developers. Use > > -Wno-dev to > > > >> > > suppress > > > >> > > > > it. > > > >> > > > > > > > > > >> > > > > > > Called from: [2] > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindLibical.cmake > > > >> > > > > > > [1] > > > >> > > > > > > > > > >> > > > > > >> > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt > > > >> > > > > > > CMake Error at cmake/modules/FindLibical.cmake:75 > > > >> (message): > > > >> > > > > > > Unable to compile or run the libical version > > detection > > > >> > > program. > > > >> > > > > > > Call Stack (most recent call first): > > > >> > > > > > > CMakeLists.txt:242 (find_package) > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > Called from: [2] > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindLibical.cmake > > > >> > > > > > > [1] > > > >> > > > > > > > > > >> > > > > > >> > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt > > > >> > > > > > > -- Configuring incomplete, errors occurred! > > > >> > > > > > > See also > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > "/usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/build/CMakeFiles/CMakeOutput.log". > > > >> > > > > > > See also > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > "/usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/build/CMakeFiles/CMakeError.log". > > > >> > > > > > > make: *** No targets specified and no makefile found. > > > >> Stop. > > > >> > > > > > > > > > >> > > > > > > > > > >> ============================================================= > > > >> > > > > > > > > > >> > > > > > > [1] > > > >> > > > > > > > > > >> > > > > > >> > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt > > > >> > > > > > > -- Found PythonLibs: //lib64/libpython2.7.so (found > > > >> suitable > > > >> > > > > version > > > >> > > > > > > "2.7.15", minimum required is "2.7.15") > > > >> > > > > > > Called from: [4] > > > >> > > > > /usr/share/cmake/Modules/FindPackageMessage.cmake > > > >> > > > > > > [3] > > > >> > > > > > > > > > >> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake > > > >> > > > > > > [2] > > > >> > > /usr/share/cmake/Modules/FindPythonLibs.cmake > > > >> > > > > > > [1] > > > >> > > > > > > > > > >> > > > > > >> > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt > > > >> > > > > > > -- Could NOT find PY_weboob (missing: PY_WEBOOB) > > > >> > > > > > > Called from: [4] > > > >> > > > > > > > > > >> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake > > > >> > > > > > > [3] > > > >> > > > > > > > > > >> /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake > > > >> > > > > > > [2] > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/cmake/modules/FindPythonModule.cmake > > > >> > > > > > > [1] > > > >> > > > > > > > > > >> > > > > > >> > > /usr/local/src/kmm/kmymoney-5.0-2018.11.07-18:23:12/CMakeLists.txt > > > >> > > > > > > -- Configuring incomplete, errors occurred! > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > ---- > > > >> > > > > > > Brendan Coupe > > > >> > > > > > > On Wed, Nov 7, 2018 at 5:42 PM Jack > > > >> > > > > <ostrof...@users.sourceforge.net> > > > >> > > > > > > wrote: > > > >> > > > > > > > > > > >> > > > > > > > On 2018.11.07 19:22, Brendan Coupe wrote: > > > >> > > > > > > > > weboob errors seem to be unfixable in Fedora. I > > > >> think they > > > >> > > > > have > > > >> > > > > > > been > > > >> > > > > > > > > around for a while, I found them in previous > > > >> requests for > > > >> > > > > help. I > > > >> > > > > > > > > don' think they have anything to do with the > > compile > > > >> > > failing. > > > >> > > > > not > > > >> > > > > > > > > sure if they cause any of the weird behavior I > > was > > > >> > > seeing. I > > > >> > > > > will > > > >> > > > > > > try > > > >> > > > > > > > > to resurrect an old F28 system. I'm hoping the > > repos > > > >> have > > > >> > > > > 5.0.2 > > > >> > > > > > > soon > > > >> > > > > > > > > since I'm currently running 5.0.1 and dealing > > with > > > >> old > > > >> > > > > problems > > > >> > > > > > > that > > > >> > > > > > > > > have been fixed. > > > >> > > > > > > > I agree weboob is not relevant here. > > > >> > > > > > > > > > > > >> > > > > > > > > Is this the detection program you are talking > > about: > > > >> > > > > > > > > cmake/modules/FindLibical.cmake > > > >> > > > > > > > No, the .cmake program tells cmake where to look > > for > > > >> stuff, > > > >> > > and > > > >> > > > > how > > > >> > > > > > > to > > > >> > > > > > > > set various variables used later in the cmake > > run. To > > > >> > > actually > > > >> > > > > > > check, > > > >> > > > > > > > cmake creates a .c program (using hints and info > > from > > > >> the > > > >> > > .cmake > > > >> > > > > > > file, > > > >> > > > > > > > and then tries to compile and link it. (Some > > checks > > > >> might > > > >> > > be > > > >> > > > > done > > > >> > > > > > > with > > > >> > > > > > > > pkg_config) Normally that fails if libical isn't > > > >> found, or > > > >> > > > > isn't a > > > >> > > > > > > > high enough version, for example. Your error says > > " > > > >> Unable > > > >> > > to > > > >> > > > > > > compile > > > >> > > > > > > > or run the libical version detection program." > > which > > > >> seems > > > >> > > like > > > >> > > > > a > > > >> > > > > > > > different sort of problem. I would look through > > the > > > >> cmake > > > >> > > > > --help > > > >> > > > > > > > output to see what parameters might provide > > additional > > > >> > > details > > > >> > > > > about > > > >> > > > > > > > what is actually failing. > > > >> > > > > > > > > > > > >> > > > > > > > > Line 75 is the source of the message. > > > >> > > > > > > > > gcc.x86_64 > > > >> 8.2.1-4.fc29 > > > >> > > > > > > > > @updates > > > >> > > > > > > > > gcc-c++.x86_64 > > > >> 8.2.1-4.fc29 > > > >> > > > > > > > > @updates > > > >> > > > > > > > > gcc-gdb-plugin.x86_64 > > > >> 8.2.1-4.fc29 > > > >> > > > > > > > > @updates > > > >> > > > > > > > > libgcc.x86_64 > > > >> 8.2.1-4.fc29 > > > >> > > > > > > > > @updates > > > >> > > > > > > > This, however, might be the issue. I'll have to > > try > > > >> > > installing > > > >> > > > > gcc > > > >> > > > > > > 8 > > > >> > > > > > > > and see how it works for me. As a temporary fix, > > you > > > >> might > > > >> > > try > > > >> > > > > > > using > > > >> > > > > > > > gcc 7. > > > >> > > > > > > > > > > >> > > > > > > > Jack > > > >> > > > > > > > > > > > >> > > > > > > > > ---- > > > >> > > > > > > > > Brendan Coupe > > > >> > > > > > > > > On Wed, Nov 7, 2018 at 4:47 PM Jack > > > >> > > > > > > <ostrof...@users.sourceforge.net> > > > >> > > > > > > > > wrote: > > > >> > > > > > > > > > > > > >> > > > > > > > > > Hello Brendan, > > > >> > > > > > > > > > > > > >> > > > > > > > > > On 2018.11.07 18:17, Brendan Coupe wrote: > > > >> > > > > > > > > > > I have been compiling from source for 10+ > > years. > > > >> I had > > > >> > > > > been > > > >> > > > > > > able > > > >> > > > > > > > > to > > > >> > > > > > > > > > > compile both the master branch and the 5.0 > > > >> branch on > > > >> > > my > > > >> > > > > > > Fedora 28 > > > >> > > > > > > > > > > system until a month or so ago. I was having > > some > > > >> > > weird > > > >> > > > > > > behavior > > > >> > > > > > > > > in > > > >> > > > > > > > > > > KMM5 that was not affecting a clean Fedora 28 > > > >> test VM > > > >> > > > > running > > > >> > > > > > > KMM > > > >> > > > > > > > > > > from the repos so I decided to build a new > > clean > > > >> > > Fedora 29 > > > >> > > > > > > system. > > > >> > > > > > > > > > It may be worth checking the release notes for > > > >> Fedora > > > >> > > 29 to > > > >> > > > > see > > > >> > > > > > > what > > > >> > > > > > > > > > changed, and if anything looks possibly > > relevant. > > > >> > > > > > > > > > > > > >> > > > > > > > > > > I also upgraded the old system from Fedora > > 28 to > > > >> 29. > > > >> > > Both > > > >> > > > > > > systems > > > >> > > > > > > > > > > fail at the same point while compiling from > > the > > > >> master > > > >> > > > > and 5.0 > > > >> > > > > > > > > > > branches: > > > >> > > > > > > > > > It certainly sounds like some difference > > between > > > >> 28 and > > > >> > > 29 > > > >> > > > > is > > > >> > > > > > > behind > > > >> > > > > > > > > > the failure. > > > >> > > > > > > > > > > > > >> > > > > > > > > > > -- Found LibOfx: > > > >> > > > > > > > > > > -- Performing Test LIBOFX_HAVE_CLIENTUID > > > >> > > > > > > > > > > -- Performing Test LIBOFX_HAVE_CLIENTUID - > > > >> Success > > > >> > > > > > > > > > > -- Found PythonInterp: /usr/bin/python2 > > (found > > > >> > > suitable > > > >> > > > > > > version > > > >> > > > > > > > > > > "2.7.15", minimum required is "2.6") > > > >> > > > > > > > > > > -- Found PythonLibs: > > /usr/lib64/libpython2.7.so > > > >> (found > > > >> > > > > > > suitable > > > >> > > > > > > > > > > version "2.7.15", minimum required is > > "2.7.15") > > > >> > > > > > > > > > > -- Could NOT find PY_weboob (missing: > > PY_WEBOOB) > > > >> > > > > > > > > > I'm assuming this is not an issue for you. > > > >> > > > > > > > > > > CMake Error at > > cmake/modules/FindLibical.cmake:75 > > > >> > > > > (message): > > > >> > > > > > > > > > > Unable to compile or run the libical > > version > > > >> > > detection > > > >> > > > > > > program. > > > >> > > > > > > > > > This does seem odd. It appears not even > > getting > > > >> to the > > > >> > > > > point of > > > >> > > > > > > > > > actually checking for an installed libical. > > > >> > > > > > > > > > > Call Stack (most recent call first): > > > >> > > > > > > > > > > CMakeLists.txt:242 (find_package) > > > >> > > > > > > > > > At the point of failure, check in the build > > > >> directory. > > > >> > > > > Often > > > >> > > > > > > you > > > >> > > > > > > > > can > > > >> > > > > > > > > > find the libical version detection program > > (I've > > > >> > > forgotten > > > >> > > > > > > whether > > > >> > > > > > > > > it > > > >> > > > > > > > > > leaves the .c program around, and see if > > > >> configure.log > > > >> > > (or > > > >> > > > > > > something > > > >> > > > > > > > > > like it) might have a more detailed reason for > > the > > > >> > > failure > > > >> > > > > to > > > >> > > > > > > > > compile > > > >> > > > > > > > > > that .c program. > > > >> > > > > > > > > > > > > >> > > > > > > > > > Not sure if it might be relevant, but what > > version > > > >> of > > > >> > > gcc > > > >> > > > > are > > > >> > > > > > > you > > > >> > > > > > > > > > using, both in F28 and in F29? > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > -- Configuring incomplete, errors occurred! > > > >> > > > > > > > > > > ======================================== > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > libical appears to be installed: > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > dnf list installed | grep libical > > > >> > > > > > > > > > > libical.x86_64 > > > >> > > > > > > > > 3.0.3-7.fc29 > > > >> > > > > > > > > > > @fedora > > > >> > > > > > > > > > > libical-devel.x86_64 > > > >> > > > > > > > > 3.0.3-7.fc29 > > > >> > > > > > > > > > > @fedora > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > Any ideas? > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > Thanks, > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > ---- > > > >> > > > > > > > > > > Brendan Coupe > > > >> > > > > > > > > > Jack > > > >> > > > > > >> > > > > >> > > > > >> > > > > > > > > > >
