Create N900 app in Qt under Windows 7

[rickrvo]

but the project was running on Qt simulator... I don't get it. where can I get examples of .pro files for the n900? (I never programmed for the n900) this is my first time and already I have to port the windows app to the mobile... :\

[wysota]

but the project was running on Qt simulator... I don't get it.

The simulator uses your desktop platform and not the mobile platfom.

where can I get examples of .pro files for the n900? (I never programmed for the n900) this is my first time and already I have to port the windows app to the mobile... :\

N900 doesn't use Windows GDI so I'd start by getting rid of that.

[rickrvo]

I disposed of that plugin as it wasn't very important for the version for the n900.

Now I'm having another problem which is the same on every other plugin that I'm trying to compile

which is:

...
Package Name : libjpeg
Version : 0.0.1
License : gpl
Using dpatch : no
Type of Package : Single
Hit <enter> to confirm:
Done. Please edit the files in the debian/ subdirectory now. libjpeg
uses a configure script, so you probably don't have to edit the Makefiles.
Package Creation: Running command 'dh_installdirs'.
Packaging Error: Could not copy 'E:\Projecto\uni_net-1.4.1-Mobile\uni_net-project\libjpeg\libjpeg' to 'E:\Projecto\uni_net-1.4.1-Mobile\uni_net-project\libjpeg\debian\libjpeg\\usr\local\bin\libj peg'.
Error while building project libjpeg (target: Maemo)
When executing build step ''

This is the output on the libjpeg plugin... on the attendees plugin the output is:

...
ar cqs libattendees.a debug/call_data.o
make[1]: Leaving directory `/e/Projecto/uni_net-1.4.1-Mobile/uni_net-project/plugins/attendees'
make: Leaving directory `/e/Projecto/uni_net-1.4.1-Mobile/uni_net-project/plugins/attendees'
The process "C:/nokiaqtsdk/maemo/4.6.2/bin/make.exe" exited normally.
Creating package file ...
Package Creation: Running command 'dh_installdirs'.
Packaging Error: Could not copy 'E:\Projecto\uni_net-1.4.1-Mobile\uni_net-project\plugins\attendees\attendees' to 'E:\Projecto\uni_net-1.4.1-Mobile\uni_net-project\plugins\attendees\debian\attendees\\usr\lo cal\bin\attendees'.
Error while building project attendees (target: Maemo)
When executing build step ''

I don't know why it keeps trying to copy 'E:\Projecto\uni_net-1.4.1-Mobile\uni_net-project\libjpeg\libjpeg and E:\Projecto\uni_net-1.4.1-Mobile\uni_net-project\plugins\attendees\attendees when the folder is only 1 libjpeg and not libjpeg\libjpeg... also targeting E:\Projecto\uni_net-1.4.1-Mobile\uni_net-project\plugins\attendees\debian\attendees\\usr\lo cal\bin\attendees with 2 \\ instead of 1.

it's happening on every plugin... the .pro of these 2 are:

attendees

TARGET = attendees
TEMPLATE = lib
CONFIG += staticlib \
debug_and_release
TRANSLATIONS += attendees.ts
SOURCES += src/call_data.cpp
HEADERS += include/call_data.h
INCLUDEPATH += include

libjpeg

QT -= core \
gui
CONFIG += qt debug_and_release
DEFINES -= UNICODE
TARGET = libjpeg
TEMPLATE = lib
DEFINES -= UNICODE
SOURCES += jutils.c \
jquant2.c \
jquant1.c \
jmemnobs.c \
jmemmgr.c \
jidctred.c \
jidctint.c \
jidctfst.c \
jidctflt.c \
jfdctint.c \
jfdctfst.c \
jfdctflt.c \
jerror.c \
jdtrans.c \
jdsample.c \
jdpostct.c \
jdphuff.c \
jdmerge.c \
jdmaster.c \
jdmarker.c \
jdmainct.c \
jdinput.c \
jdhuff.c \
jddctmgr.c \
jdcolor.c \
jdcoefct.c \
jdatasrc.c \
jdatadst.c \
jdapistd.c \
jdapimin.c \
jctrans.c \
jcsample.c \
jcprepct.c \
jcphuff.c \
jcparam.c \
jcomapi.c \
jcmaster.c \
jcmarker.c \
jcmainct.c \
jcinit.c \
jchuff.c \
jcdctmgr.c \
jccolor.c \
jccoefct.c \
jcapistd.c \
jcapimin.c
HEADERS += jversion.h \
jpeglib.h \
jpegint.h \
jmorecfg.h \
jmemsys.h \
jinclude.h \
jerror.h \
jdhuff.h \
jdct.h \
jconfig.h \
jchuff.h
win32:{QMAKE_CFLAGS += -mwindows
QMAKE_CXXFLAGS += -mwindows
LIBS += -Wl,-subsystem,windows
}
ReleaseLLDESTDIR = ../nsserver/release ../uni_net-classroom/release ../uni_net-student/release ../uni_net-student-mobile-maemo/debug ../uni_net-student-mobile-maemo/simulator/debug
DebugLLDESTDIR = ../nsserver/debug ../uni_net-classroom/debug ../uni_net-student/debug ../uni_net-student-mobile-maemo/release ../uni_net-student-mobile-maemo/simulator/release

both are without shadow builds.

[wysota]

I told you that your DLLDESTDIR values don't make sense. Do you even know what this variable is for?

[rickrvo]

I know that it is to create dll and linux uses .so files... but that's not the problem that is originating the error. I erased those lines and the "could not copy" error persists.

[wysota]

If you have to use some framework it is a good idea to understand what it does before you start using it. What is failing is a build step for creating a package for maemo which will fail on Windows regardless of what settings you have in your .pro file. First because you are using Windows so you can't run Debian packaging scripts and second because the .pro file has nothing to do with creating the package. It is done by Creator. Disable the packaging step in Creator and you'll probably be fine.

And DLLDESTDIR is not used to create dll files. It points to a directory where the library should be created if the goal of the project is to create a library. If you point it to several directories, where should the library be created? In each of them?

[rickrvo]

yes, on the windows version some plugins must have the .dlls on their folder to compile and work properly. I don't know if it is going to be necessary on maemo. On linux the .so files must be on the project's folder and not inside its debug and release folders.

I know that I won't be able to run debian scripts on windows, I was wondering if I could compile it on windows and then copy it to my n900. I compiled a helloworld app and it created a package sucessfully under windows and I installed it on the n900 and it worked.

I've disabled the packaging step and no errors were found and the .so files were created! thanks

now, generally, I just have to place the .so files on the main project folder and it should work right?

[wysota]

yes, on the windows version some plugins must have the .dlls on their folder to compile and work properly.

No, that's false.

I don't know if it is going to be necessary on maemo. On linux the .so files must be on the project's folder and not inside its debug and release folders.

No, that's false.

I know that I won't be able to run debian scripts on windows, I was wondering if I could compile it on windows and then copy it to my n900.

But it's not compilation that fails.

now, generally, I just have to place the .so files on the main project folder and it should work right?

I have no idea, it's your project.

[rickrvo]

1st No, that's false.

I'm telling you that on my project I must have the staticlib plugin .dll on zlib folder in order for zlib plugin to compile without erros because it uses some dependencies from the staticlib plugin. And all of the .dll's must be on the debug or release accordingly on the main app in order for them to work. that's why I have the DLLDESTDIR set to all those folders.

2nd No, that's false.

I compile the same project under linux and it doesn't create the .so on the other project's folders and it works as well...


I'll run more tests if anything comes up I'll post here.

Thank a lot wysota!

[wysota]

I'm telling you that on my project I must have the staticlib plugin .dll on zlib folder in order for zlib plugin to compile without erros because it uses some dependencies from the staticlib plugin.

1) Static library and dll are two completely different things (dll means "dynamically loaded library").
2) Static libraries are not plugins.
3) It doesn't have to be in the folder you say. You can tell your compiler where to look for libraries.
4) DLLDESTDIR says where a dynamic library you build will be placed. It says nothing about (and doesn't affect) static libraries.

What is false about your second statement is that you assume something has to be somewhere and not that it affects or doesn't affect anything. If you need to link against some library then tell the component that needs it where to find it instead of copying it around, having multiple instances and never knowing which is which. The whole point of a library is that you have one copy of it. Otherwise you can just include its source files directly in each component that needs the functionality.

[rickrvo]

for instance I'm trying to compile zlib project and it keeps giving me this error:

...
gcc -c -pipe -g -D_REENTRANT -Wall -W -fPIC -DQT_GL_NO_SCISSOR_TEST -DQT_DEFAULT_TEXTURE_GLYPH_CACHE_WIDTH=1024 -Ic:/NokiaQtSDK/Maemo/4.6.2/sysroots/fremantle-arm-sysroot-20.2010.36-2-slim/usr/share/qt4/mkspecs/default -I. -Ic:/NokiaQtSDK/Maemo/4.6.2/sysroots/fremantle-arm-sysroot-20.2010.36-2-slim/usr/include -Idebug -o debug/adler32.o adler32.c
rm -f liblibz.so.1.0.0 liblibz.so liblibz.so.1 liblibz.so.1.0
g++ -Wl,-rpath-link,/usr/lib -shared -Wl,-soname,liblibz.so.1 -o liblibz.so.1.0.0 debug/zutil.o debug/uncompr.o debug/trees.o debug/minigzip.o debug/maketree.o debug/infutil.o debug/inftrees.o debug/inflate.o debug/inffast.o debug/infcodes.o debug/infblock.o debug/gzio.o debug/deflate.o debug/crc32.o debug/compress.o debug/adler32.o -LC:/NokiaQtSDK/Maemo/4.6.2/sysroots/fremantle-arm-sysroot-20.2010.36-2-slim/usr/lib -L../staticlib/ -L../plugins/attendees -lz -ljpeg -lssl -lcrypto -lnsl -luni_net -lattendees -lpthread
make[1]: Leaving directory `/e/Projecto/uni_net-1.4.1-Mobile/uni_net-project/zlib'
make: Leaving directory `/e/Projecto/uni_net-1.4.1-Mobile/uni_net-project/zlib'
../staticlib//libuni_net.so: file not recognized: File format not recognized

collect2: ld returned 1 exit status

make[1]: *** [liblibz.so.1.0.0] Error 1
make: *** [debug] Error 2
The process "C:/nokiaqtsdk/maemo/4.6.2/bin/make.exe" exited with code %2.
Error while building project libz (target: Maemo)
When executing build step 'Make'

it is trying to access the staticlib's .so on its project folder. I still haven't figured out why this error occurs and what I'm doing wrong here... :\ but as well as windows zlib needs the staticlib's .dll to compile.

[wysota]

See that?

../staticlib//libuni_net.so: file not recognized: File format not recognized

It tries the library from this directory because it's told to look for it there by the -L flag. The library is probably meant for a different platform or is not a shared object file at all.