Using fpc/trunk
I cannot compile lazarus/trunk on windows 8 64bit

win32object.inc(565,78) Error: Incompatible type for arg no. 4: Got "<address of procedure(QWord;LongWord;LongWord;LongW ord);StdCall>", expected "<procedure variable type of
procedure(QWord;LongWord;QWord;LongWord);StdCall>"

Needing to build for Win8x64.

2012/10/28 Andrew Brunner :

What is on that line? What fpc and lazarus trunk revision do you use?

Vincent

I'm exporting now ...
Lazarus revision 39186
FPC revision 22875
But this was from yesterday so it would be "-" at least on revision.

Downloaded lazarus install for Windows 64 from lazarus.freepascal.org website
It came with FPC 2.6.0 and placed in ./lazarus/fpc I opened my project but could not build my project - fpc didn't find the postgresql component

So Then I:
Downloaded both fpc and lazarus from svn.
Built fpc with no problems.
Ran fpcconfig (forgot exact command) and had to fix APP_DATA with my actual path for Units in the fpc.cfg file.
Building lazarus faild with that error.

I think maybe it was because I exported svn lazarus "on-top" of installed lazarus though.

Another problem is that when I go to install Lazarus in my Program Files Folder I get
"Selected folder contains spaces, please select a folder without spaces in it."

This IMO is totally unacceptable. Some people aren't going appreciate that. But having A Lazarus install outside Program Files is highly irregular.

What was the cause for this decision?

I would like strongly note my rejection and consider this a design flaw.

2012/10/29 Andrew Brunner :

In the past some third part tools didn't work corectly with paths with space. To prevent trouble, Lazarus refuses to install in Program Files. (A highly irregular install is preferable over an install, that results in a Lazarus that doesn't work)

Nobody bothered to check if there are still problems.

Vincent

Vincent Snijders wrote

In the past some third part tools didn't work corectly with paths with space. To prevent trouble, Lazarus refuses to install in Program Files. (A highly irregular install is preferable over an install, that results in a Lazarus that doesn't work)

I think this was a really bad move. Failing / Improving the tools would have been
the better move.

Nobody bothered to check if there are still problems. Vincent

Agreed. Unless someone complains about something the problem can go unaware and is not going to get resolved until attention is brought to it.

The project overall is what the big pictures is about here. First come Lazarus users are going to install it for windows and certain percent of these are stuck in their Microsoft world - they simply won't be able to see past this. Life outside the Program Files folder is a complete mystery. LOL. Meaning, they will go back to their Microsoft development platform de'Joure and something inside them will say "See it's better with Microsoft commercial development tools".

This is in direct opposition to power users - who I guess are mainly using Linux. These can get around anything. While the real power users just simply use Windows as build machines, they are not necessarily going to care about the Lazarus "Brand". After all, some power users are Lazarus contributors.

The space path issues is a show stopper. Each day Lazarus is downloaded as no space paths allowed translates into a stunted growth rate. This is simply forcing some developers to abort the install and simply put lazarus on the back burner for another version increment.

But as it stands now, Release 1.0.2 is not a success due to the database component problems I found. I forgot about that too :-) But that demographic a subset of this one I'm pretty sure.

After installing Lazarus 1.0.2 binaries I try to compile my project and get

Fatal: Can't find unit pqconnection used by uDatabase

If I click on the pqconnection unit CodeTools brings me right to the proper file.

What can't fpc find the unit? What entry is missing from the fpc.cfg file?

2012/10/29 Andrew Brunner :

Why? If it was not fixable at that time? We don't create the linker, nor the debugger.

It is a known issue for me. There even is a bug report about it. Just nobody willing to work on it. And this is so easy to do for a user. Simply rename the Lazarus directory and update the environment options accordingly and see what breaks. For example debugging, external linker, resource compiling. I think it is better now, because a lot things have been tested when compiling projects in paths with spaces.

It is better.

Do you care? Then test.

Fine, that doesn't hurt me.

And still nobody bothered to test if it works in a directory with spaces. IMHO it is a nice to have, so I won't spend time on testing, just on disabling it

Vincent

Ranting even more won't get anything done. Test and create patches, stop complaining.
If you don't want to do that, choose a different development environment where you can install in paths with spaces.

Afaik it is/was "windres" (resource compiler). It also (may) affect user projects, and there have been users running into trouble, because they saved there project to a folder which contained spaces.

As Vincent said this (windres) comes from another project, and we are not in charge of it. Also afaik the makers know, but the problem is not simple to fix (for them), as it would require changes to the command-line reading, and any way of doing it might break other projects. Something like that.

Alse there is a bug in XP itself, that in special cases will prevent launching an app in folders with spaces (this is unrelated to lazarus or tools used by lazarus / this appears to be XP itself). In Lazarus it can happen using the debugger (but again, according to my research it is XP, not the debugger).
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Error_193_.28Error_creating_process_.2F_Exe_not_found.29

Vincent Snijders wrote

Why? If it was not fixable at that time? We don't create the linker, nor the debugger.

I have no idea about linker and debugger idiosyncrasies. I don't know myself. I am merely pointing out facts.

Ok. There are issues. There has to be progress and resolution to move forward.

It is better.

Just go give you perspective here. The enemy is NEVER better. And this particular one is as bad as it gets.

Do you care? Then test.

Reality check here. I've been developing / reporting because of Aurawin for about 7 years.
Sometimes my project has had to wait for Lazarus developers to further the platform. There
are times I have prayed for help for you guys to get further along faster. I have invested my
time and money into Aurawin which depends on Lazarus and FPC.

I have been offering oversight and strategy hints for years.

This issue will affect me, as I plan to release 2 open source projects. Others trying to
build Aurawin projects from source will find it impossible. And that is ok (for now).
As a substitute at least I MUST be able to release binary distros.

Personally, I can live without windows support. But some users cannot. While I can see how windows is becoming more and more deprecated, having no Windows cloud sync software is a problem.

Reinier Olislagers wrote

Ranting even more won't get anything done. Test and create patches, stop complaining.

I'm not complaining, just alerting first and trying to see how to get resolution via the proper channels.

If you don't want to do that, choose a different development environment where you can install in paths with spaces.

Please refrain from self deprecation, just stick to the issues. If you can't offer insight to resolution just keep from posting.

I can see he is reluctant. Neither one of us knows how to resolve this.

Yes, of course. I'll leave you to it then.

El 29/10/2012 16:59, Andrew Brunner escribi?:

Hello,

In the past other development environments (or even commercial apps. like some POS) create a "subst'ed" drive to run the software, so in the "start" it subst to a new drive letter, and move execution to that drive.

With XP and upper a hardlink to "X:\Lazarus" from "Program Files" could be created on installation.

FPC also has problems with substituted drives :-(

A friend of mine cannot even run a HelloWorld type program, having his libraries in an substituted drive - these files are never found!

DoDi

Maybe you have a wrong ppu file or maybe you have an include file that conflicts.
Try in the IDE "Run / Clean up build files".

Mattias

2012/10/31 Mattias Gaertner

default installation, because the postgresql dll was not yet tested with fpc and win64, so nobody knew it actually worked.

Vincent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121031/081a7913/attachment.html>