Compiler does not produce .o file , just a moc_.o and moc_.cpp files.



  • It happens that the compiler fails to compile a source to an object .o file while still producing its moc and cpp counterparts.

    It is not always so. Sometime it does produce the .o file and the program works fine. I would need its .o file to use somewhere else as a lib file .

    How is that possible? What can I do to force the compiler producing the .o file ?


  • Lifetime Qt Champion

    Hi,

    Something's not clear here. Do you have trouble compiling a class ? Or do you have some special project since you are talking about reusing an object file for a library ?



  • Hi,

    the compiling is fine and the linking is fine but problem is that the object .o file is missing and I need one to use in different project as a lib. The pro contains header and source sections that contain the entries like

    TEMPLATE = app
    HEADERS+= class_name.h
    SOURCES+= class_name.cpp
    CONFIG += c++11

    but the generated makefile does not have either class_name.cpp in the SOURCES or in the OBJECTS.
    If I manually add those into the Makefile sections , it produces "no rule to make target".

    I suppose qmake assumes some optimizations and skips to create that particular object file, (thoug it produces moc object file and the moc cpp.


  • Lifetime Qt Champion

    If you need it in a library then put it that library and link your application to that library. That will be way cleaner.



  • @SGaist , I would put in the library , but that particular class I reuse from the object + header file in different project. Since there is no generated o. gives me nothing to put


  • Lifetime Qt Champion

    A different sub-project in your project ? A completely different project ?

    In both cases, it would be cleaner to provide a library containing your common class(es)


  • Qt Champions 2016

    @ddze

    I would put in the library , but that particular class I reuse from the object + header file in different project. Since there is no generated o. gives me nothing to put

    And what if your class is spread over more than one translation unit, as QObject derived classes are? I'm with @SGaist on this, create a static library (which is basically a set of object files) and link with that in whatever project you want.



  • @SGaist ,

    it is a completely different project. But strangely , it has produced the .o file few times. Than (without even changing the signature in the headers or the cpp) failed to produce the object file the next time I compiled the original project.

    you mean the library like the QLibrary ?


  • Qt Champions 2016

    @ddze

    Than (without even changing the signature in the headers or the cpp) failed to produce the object file the next time I compiled the original project.

    Translation units (object files) are an intermediate step of building, so the compiler (and linker) is not at all obligated to provide you with them. They can be created in a temp directory, or (how it's usually done by compilers) in the build directory, the only requirement is that they're available to the linker to finish up the building process. So, don't use them raw, as you want to do.

    you mean the library like the QLibrary ?

    No, QLibrary is a class for dynamic loading of shared objects/dlls/dynlibs what you need is to create a static library which is a collection of object files to link with your projects. You can do that as is described here in the wiki.

    Kind regards.



  • @kshegunov ,
    it is a derived QGraphicsView class with the Q_OBJECT macro (needed for a signal). But the strange thing the compiler has produced the object file several times (than I removed a commented line of code and needed new object - so the recompiling produced no object output since than) I have another object file with the MACRO and it compiles and links fine all the time.

    Also in the new project I have two object files along with their headers , One runs perfectly fine but the linker ( not the compiler-sorry my tippo ) finds an undefined reference to an access function from the QGraphicsView derived object file. The reason why I want the new object file.


  • Qt Champions 2016

    @ddze

    One runs perfectly fine but the compiler finds an undefined reference to an access function from the QGraphicsView derived object file. The reason why I want the new object file.

    This is the linker, not the compiler and is because as I already said QObject derived classes span more than one translation unit. Follow the advice in my previous post. Additionally, any class you derive from QObject should have the Q_OBJECT macro, don't comment it out.



  • @kshegunov ,

    Thanks a million for a simple but very informative explanation.



  • @SGaist

    thanks man too, appreciate very much.



  • Unfortunately , seems like I have a problem with creating a static lib. Because of the internal dependency on an interface class. Basically, the static linking assumes that all of the classes can be instantiated, but in my case one of them holds an interface - therefore producing an error "incomplete type". Now I would have to add new classes into the static library which progresses from worse to terrible.

    Is there any way to force the compiler to produce an object file by modifying the Makefile ?


  • Qt Champions 2016

    @ddze
    If you can't build a static library you'll never be able to use the object files as well, since a static library is a number of object files put together (but with no stub or loader information). So I suggest to look up how to fix the static library build.

    Because of the internal dependency on an interface class. Basically, the static linking assumes that all of the classes can be instantiated, but in my case one of them holds an interface - therefore producing an error "incomplete type".

    This doesn't make any sense. You put everything related to your QGraphicsView derived class in the static library, the abstract base class as well and that's all there is to it. "Incomplete type" comes from the compiler, and in all probability means you've forgotten to include a header.

    Is there any way to force the compiler to produce an object file by modifying the Makefile ?

    It should produce them in any case, as the linker needs those, it's a matter of where, not if.



  • @kshegunov

    so, you mean that is allowed to place an interface class into a static library?

    I searched that question and found nothing really meaningful relative to my case. So it is important to know since I am stack with a question whether is possible to fix the problem with the static library holding the interface class or I would have to look for alternative strategy.

    the line where it fails is an event handler in the derived QGraphicsView definition.

    IBase *source = qobject_cast<IBase*>(event->source());
    

    which compiles and links perfectly in another program but fails to compile in the static library with a messages :

    • error: static assertion failed: qobject_cast requires the type to have a Q_OBJECT macro
      #define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), Message)

    and

    • error: incomplete type 'ObjType {aka IBase}' used in nested name specifier
      return static_cast<T>(ObjType::staticMetaObject.cast(object));

    So, for some reason requires either the interface to posses a Q_OBJECT MACRO ( which I find that makes no sense to insert a MACRO in an interface class - maybe I miss something ) or that the instance is a live object at the point of assignment. ( the derived QGraphicsView class holds the MACRO in its declaration).


  • Qt Champions 2016

    @ddze

    so, you mean that is allowed to place an interface class into a static library?

    First, let me clarify a thing:
    What do you mean when you say an interface class?

    In C++ there's the abstract class (such that has at least one pure virtual function), and an abstract class that only has pure virtual functions usually is called an interface (class). In any case if you are deriving from QObject then you should put the Q_OBJECT macro in each of your subclasses.
    That said, qobject_cast is only for classes that derive from QObject, so if IBase is not a QObject descendant, well then, you can't use qobject_cast!

    Kind regards.



  • @kshegunov

    interface class -> a class with all virtual functions assigned a zero.

    in my case IBase is a pure virtual Abstract class , no MACROS , no inheritance from QObject. But, a derivative of the IBase also derives from the QGraphicsObject , so it is possible to compile and link the code. I know that because it does in another project.

    Hopefully, it clarifies the situation a little.


  • Qt Champions 2016

    @ddze
    Then you can't do this:

    qobject_cast<IBase*>(event->source())
    

    If you need to cast to that base pointer, then use ordinary dynamic_cast.



  • @kshegunov ,

    I have resolved it , that line of the code served only as check that an instance of the IBase exists prior to proceeding further.

    By removing that line and subsequent lines that check for the NULL pointer compiles and I will have to sort "eventual" point of failure by different mean.

    Still, not sure why that line compiles in another program.

    Kind Regards


  • Qt Champions 2016

    @ddze

    Still, not sure why that line compiles in another program.

    This seems doubtful, but it doesn't matter. I'm glad it works and for this particular case you could use:

    dynamic_cast<IBase*>(event->source())
    

    instead of qobject_cast and everything should compile and run fine.

    Cheers!



  • @kshegunov ,

    normally I do , I do not know why I did not try that one in this case. probably I had thought it was not the type casting causing the trouble. Though , when I think about it , it is actually very relevant.

    Good about this is to learn that the Abstract classes may be part of the static libs.



  • @kshegunov ,

    dynamic_cast did not work, but the reinterpret_cast compiled ok.


  • Qt Champions 2016

    @ddze

    dynamic_cast did not work, but the reinterpret_cast was ok.

    You shouldn't use reinterpret_cast, it's not for that purpose. What's the problem with the dynamic_cast?



  • @kshegunov

    here is the ...

    error: cannot dynamic_cast 'event->QDragEnterEvent::<anonymous>.QDragMoveEvent::<anonymous>.QDropEvent::source()' (of type 'class QObject*') to type 'class IBase*' (target is not pointer or reference to complete type)
    IBase source = dynamic_cast<IBase>(event->source());
    ^

    seems like that dynamic_cast cannot cast if the object is not instantiated completely ...


  • Qt Champions 2016

    @ddze

    IBase source = dynamic_cast<IBase>(event->source());
    

    I don't see the stars ...! dynamic_cast works only on pointers (or references), so this line is quite simply invalid. You can't have polymorphic cast on an object, it just doesn't make sense. You can however do it on a pointer to that object.

    IBase * source = dynamic_cast<IBase *>(event->source());
    

    Should work just fine.



  • @kshegunov

    here is the line IBase *source = dynamic_cast<IBase*>(event->source()); , not the pointer


  • Qt Champions 2016

    @ddze
    Okay then, your previous post didn't reflect that. Anyway, have you included the header where the IBase class resides?

    PS:
    Oh, I see, because you pasted the code as text, and the forum parser recognised the the asterisks and made the text italic ... heh.



  • @kshegunov

    you are 100% correct , it was the header file missing .... . The other project has the header IBase , that is why it compiles .... probably I deleted it accidentally or by trying the things out. (Should use a diff from now on)



  • once on this topic , what would happen if one has a cross-reference include headers ?

    I noticed few times that only if I declare a class forward declaration skipping an include of the header to be able to compile. Would in that case be ok to use reinterpret_cast as the dynamic_cast may needed the full header?

    probably this applies

    An expression of integral, enumeration, pointer, or pointer-to-member type can be converted to its own type. The resulting value is the same as the value of expression. (since C++11)

    Ref: reinterpret_cast


  • Qt Champions 2016

    @ddze
    No, not at all. dynamic_cast is polymorphic cast, it goes looks up the virtual table and makes safe casting for object pointers. reinterpret_cast is a different kettle of fish entirely, it just switches from one "interpretation" of data to another (whence the name). So it's completely legal to cast pretty much anything with reinterpret_cast but it's a bad idea, because it can be quite error-prone.

    You can do this:

    struct SomeStruct
    {
        int a;
        double b;
        QString x;
    };
    
    SomeStruct * variable = new SomeStruct;
    char * bytes = reinterpret_cast<char *>(variable);  //< This is valid, compiles and runs just fine. Only problem is, you may accidentally modify memory that's not yours ...
    

    And you have the whole structure as an array of bytes ... but it's ill advised to do such things in general. reinterpret_cast is similar to the functionality the union provides.
    So as rule of thumb, do not use reinterpret_cast.



  • @kshegunov

    Thanks a lot.


Log in to reply
 

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