Hi,
Den, do you know who's package maintainer for libQt4Pas on Ubuntu ? Problem is with -mstackrealign, that should be added for ubuntu 10.10 which uses qt-4.7 (apps crashes). So package should be updated.

zeljko

I maintain the packages in Debian and Ubuntu. An updated version has already been prepared and is enqueued for Debian Sid. I can the ask for an FFe to make it available in Ubuntu too. Cheers,
Matthias Klumpp

Thanks

zeljko

Hi!
I applied the attached patch to the Debian and Ubuntu packages, which adds the -mstackrealign flag if an x86_64 or x86 platform is detected, as this GCC flag is not available for other targets than these two. You might want to add it to the upstream sources too. Cheers,
Matthias

-------------- next part --------------
Description: Compile Qt4 bindings with -mstackrealign. (Required for Qt >= 4.7, since sse2 is enabled by default) Forwarded: yes
Author: Matthias Klumpp
Last-Update: 2011-03-14
--- a/Qt4Pas.pro
+++ b/Qt4Pas.pro
@@ -31,12 +31,21 @@
CONFIG += dll
CONFIG += warn_off

+contains(QMAKE_HOST.arch, x86_64) {
+ message("Compiling with stackrealign on x86_64")
+ QMAKE_CXXFLAGS += -mstackrealign
+}
+
+contains(QMAKE_HOST.arch, x86) {
+ message("Compiling with stackrealign on x86")
+ QMAKE_CXXFLAGS += -mstackrealign
+}

!equals(QT_MAJOR_VERSION,4)|!equals(QT_MINOR_VERSION,5) { message("This pascal binding should be used for 4.5.3 and current Qt is" $$QT_VERSION) }

-# Available Binding Platforms: see http://wiki.freepascal.org/Qt4_binding#Supported_Platforms +# Available Binding Platforms: see http://wiki.freepascal.org/Qt4_binding#Supported_Platforms

target.path = $$[QT_INSTALL_LIBS]

@@ -44,18 +53,18 @@
PLATFORM = MSWINDOWS
target.path = $$[QT_INSTALL_BINS]
}
-
-embedded:PLATFORM = QTOPIA
+
+embedded:PLATFORM = QTOPIA

unix:!embedded:!mac:PLATFORM = BINUX

mac {
PLATFORM = DARWIN
CONFIG += lib_bundle
- }
+ }

message("Pascal Qt Interface for binding platform:" $$PLATFORM) -DEFINES += $$PLATFORM
+DEFINES += $$PLATFORM
message("Install location:" $$target.path)

INSTALLS += target

I guess that this patch will work for Fedora and other packagers ?

zeljko

Matthias Klumpp wrote

I applied the attached patch to the Debian and Ubuntu packages, which adds

you might consider cleaning up the patch (not for me, but for Debian)

the -mstackrealign flag if an x86_64 or x86 platform is detected, as this

I found x86_64 in the Qt source code, but x86 ??? Did you test this :-) I tried on 32bit linux and got i686.
Reading the qt source code I see why: qmake/project.cpp

GCC flag is not available for other targets than these two.

Good that you noticed that. Does the compiling fail on other architectures ? Or do you just get a warning ?

However using QMAKE_HOST.arch will cause problems when cross compiling. see: http://bugreports.qt.nokia.com/browse/QTBUG-9160

You might want to add it to the upstream sources too.

I had already added mstackrealign in all cases,
I will now use : 86 as keyword, I hope there is no other architecture that has 86 in it

regards,

Den Jean

Hi!

Den Jean wrote

On Wednesday 06 April 2011 14:10:54 Matthias Klumpp wrote: > I applied the attached patch to the Debian and Ubuntu packages, which > adds you might consider cleaning up the patch (not for me, but for Debian)

It just removes blank spaces at the end of lines - not dramatic, but right, I'll better clean it up.

> the -mstackrealign flag if an x86_64 or x86 platform is detected, as

this

I found x86_64 in the Qt source code, but x86 ??? Did you test this :-) I tried on 32bit linux and got i686. Reading the qt source code I see why: qmake/project.cpp

Oh, really ugly! I relied on a mailing list positing of a Qt dev, but just "x86" does not work indeed.

> GCC flag is not available for other targets than these two. Good that you noticed that. Does the compiling fail on other

architectures

? Or do you just get a warning ?

It fails, otherwise this patch would not have been necessary. (The first try broke all builds :( But the GCC docs say clearly this should only be used on x86_64 and x86)

However using QMAKE_HOST.arch will cause problems when cross compiling. see: http://bugreports.qt.nokia.com/browse/QTBUG-9160

Okay... This is no problem for Debian, but if there's a more sane solution, I'm happy to add it.

> You might want to add it to the upstream sources too. I had already added mstackrealign in all cases, I will now use : 86 as keyword, I hope there is no other architecture that has 86 in it

Can you do a bugfix upstream release or send me this patch or point me to your VCS if there is any?

Thanks!
Matthias

Perhaps Debian cross compiles for the arm releases

Can you do a bugfix upstream release or send me this patch

the qmake function contains does not work for substr, will look into it. I will make a new release when the
needed patches of the previous release(V2.2) are incorporated.

Den Jean wrote

> > However using QMAKE_HOST.arch will cause problems when cross

compiling.

Okay, thanks! Please note the following: This change will most likely not be in Ubuntu Natty, as we're in Main Release Freeze soon. Also, if the new release breaks compatibility with LCL 0.9.30, I don't know if I can include it, because there are applications in Debian requiring the Qt LCL.
Cheers,
Matthias

The patches I submitted are necessary for one platform and do not change anything on the other platforms.

Can Zeljko give me a timing when these will be applied ?

It would be nice to have the next release unite all platforms again.

It's up to you. If we don't change minimum lib version (4.5) then you can prepare update anytime.

zeljko

I think you misunderstand, I am awaiting application of the the patches supplied in June 2010 for V2.2, this will allow me to create a new binding V2.3 starting from the last work. http://lists.lazarus.freepascal.org/pipermail/qt/2010-June/001547.html

Maybe, so I have to apply maemo patch and that's it ?

zeljko

zeljko wrote

Maybe, so I have to apply maemo patch and that's it ?

yes, and after release the latest qt4.pas (probably compatible)

Den Jean wrote

On Tuesday 12 April 2011 18:51:39 zeljko wrote: > Maybe, so I have to apply maemo patch and that's it ? yes, and after release the latest qt4.pas (probably compatible)

What do you mean by this ? change qt4.pas to use maemo (it's in patch already) or what ?

zeljko

zeljko wrote

What do you mean by this ? change qt4.pas to use maemo (it's in patch already) or what ?

When I make the new release, it will provide again a new qt4.pas. I do not know yet what will be the differences, but they should be compatible.

Uf... I'm confused now :) ... just tell me what should I do and I'll do that :)

zeljko

2011/4/13 zeljko :

Apply this patch:
Patch for Lazarus:
http://users.telenet.be/Jan.Van.hijfte/qtforfpc/maemo.diff.txt.tar.gz

Vincent

could you try this for one or more platforms you
have (32/64 win/linux/osx) and inform me if it works.

I only found time for 32bit Linux.

Qt4Pas.pro:

...
X86 = $$find(QMAKE_HOST.arch, i*86)
! isEmpty( X86 ) {
message("Added -mstackrealign to CXXFLAGS in support of SSE on arch " $$QMAKE_HOST.arch) QMAKE_CXXFLAGS += -mstackrealign
}
...

There's also problem with qt-4.7 under windows (someone reported on lazarus forum). dll should be compiled with -mstackrealign, if mingw gcc compiler doesn't support then
we can do nothing, except rebuilding complete qt on win32 with disabled sse2.

zeljko

Den Jean wrote

When I make the new release, it will provide again a new qt4.pas. I do not know yet what will be the differences, but they should be compatible.

whilst comparing a new qt4.pas with the one in lazarus trunk I found that GetPtrIntArrayAddr was changed downstream. Were there problems? I do not remember. I just like to know.

>>>... original (mine) ...

// PtrInt Array Access from c-code
function GetPtrIntArrayAddr(PArr : PPtrIntArray): PPtrInt; cdecl; export;
begin
    Result := @PArr^[0];
end;

>>>... lazarus trunk ...

// PtrInt Array Access from c-code
function GetPtrIntArrayAddr(PArr : PPtrIntArray): PPtrInt; cdecl; export;
begin
  if PArr^ = nil then                 <---------- extra
    Result := nil                     <---------- extra
  else                                <---------- extra
    Result := @PArr^[0];
end;

2011/4/13 Den Jean :

The change was in
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&root=lazarus&revision=25368

Do you want me to ask Martin for further explanation?

Vincent

Vincent Snijders wrote

Do you want me to ask Martin for further explanation?

yes please, changes like this can be valid fixes
but can also hide root causes. And pointers
should always be taken serious :-)
This code is old, I am not looking forward
having to go through all use case :-(

huuuu...I haven't seen this change hmmm....Den is there any other change in qt45.pas ? Martin ?

zeljko

huuuu...I haven't seen this change hmmm....Den is there any other change in qt45.pas ?

no