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

ddze

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 ?

SGaist

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 ?

ddze

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.

SGaist

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

ddze

@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

SGaist

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)

kshegunov

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

ddze

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

kshegunov

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

ddze

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

kshegunov

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

ddze

@kshegunov ,

Thanks a million for a simple but very informative explanation.

ddze

@SGaist

thanks man too, appreciate very much.

ddze

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 ?

kshegunov

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

ddze

@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).

kshegunov

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

ddze

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

kshegunov

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

ddze

@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