[krishnaa]

Hi,

My objective is to create a shared library and link it with app and call some APIs of dll in the app.

Platform Details:
-----------------
Qt for Symbian 4.6.0
Qt Creator 1.3.0
S60 5th edition
Abld is build system

Below are the steps followed and issued faced.

1. Creating "App"
I created an app called "MyApp" using Qt-Creator "Qt4 Gui Application" option. Default tool chain used to build is GCCE and able to build it.

2. Creating "Shared Library"
I created a shared library called "MyDLL" using Qt-Creator option "C++ Library" then "Shared Library". Default tool chain is GCCE and able to built it.

3. Link "Shared Library" with "App"
I don't find any good documentation of how to do this, the whole sequence of steps needed. I figured that LIBS needs.

Added below line to MyApp.pro file
LIBS += -lMyDLL.dll

as suggested by qmake help, then building the app gives error

make[2]: *** No rule to make target `\S60\devices\S60_5th_Edition_SDK_v1.0\epoc32\release\armv5\LIB\MyDLL.dso', needed by `\S60\devices\S60_5th_Edition_SDK_v1.0\epoc32\release\gcce\udeb\MyApp.exe'. Stop.
make[1]: *** [TARGETMYAPP_0XE25A8EF2] Error 2

Question is : I am working with tool chain GCCE, why make is looking into ARMV5 path?. i.e. `\S60\devices\S60_5th_Edition_SDK_v1.0\epoc32\release\armv5\LIB\MyDLL.dso

4. Trying to work with Tool chain ARMV5
First, I want to build the MyDLL with Armv5. I created a new project settings with tool chain as ARMV5, then build MyDLL. Following error occrued

Error: C0000U: Unrecognized option '--visibility_inlines_hidden'.
make[2]: *** [\S60\devices\S60_5th_Edition_SDK_v1.0\EPOC32\BUILD\Qt-Projects\DLL\MyDLL\MYDLL_0XE11197E8\ARMV5\udeb\mydll.o] Error 1
make[1]: *** [TARGETMYDLL_0XE11197E8] Error 2

The generated MyDLL_0xE11197e8.mmp file has the line
OPTION ARMCC --visibility_inlines_hidden --fpu softvfp


I feel, creating a library is a very basic thing and it should be very easy for any body to do. There should be a single wiki page explaining all the steps with code whereever possible.

I feel we should have detailed docmentation for Static Library, Shared Library and Plugins with code examples.

Let me know if I miss any thing...

-Krishna.

[koshui]

Hi, I'll answer here though you posted on mail-list as well.

Originally Posted by krishnaa

Hi,

Added below line to MyApp.pro file
LIBS += -lMyDLL.dll

this is correct.

as suggested by qmake help, then building the app gives error

make[2]: *** No rule to make target `\S60\devices\S60_5th_Edition_SDK_v1.0\epoc32\release\armv5\LIB\MyDLL.dso', needed by `\S60\devices\S60_5th_Edition_SDK_v1.0\epoc32\release\gcce\udeb\MyApp.exe'. Stop.
make[1]: *** [TARGETMYAPP_0XE25A8EF2] Error 2

you need to buid the dll first.

Question is : I am working with tool chain GCCE, why make is looking into ARMV5 path?. i.e. `\S60\devices\S60_5th_Edition_SDK_v1.0\epoc32\release\armv5\LIB\MyDLL.dso

This is the default directory all libs go to no matter what the dll target is.

4. Trying to work with Tool chain ARMV5
First, I want to build the MyDLL with Armv5. I created a new project settings with tool chain as ARMV5, then build MyDLL. Following error occrued

Error: C0000U: Unrecognized option '--visibility_inlines_hidden'.
make[2]: *** [\S60\devices\S60_5th_Edition_SDK_v1.0\EPOC32\BUILD\Qt-Projects\DLL\MyDLL\MYDLL_0XE11197E8\ARMV5\udeb\mydll.o] Error 1
make[1]: *** [TARGETMYDLL_0XE11197E8] Error 2

The generated MyDLL_0xE11197e8.mmp file has the line
OPTION ARMCC --visibility_inlines_hidden --fpu softvfp

You need to update your RVCT version to 2.2. build 686 as stated in the documentation.

[lucian]

If your DLL is properly build and your DSOs are generated then the problem is in how you have actually specified the library name in the .pro file. Which is also easy to verify by looking at the generated *.mmp file (of course that does not help if you are new to Symbian as well)

Lose the extension and let the toolchain pick-up the suitable library file. Btw, you don't specify the .DLL in your project to begin with, you specify the link library.

This should do it:

LIBS += -lMyDLL

[krishnaa]

Hi,

Thanks for the suggestions.

- MyDLL build

In the step 2, MyDLL shared library is created and also build properly without any errors. Build generated MyDLL.dll in epoc32\release\gcce\udeb, but MyDLL.dso wasn't generated in epoc32\release\armv5\lib. After adding following line to .pro of MyDLL it generated the MyDLL.dso file.

MMP_RULES += EXPORTUNFROZEN

- GCCE vs ARMV5

Looks like epoc32\release\armv5\LIB\ is common destination folder for libraries, i.e MyDLL.dso for gcce build and MyDLL.lib for armv5 build.

I was able to create, link and use the DLL with App using both GCCE, and also with ARMV5.

- RVCT 2.2 build 686

If you have an earlier version of RVCT you’ll need to remove --visibility_inlines_hidden from the QMAKE_CXXFLAGS.ARMCC line in mkspecs\common\symbian\symbian.conf.

- Deploy to device

By adding following lines to MyApp.pro the dll can be deployed on to device

mydll.sources = MyDLL.dll
mydll.path = \sys\bin
DEPLOYMENT += mydll

[iain]

Originally Posted by krishnaa

- MyDLL build

In the step 2, MyDLL shared library is created and also build properly without any errors. Build generated MyDLL.dll in epoc32\release\gcce\udeb, but MyDLL.dso wasn't generated in epoc32\release\armv5\lib. After adding following line to .pro of MyDLL it generated the MyDLL.dso file.

MMP_RULES += EXPORTUNFROZEN

That was unwise - now you can't maintain BC on the DLL interface.

Originally Posted by krishnaa

- RVCT 2.2 build 686

If you have an earlier version of RVCT you’ll need to remove --visibility_inlines_hidden from the QMAKE_CXXFLAGS.ARMCC line in mkspecs\common\symbian\symbian.conf.

That would also be unwise, although less so. You probably don't want your inline functions to appear in your DEF file - if nothing else, it gives people the impression that they might be able to change them when there's no guarantee that other users will use the definition in your DLL. Anyway 2.2 build 686 is on ARM's website - just download it (especially since it has other fixes that are required for Qt to work correctly).

[krishnaa]

Iain,

You mean as the exports are not frozen (EXPORTUNFROZEN), BC won't be maintained?. If so, it can be changed to EXPORTFROZEN to maintain BC, but the point is without this statement the MyDLL.dso or MyDLL.lib wasn't getting generated.

-Krishna.

[iain]

Originally Posted by krishnaa

Iain,

You mean as the exports are not frozen (EXPORTUNFROZEN), BC won't be maintained?. If so, it can be changed to EXPORTFROZEN to maintain BC, but the point is without this statement the MyDLL.dso or MyDLL.lib wasn't getting generated.

-Krishna.

Yes, if you use EXPORTUNFROZEN all bets are off. There is no EXPORTFROZEN keyword - the default is frozen. If you weren't seeing a .dso or .lib being generated it's highly likely that you forgot to freeze and rebuild (the first time you build, with no DEF file, the build system won't generate any libs or dsos, you're expected to freeze and rebuild). There should be a warning about this printed on the console, saying something like "No DEF file found, not attempting to generate lib file; rebuild once DEF files frozen".

[krishnaa]

Iain,

In Symbian programming, after the build command abld build armv5 udeb, abld freeze armv5 command is called to create the lib file for the first time. So, the question is, using Qt how to do the same thing like calling abld freeze armv5, so that the .lib gets created?. Is it that need to add a custom build step or so?.

-Krishna.

[orbital]

After building with make, you can use abld or sbs commands normally.
The makefile is just a wrapper that runs the symbian build tools.

[krishnaa]

orbital,

It would be wise, if it can be done using Qt-creator. I tried the "Custom Process Step" in Qt-Creator "Projects" mode option, but no luck.

If you see the whole process of create APP, DLL every thing is done using Qt-Creator. Just for this step of running "abld freeze" if user had to do it from command prompt. That won't be good experience.

-Krishna.

[krishnaa]

I've created a wiki page with code examples of how to create and link a DLL with APP.

http://developer.symbian.org/wiki/in...ion(APP)_in_Qt

[iain]

Originally Posted by krishnaa

I've created a wiki page with code examples of how to create and link a DLL with APP.

http://developer.symbian.org/wiki/in...ion(APP)_in_Qt

If I were you I would be putting a big "under construction" tag on that page. As I said, using EXPORTUNFROZEN is not the right thing to do.

[hamishwillee]

Hi All

I plan on building on this document over the next few days. Will probably need you to test it for RVCT.

One question, how do you export a header to /epoc32/include?

Regards
Hamish

[lucian]

Symbian style: PRJ_EXPORTS in BLD.INF
Qt style: BLD_INF_RULES.prj_exports in *.pro file

I've never used it but I bet it goes as

BLD_INF_RULES.prj_exports += "../inc/header.h /epoc32/include/header.h"

[hamishwillee]

Originally Posted by lucian

Symbian style: PRJ_EXPORTS in BLD.INF
Qt style: BLD_INF_RULES.prj_exports in *.pro file

I've never used it but I bet it goes as

BLD_INF_RULES.prj_exports += "../inc/header.h /epoc32/include/header.h"

Thanks Lucian! Happen to know where a file gets exported to on windows/mac/linux? Thinking I should add these for completeness.

[iain]

Originally Posted by hamishwillee

Thanks Lucian! Happen to know where a file gets exported to on windows/mac/linux? Thinking I should add these for completeness.

It doesn't, because this is a Symbian specific thing, as given away by the fact you're writing BLD_INF_RULES.

[hamishwillee]

For anyone who has tried exporting headers, there are issues if you're calling a project from a project.
http://bugreports.qt.nokia.com/browse/QTCREATORBUG-764

[hamishwillee]

Hi
I've re-written Krishna's doc: http://developer.symbian.org/wiki/in...loying_the_DLL

Can you guys check it out and confirm it is sane/useful. It still needs latest example to be added/updated.

It also needs me to specify how you
a)mark a SIS file as a dependency
b) include a SIS file in a SIS file
in Qt. Ideas?

Cheers
H

[lucian]

Here's a project with both use cases exemplified:

#-------------------------------------------------
#
# Project created by QtCreator 2010-02-26T12:00:10
#
#-------------------------------------------------

QT       += core gui

TARGET = SymbianDeplyment
TEMPLATE = app


SOURCES += main.cpp\
        symbiandeployment.cpp

HEADERS  += symbiandeployment.h

FORMS    += symbiandeployment.ui

symbian {

dependency.pkg_prerules= "(0x12345678),1,0,0,{\"CocoaUI lib\"}"
embeddedsis.pkg_postrules = "@\"..\some\path\some_file.sisx\",(0x12345678)"

DEPLOYMENT = dependency embeddedsis
}

With the corresponding output in PKG:

; SymbianDeplyment_template.pkg generated by qmake at 2010-02-26T12:27:15
; This file is generated by qmake and should not be modified by the user
;

; Language
&EN

; SIS header: name, uid, version
#{"SymbianDeplyment"},(0xEc38b98c),1,0,0

; Localised Vendor name
%{"Vendor"}

; Unique Vendor name
:"Vendor"

; Manual PKG pre-rules from PRO files
(0x12345678),1,0,0,{"CocoaUI lib"}

; Executable and default resource files
"symbian_SDK/epoc32/release/$(PLATFORM)/$(TARGET)/SymbianDeplyment.exe"    - "!:\sys\bin\SymbianDeplyment.exe"
"/symbian_SDK/epoc32/data/z/resource/apps/SymbianDeplyment.rsc"    - "!:\resource\apps\SymbianDeplyment.rsc"
"/symbian_SDK/epoc32/data/z/private/10003a3f/import/apps/SymbianDeplyment_reg.rsc"    - "!:\private\10003a3f\import\apps\SymbianDeplyment_reg.rsc"

; Manual PKG post-rules from PRO files
@"..\some\path\some_file.sisx",(0x12345678)

[orbital]

Hamish:

For deploying executables, it is simpler than in your document.

symbian: {
addFiles.sources = qtenginedll.dll
addFiles.path = /sys/bin
DEPLOYMENT += addFiles
}

QMAKE will generate the correct source path for you (platform and urel/udeb are resolved when calling 'make sis' or building the pkg with carbide)

If you want to deploy additional data files, epocroot can be specified like this:
$${EPOCROOT}

Lucian:

Your examples are correct, except you should use unix path separators so that the project can be built on a linux or windows SDK without changes.

[lucian]

Linux? What's Linux? You are right, I should try to get used to that.

In one of my projects I have this code:

    # addFiles.sources = $(EPOCROOT)/epoc32/release/$(PLATFORM)/$(TARGET)/SmsEngine.dll
    # addFiles.path = !:/sys/bin
    # or
    addFiles.pkg_postrules = "\"$(EPOCROOT)\\epoc32\\release\\$(PLATFORM)\\$(TARGET)\\SmsEngine.dll\" - \"!:\\sys\\bin\\SmsEngine.dll\""

    DEPLOYMENT += addFiles

I believe that I had this tested at the time and both constructs work. The advantage of the later seems to be that allows me to specify the destination file name, while the firs one seems to restrict me to a file path. Or I didn't find the right parameter for changing it.

As I remember

addFiles.path = !:/sys/bin/SmsEngine.dll

seems to think that SmsEngine.dll is a plug-in and in this case additional PKG content is generated.

[orbital]

pkg_prerules and pkg_postrules add the text verbatim to the pkg file.
Deployment using .sources and .path is consistent with Qt on other platforms, but doesn't allow you to have different source and destination filenames.

In theory, you could do:

addfiles.sources = SmsEngine.dll
symbian: addfiles.path = !:/sys/bin
wince*: addfiles.path = .

[lucian]

Indeed, that seems to be the limitation. This is why probably both ways should be documented/exemplified so that when customization of the name is needed (e.g. for the autostart registration file) one knows that a possible solution is pkg_postrules

[orbital]

Does something like this not work?

autostart.sources = $${EPOCROOT}epoc32/data/z/resource/101f875a/12345678.rsc
autostart.path = !:/resource/101f875a/import
DEPLOYMENT += autostart

[lucian]

Nope. The startup list registration resource must be installed in the [12345678].rsc format while the toolchain doesn't really like to process a file with that name. So you will end-up having to build it as 12345678.rsc (or any other name) while at install time it should be renamed as [12345678].rsc

So we are back to the problem of having to specify the file name at destination.

[hamishwillee]

Lucian, Orbital

I've updated the document as you've suggested. Thank you both very much for your help - I think this now has a reasonable coverage of the topic. Please feel free to suggest any improvements.

On the topic of deploying applications, I think this is documented in an unclear and confusing manner in the "official" places: e.g.
http://qt.nokia.com/doc/4.6/deployment-symbian.html
http://qt.nokia.com/4.6/symbian-with...n-applications
http://qt.nokia.com/doc/4.6/qmake-va...tml#deployment

I've started to write a better version here: http://developer.symbian.org/wiki/in...Qt_Application
I will try and capture the elements you've discussed here. Still quite a bit of work to go, and I'm still not sure of the structure. If you have any examples that can be cut and pasted into the empty sections that would be appreciated.

Regards
Hamish

PS
Would I be correct in thinking that the smart installer should be given its own UID - a default one appears to be applied, but presumably you wouldn't want every application to have the same smart installer UID?
In addition, is there any advice you can give re whether the embedded SIS should be smart installer version, or the embedding application, or both?

[lucian]

"Over-riding the default PKG file behaviour" ? I hope you mean "Over-riding the default generated PKG content" or something of that nature

I would try to create parallels between common PKG script use cases (from SDK docs) and their Qt counterparts. Like how to deploy a file, a binary, a plug-in, an embedded SIS file, an autostart registration file ...

Then moving on to more complex tasks: language dependent files, options, query system properties (e.g. manufacturer, device model)

In fact what I think needs to be made clear is that Qt generates PKG scripts (one should learn that language) and that for big and complex projects a lot of customization of the installation scripts may be needed, which may make qmake's DEPLOYMENT variable rather unsuitable. At which point remains to be seen whether it is better to have the PKG file generated by one big pkg_postrules string or to have an independent PKG file maintained for that project.

[hamishwillee]

Hi Lucian,

Thanks very much. That is pretty much the approach I was hoping to convey from the document structure and the statements in the introduction. The goal being to do three things:
1. Help people understand that they need to understand the package file format
2. Provide a library of cut and paste examples
3. Explain how the default_deployment mechanism works, because this was pretty unclear to me.

I like your point re the fact that sometimes you might choose to maintain a more complex pkg file using a different approach (ie as a postrule or in its own file).

Still thinking about this though.

Regards
H

[hamishwillee]

I've posted a message on FN here: http://discussion.forum.nokia.com/fo...91&postcount=4

Which basically asks the question "how to I control the content of the smart installer pkg file". Some of the values (e.g. Vendor) come from the .PRO file, but there doesn't seem to be any obvious way to change its UID or name.

[hamishwillee]

... found the answer for the first bit (how you change the values)
DEPLOYMENT.installer_header = 0x12345678

I'm assuming you need to change the UID because bad things generally happen if you have two SIS files with the same UID?

Also, is there any way to modify version Qt dependency to Qt? I assume not