Issues compiling c files in Qt creator



  • I'm learning c/c++ and wanted to do some work with QT Creator. I am using a base64 class that just refuses to compile and any help would be greatly appreciated.

    The error lines I get is
    /QTDev/PolicyFrameworkDesktop-build-desktop/../PolicyFrameworkDesktop/libhaggle/base64.h:59: error: expected ';', ',' or ')' before 'in'

    /QTDev/PolicyFrameworkDesktop-build-desktop/../PolicyFrameworkDesktop/libhaggle/base64.h:66: error: expected ';', ',' or ')' before 'in'

    /QTDev/PolicyFrameworkDesktop-build-desktop/../PolicyFrameworkDesktop/libhaggle/base64.c:68: error: expected ';', ',' or ')' before 'in'

    /QTDev/PolicyFrameworkDesktop-build-desktop/../PolicyFrameworkDesktop/libhaggle/base64.c:: error: At top level:

    /QTDev/PolicyFrameworkDesktop-build-desktop/../PolicyFrameworkDesktop/libhaggle/base64.c:320: error: expected ';', ',' or ')' before '*' token

    /QTDev/PolicyFrameworkDesktop-build-desktop/../PolicyFrameworkDesktop/libhaggle/base64.c:373: error: expected ';', ',' or ')' before 'in'
    /QTDev/PolicyFrameworkDesktop-build-desktop/../PolicyFrameworkDesktop/libhaggle/base64.c:456: error: expected ';', ',' or ')' before 'in'

    The files in question are in the links below along with the 'pro' file and the generated Makefile.

    http://rapidshare.com/files/435084121/base64.c
    http://rapidshare.com/files/435084122/base64.h
    http://rapidshare.com/files/435084571/Makefile
    http://rapidshare.com/files/435084682/PolicyFrameworkDesktop.pro

    [fixed topic, Tobias Hunger]



  • restrict is C keyword, not C++. I think you should not include them in .pro but make additional Makefile (manually) which will call C compiler for base64 library and link it in your .pro file.



  • Hi Denis,

    Thanks for the quick reply. Can you please give me an example of how to link a manual makefile to a pro file? Also i thought the #ifdef __cplusplus section would stop any compiler issues?

    Thanks again


  • Moderators

    Why a base64 library? Qt can de/encode base64 all by itself (QByteArray::fromBase64 and toBase64).



  • You can add it as custom target to PRE_TARGETDEPS variable I think.



  • [quote author="Tobias Hunger" date="1291577543"]Why a base64 library? Qt can de/encode base64 all by itself (QByteArray::fromBase64 and toBase64).[/quote]

    Hi Toby,
    Thanks for the reply, that class is part of the source of a library that I am trying to use. It builds fine when running a normal gcc session from the command line so I was a bit surprised when I run into the issue. I'm not a c++ expert by any stretch ,just learning as I go along, but if I understand what you are suggesting it means that I have to go through the whole library replacing the instances of base64 calls with the QByteArray calls, and I don't know how that will affect the rest of the library which was why I wanted to see if there was something I should be doing instead.

    Thanks again



  • [quote author="Denis Kormalev" date="1291577718"]You can add it as custom target to PRE_TARGETDEPS variable I think.
    [/quote]

    Thanks for that Denis, will try that right away and let you know how it goes.


  • Moderators

    benardmens: Oh, if this is part of 3rd party code then forget my comment.

    Many people seem to not know that Qt can de/encode base64 all by itself... I have seen more than one piece of code where some developer dragged in a 3rd party library just to write some bytes in base64 encoding.



  • Unfortunately I cannot download the files (too many downloads in parallel). So, sorry, can't help with this.



  • [quote author="Denis Kormalev" date="1291577718"]You can add it as custom target to PRE_TARGETDEPS variable I think.
    [/quote]

    Hi Denis, tried that but it didn't work. The way I understood it is to add a custom Makefile argument to the PRE_TARGETDEPS? Thanks

    [edit: quoe fixed / Denis Kormalev]



  • [quote author="Volker" date="1291582514"]Unfortunately I cannot download the files (too many downloads in parallel). So, sorry, can't help with this.[/quote]

    Hi Volker,
    These are some new links which shouldnt give the same problem,

    http://www.mediafire.com/?z13ki4t48iqs8ke
    http://www.mediafire.com/?nq14e8527bj4l7i
    http://www.mediafire.com/?1a23rh9ngxpe3dm

    I would appreciate any help as I've been trying to get this working for a day now. Thanks again



  • benardmens, can you show your .pro file (please post its content here in @ tags)?



  • You could put the files inside a zip or tar. Makes it easier to upload and download (for future reference).

    Theres a site called wikiupload that doesn't have a time delay to download.



  • [quote author="Denis Kormalev" date="1291620464"]benardmens, can you show your .pro file (please post its content here in (at) tags)?[/quote]

    Hi Denis,
    I just got a work around to work by building it as a library and adding it manually to the libs. However , i would still like to be able to understand how to do it properly if possible.

    The current .pro file is below as requested

    @
    #-------------------------------------------------

    Project created by QtCreator 2010-12-05T20:36:45

    #-------------------------------------------------

    QT += core gui

    TARGET = PolicyFrameworkSpy
    TEMPLATE = app

    unix:LIBS +=-L/usr/include/libxml2
    /usr/local/lib/libhaggle.a

    unix:INCLUDEPATH +=/usr/local/include/libhaggle/
    /usr/include/libxml2 \

    QMAKE_CFLAGS_DEBUG += -std=gnu99 -O2
    QMAKE_LFLAGS += -lxml2 -lz -lpthread -licucore -lm
    SOURCES += main.cpp
    PolicyFramework.cpp

    HEADERS += PolicyFramework.h

    FORMS += PolicyFramework.ui
    @

    And the one I was having issues with

    @
    #-------------------------------------------------

    Project created by QtCreator 2010-12-05T16:43:38

    #-------------------------------------------------

    QT += core gui

    TARGET = PolicyFrameworkDesktop
    TEMPLATE = app

    INCLUDEPATH +=/QTDev/PolicyFrameworkDesktop/libhaggle

    SOURCES += main.cpp
    PolicyFrameworkSpy.cpp
    libhaggle/base64.c

    HEADERS += PolicyFrameworkSpy.h
    libhaggle/base64.h

    FORMS += PolicyFrameworkSpy.ui
    @



  • [quote author="xsacha" date="1291620625"]You could put the files inside a zip or tar. Makes it easier to upload and download (for future reference).

    Theres a site called wikiupload that doesn't have a time delay to download.[/quote]

    Thanks for that, I will keep that in mind for later. Thanks for the help everyone. This is one of the most responsive forums I've ever been on!



  • benardmens, try to add something like this
    @
    someLib.target = someLibBuild
    someLib.commands = cd path/to/lib && make
    QMAKE_EXTRA_TARGETS += someLib
    PRE_TARGETDEPS += someLibBuild
    @



  • [quote author="benardmens" date="1291619302"]
    These are some new links which shouldnt give the same problem,

    I would appreciate any help as I've been trying to get this working for a day now. Thanks again[/quote]

    I put base64.h and and base64.c in a small project and could compile it and use its base64_encode_alloc in a C++ program.

    qmake calls g++ or gcc depending on the file extension (cpp or c). I used no pre targets or libs or something like that.



  • Hi all,
    1st thing is that you are not using class. There is no such thing in C as class or object!
    Your problem is that you're using qt tools to compile (.pro file & qmake) which generate Makefiles only for C++. If you want to compile C code with QtCreator you should start using "cmake":http://cmake.org/ (which is supported by QtCreator) instead of .pro files.



  • Not quite true.

    @
    HEADERS += plain.h base64.h
    SOURCES += main.cpp base64.c
    @

    This calls g++ (GCC in C++ mode) on main.cpp and gcc (GCC in C mode) on base64.c. The decision is made on the file extension (.cpp or .c). One can tweak that with setting QMAKE_EXT_CPP. The default is .cpp .cc .cxx .C



  • Actually, there's an even better way:

    Top-level .pro file:
    @
    TEMPLATE = subdirs

    someLib.subdir = someLib
    someLib.makefile = someLib.mak # This may not be named "Makefile"!
    someLib.target = $${QMAKE_PREFIX_SHLIB}someLib.${QMAKE_EXTENSION_SHLIB}

    SUBDIRS = someLib someApp
    @

    someLib/someLib.mak:
    @
    libsomeLib.so:
    gcc foo.c -o libsomeLib.so

    clean:
    rm -f libsomeLib.so

    distclean: clean

    .PHONY: clean distclean
    @

    Note that it will create a bogus, non-functional "someLib/Makefile", but you may simply ignore it.

    I don't believe this is documented, but it's been in qmake for quite a long time (I want to say at least since 4.3.x, but don't quote me on that).



  • [quote author="GordonSchumacher" date="1291831448"]Actually, there's an even better way:

    Top-level .pro file:
    @
    TEMPLATE = subdirs

    someLib.subdir = someLib
    someLib.makefile = someLib.mak # This may not be named "Makefile"!
    someLib.target = $${QMAKE_PREFIX_SHLIB}someLib.${QMAKE_EXTENSION_SHLIB}

    SUBDIRS = someLib someApp
    @

    someLib/someLib.mak:
    @
    libsomeLib.so:
    gcc foo.c -o libsomeLib.so

    clean:
    rm -f libsomeLib.so

    distclean: clean

    .PHONY: clean distclean
    @

    Note that it will create a bogus, non-functional "someLib/Makefile", but you may simply ignore it.

    I don't believe this is documented, but it's been in qmake for quite a long time (I want to say at least since 4.3.x, but don't quote me on that).[/quote]

    [quote author="Volker" date="1291641995"]Not quite true.

    @
    HEADERS += plain.h base64.h
    SOURCES += main.cpp base64.c
    @

    This calls g++ (GCC in C++ mode) on main.cpp and gcc (GCC in C mode) on base64.c. The decision is made on the file extension (.cpp or .c). One can tweak that with setting QMAKE_EXT_CPP. The default is .cpp .cc .cxx .C[/quote]

    Thanks for all the suggestions, I was unable to go back to the project because of work but I will try the suggestions right away and get back to you.

    Thanks everyone!



  • Hi all,

    I've tried the options without success so I've uploaded the project if some one could kindly help me out with where I'm going wrong. The link is below

    http://www.wikiupload.com/3XHWP6JG2GXMU1D

    Thanks again everyone for the help so far



  • Is that really all of libhaggle? There is no Makefile in that directory, but there is Makefile.in/.ac, which would certainly suggest that it's an Autotools project... but there is no Autoconf.in/.ac, so I can't run automake at all (or at least, mine complains about the lack of those files).



  • [quote author="GordonSchumacher" date="1292083276"]Is that really all of libhaggle? There is no Makefile in that directory, but there is Makefile.in/.ac, which would certainly suggest that it's an Autotools project... but there is no Autoconf.in/.ac, so I can't run automake at all (or at least, mine complains about the lack of those files).[/quote]

    Hi Gordon, thanks for the quick reply, I actually didn't include them because in my naivety i though they weren't needed. Please find the full haggle folder included. By the way this is being compiled for Maemo (N900). Don't know if that helps. The links are below. They are both the same thing just uploaded to different places for convenience.

    http://www.wikiupload.com/QIPLU200EX9PHGS
    http://rapidshare.com/files/436368610/Policy.zip

    Thanks again every one, really appreciate the help



  • Okay, that was way harder than it should have been, and my solution unquestionably qualifies as abusing qmake... but it works!

    I created a "main.pro" in the top-level directory with the following contents:
    @TEMPLATE = subdirs

    haggle_build.subdir = haggle_build
    haggle_build.makefile = Makefile.haggle_build

    PolicyMobile.subdir = PolicyMobile
    PolicyMobile.depends = haggle_build

    SUBDIRS = haggle_build PolicyMobile@

    The "haggle_build.makefile = haggle_build" will cause the top-level Makefile to call "make -f Makefile.haggle_build" in that subdirectory. We need to change the name of the makefile because configure would otherwise clobber it. Note that this will not actually change the name of the file qmake generates there... we'll take care of that in a bit.

    Then I created a subdirectory called "haggle_build". In that directory I placed a file named haggle_build.pro which contains:
    @MAKEFILE = Makefile.haggle_build

    HAGGLE_SRCDIR = ../haggle-0.3

    autoreconf.target = $${HAGGLE_SRCDIR}/configure
    autoreconf.commands = cd $${HAGGLE_SRCDIR} && autoreconf

    aclocal.target = $${HAGGLE_SRCDIR}/aclocal.m4
    aclocal.depends = autoreconf

    automake.target = $${HAGGLE_SRCDIR}/Makefile.in
    automake.depends = autoreconf

    autoheader.target = $${HAGGLE_SRCDIR}/Makefile.in
    autoheader.depends = autoreconf

    libtoolize.target = $${HAGGLE_SRCDIR}/ltmain.sh
    libtoolize.depends = autoreconf

    Makefile.target = Makefile
    Makefile.commands = $${HAGGLE_SRCDIR}/configure
    Makefile.depends = autoreconf aclocal automake autoheader libtoolize

    all.CONFIG = phony
    all.commands = make
    all.depends = Makefile

    TARGET = \\

    QMAKE_EXTRA_TARGETS += autoreconf aclocal automake autoheader libtoolize Makefile all@

    So the MAKEFILE variable changes the name of the makefile to match main.pro's. Most of the rest of the .pro is writing custom targets to ensure that all the Autotools file are up-to-date. The last target, "all", is one which qmake always generates, and is the default build target. I have not found a way to get qmake not to output a section which looks something like:
    @all: $(TARGET)
    $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)@

    Since we defined a custom rule named "all" as well and made it depend on "Makefile", qmake will later on write another rule in the makefile. So we can successfully get the "all" target to invoke make for us; our remaining challenge is to get it not to call the linker!

    So my tactic was to abuse qmake and define TARGET to simply a space. This means that the first "all" rule depends on nothing, and thus will never be run!

    Hope this works for you and helps; I am planning to transfer this nugget to a wiki page...



  • [quote author="GordonSchumacher" date="1292254708"]Okay, that was way harder than it should have been, and my solution unquestionably qualifies as abusing qmake... but it works!

    I created a "main.pro" in the top-level directory with the following contents:
    @TEMPLATE = subdirs

    haggle_build.subdir = haggle_build
    haggle_build.makefile = Makefile.haggle_build

    PolicyMobile.subdir = PolicyMobile
    PolicyMobile.depends = haggle_build

    SUBDIRS = haggle_build PolicyMobile@

    The "haggle_build.makefile = haggle_build" will cause the top-level Makefile to call "make -f Makefile.haggle_build" in that subdirectory. We need to change the name of the makefile because configure would otherwise clobber it. Note that this will not actually change the name of the file qmake generates there... we'll take care of that in a bit.

    Then I created a subdirectory called "haggle_build". In that directory I placed a file named haggle_build.pro which contains:
    @MAKEFILE = Makefile.haggle_build

    HAGGLE_SRCDIR = ../haggle-0.3

    autoreconf.target = $${HAGGLE_SRCDIR}/configure
    autoreconf.commands = cd $${HAGGLE_SRCDIR} && autoreconf

    aclocal.target = $${HAGGLE_SRCDIR}/aclocal.m4
    aclocal.depends = autoreconf

    automake.target = $${HAGGLE_SRCDIR}/Makefile.in
    automake.depends = autoreconf

    autoheader.target = $${HAGGLE_SRCDIR}/Makefile.in
    autoheader.depends = autoreconf

    libtoolize.target = $${HAGGLE_SRCDIR}/ltmain.sh
    libtoolize.depends = autoreconf

    Makefile.target = Makefile
    Makefile.commands = $${HAGGLE_SRCDIR}/configure
    Makefile.depends = autoreconf aclocal automake autoheader libtoolize

    all.CONFIG = phony
    all.commands = make
    all.depends = Makefile

    TARGET = \\

    QMAKE_EXTRA_TARGETS += autoreconf aclocal automake autoheader libtoolize Makefile all@

    So the MAKEFILE variable changes the name of the makefile to match main.pro's. Most of the rest of the .pro is writing custom targets to ensure that all the Autotools file are up-to-date. The last target, "all", is one which qmake always generates, and is the default build target. I have not found a way to get qmake not to output a section which looks something like:
    @all: $(TARGET)
    $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)@

    Since we defined a custom rule named "all" as well and made it depend on "Makefile", qmake will later on write another rule in the makefile. So we can successfully get the "all" target to invoke make for us; our remaining challenge is to get it not to call the linker!

    So my tactic was to abuse qmake and define TARGET to simply a space. This means that the first "all" rule depends on nothing, and thus will never be run!

    Hope this works for you and helps; I am planning to transfer this nugget to a wiki page...[/quote]

    Thanks a lot, there is no way I could have figured that out, I will try that right away and let you know how it goes,

    Thanks again everyone



  • I am also using qmake for my TicTacToe University Project which is coded in C and ncurses. I have no problems compiling C files.



  • [quote author="GordonSchumacher" date="1292254708"]Okay, that was way harder than it should have been, and my solution unquestionably qualifies as abusing qmake... but it works!

    I created a "main.pro" in the top-level directory with the following contents:
    @TEMPLATE = subdirs

    haggle_build.subdir = haggle_build
    haggle_build.makefile = Makefile.haggle_build

    PolicyMobile.subdir = PolicyMobile
    PolicyMobile.depends = haggle_build

    SUBDIRS = haggle_build PolicyMobile@

    The "haggle_build.makefile = haggle_build" will cause the top-level Makefile to call "make -f Makefile.haggle_build" in that subdirectory. We need to change the name of the makefile because configure would otherwise clobber it. Note that this will not actually change the name of the file qmake generates there... we'll take care of that in a bit.

    Then I created a subdirectory called "haggle_build". In that directory I placed a file named haggle_build.pro which contains:
    @MAKEFILE = Makefile.haggle_build

    HAGGLE_SRCDIR = ../haggle-0.3

    autoreconf.target = $${HAGGLE_SRCDIR}/configure
    autoreconf.commands = cd $${HAGGLE_SRCDIR} && autoreconf

    aclocal.target = $${HAGGLE_SRCDIR}/aclocal.m4
    aclocal.depends = autoreconf

    automake.target = $${HAGGLE_SRCDIR}/Makefile.in
    automake.depends = autoreconf

    autoheader.target = $${HAGGLE_SRCDIR}/Makefile.in
    autoheader.depends = autoreconf

    libtoolize.target = $${HAGGLE_SRCDIR}/ltmain.sh
    libtoolize.depends = autoreconf

    Makefile.target = Makefile
    Makefile.commands = $${HAGGLE_SRCDIR}/configure
    Makefile.depends = autoreconf aclocal automake autoheader libtoolize

    all.CONFIG = phony
    all.commands = make
    all.depends = Makefile

    TARGET = \\

    QMAKE_EXTRA_TARGETS += autoreconf aclocal automake autoheader libtoolize Makefile all@

    So the MAKEFILE variable changes the name of the makefile to match main.pro's. Most of the rest of the .pro is writing custom targets to ensure that all the Autotools file are up-to-date. The last target, "all", is one which qmake always generates, and is the default build target. I have not found a way to get qmake not to output a section which looks something like:
    @all: $(TARGET)
    $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJCOMP) $(LIBS)@

    Since we defined a custom rule named "all" as well and made it depend on "Makefile", qmake will later on write another rule in the makefile. So we can successfully get the "all" target to invoke make for us; our remaining challenge is to get it not to call the linker!

    So my tactic was to abuse qmake and define TARGET to simply a space. This means that the first "all" rule depends on nothing, and thus will never be run!

    Hope this works for you and helps; I am planning to transfer this nugget to a wiki page...[/quote]

    Hi Gordon,

    I've been trying to replicate your solution for the past two weeks with varying levels of success, sometimes it compiles the files and then proceeds to fail. I was wondering if your solution is working for maemo as thats the target platform I'm trying to build for using the MADDE tools. Could you upload your solution so that I can go through it as I dont seem to be making much more headway.

    Thanks a bunch


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.