Indy 10 installation instructions on Wiki needs
clarification/reorganisation
lazarus / 38-Networking and Web Programming
----------------------------------------------------------------------
JD · 2013-05-03 09:40
Hi there everyone,
I just visited the Indy10 page on the Lazarus Wiki
http://wiki.lazarus.freepascal.org/Indy_with_Lazarus and the
installation instructions can be a bit confusing.
In my opinion, the installation instructions should be divided into
two sections:
a) Installation from the stable Lazarus version (Indy 10.2.XX)
How to install
How to install[2]
How to install (confirmed) on Windows - Indy 10.2.03
b) Installation from SVN at http://indy.fulgan.com/ (Indy 10.5.XXXX)
How to install [3] Windows, Indy 10.5.8.0
I wrote the instructions for installing the SVN version of Indy10 (it
was added to the Wiki by someone else) and it works perfectly in
Windows and Linux. I just refreshed my installation this morning as
you can see from the attached screenshot. Therefore, the Wiki
instructions for (b) above should say that the installation
instructions work in Windows and Linux. I know because I've installed
it on both of them.
This way, new users can decide what version they want to install and
use.
Cheers,
JD
----------------------------------------------------------------------
ChrisF · 2013-05-03 12:15
In fact, there are still a few issues concerning the Indy installation
for FPC (for the current fulgan release, I mean). Some of them are
concerning the Windows flavor only, while some others are more
general:
-you shouldn't have to put all the files into one single directory.
It's just because the indylaz.lpk script is not correctly defined to
access to the concerned sub-directories. A minor change can fix it,
-you have to compile the package twice, mostly of the time. Because of
an issue into the FPC compiler: see bug reports
http://bugs.freepascal.org/view.php?id=19673 and
http://bugs.freepascal.org/view.php?id=24121 . Well, in fact only one
file is recompiled the second time,
-icons inside the IDE are outdated. They are corresponding to the old
16 colors ones, though the 256 colors version is available
(furthermore a few ones are missing); because the .lrs files have not
been updated. See attached capture for a sample with the 256 colors
version.
I've planned to propose my fixes for the FPC installation; I guess I
should do it.
----------------------------------------------------------------------
JD · 2013-05-03 13:21
Quote from: ChrisF on May 03, 2013, 02:15:16 pm-you shouldn't have to
put all the files into one single directory. It's just because the
indylaz.lpk script is not correctly defined to access to the concerned
sub-directories. A minor change can fix it,
It is true that the IndyLaz.lpk script needs work. I preferred to let
the author do it since the changes will then be included in subsequent
releases.
Quote from: ChrisF on May 03, 2013, 02:15:16 pm-you have to compile
the package twice, mostly of the time. Because of an issue into the
FPC compiler: see bug reports
http://bugs.freepascal.org/view.php?id=19673 and
http://bugs.freepascal.org/view.php?id=24121 . Well, in fact only one
file is recompiled the second time,
I haven't noticed this. I only compiled once.
Quote from: ChrisF on May 03, 2013, 02:15:16 pm-icons inside the IDE
are outdated. They are corresponding to the old 16 colors ones, though
the 256 colors version is available (furthermore a few ones are
missing); because the .lrs files have not been updated. See attached
capture for a sample with the 256 colors version.
You're right about the outdated icons. I was hoping this would be
fixed for future releases. The newly released Indy 10.6 (I'm yet to
test it) and above all Indy 11.
Quote from: ChrisF on May 03, 2013, 02:15:16 pmI've planned to propose
my fixes for the FPC installation; I guess I should do it.
Please feel free to update the Wiki if you can.
JD
----------------------------------------------------------------------
ChrisF · 2013-05-03 13:47
@JD
------
Well, you've most probably not noticed that one .pas file has been
compiled twice during your installation process.
If you put all the needed files into one single directory, it works
without any problem.
But if you use sub-directories (with a modified package script to
allow them), you step into a compilation error. Because the second
time, the compiler can't find the correct path. I don't remember all
of the details, but I'm sure about this issue.
The only solution is to manually ask for a second compilation for the
package: this time, only the concerned file is recompiled (in fact,
only the checksum inside the .PPU file is updated), and there is no
path issue.
The other solution being of course to manually put all the needed
files into one single directory, as you've probably done. This way,
the second time the compiler doesn't have any problem to find the
needed directory as there is only one. And so, it can be all done in
"one" compilation step only during the installation process.
In fact, when I was referring to fixes, I intended to mean fixes
within the fulgan distribution. I've posted today a proposal for such
fixes into the Indy forum. Depending of the answer of the coder(s), I
may update then the Lazarus wiki.
----------------------------------------------------------------------
JD · 2013-05-03 14:00
Quote from: ChrisF on May 03, 2013, 03:47:55 pmIn fact, when I was
referring to fixes, I intended to mean fixes within the fulgan
distribution. I've posted today a proposal for such fixes into the
Indy forum. Depending of the answer of the coder(s), I may update then
the Lazarus wiki.
Have no fears on this one. Remy Lebeau (the package maintainer) is a
very helpful person. I've nothing but praise for him for his
assistance and availability where using Indy is concerned.
----------------------------------------------------------------------
ChrisF · 2013-05-03 20:04
(Continuation of another topic, concerning fixes for the indy
installation)
If I've not proposed my patches for the Indy installation here before,
it's because I intended to propose them for the "official" fulgan
releases. But as I've postponed to make my proposal a couple of times
in the past and so, as it's still not done, here are them; at least
for test purposes. Hopefully, they'll be included into the future indy
releases, and/or similar fixes will be provided.
Basically, the changes concerns the package script (in order to use
the provided sub-directories during the installation process), and the
resource files (in order to get the 256 colors icons inside the
Lazarus IDE).
Once you've downloaded the indy fulgan version (currently, version
Indy10_5004) and unzipped it, here are the steps for the installation
(anyhow, most of them are common to any lazarus package installation):
Preliminary note: As you may have already noticed, only the \Lib
subdirectory of Indy is needed for the installation. In fact only
\Lib\Core, Lib\System\ and \Lib\Protocols, and not all the files; but
that's another matter...
1/ Copy the "\Lib" subdirectory in its final place : for instance in
an "indy" directory created inside the "components" subdirectory of
Lazarus (i.e. $(LazarusDir)components\indy ).
2/ Replace the "indylaz.lpk" file present into the \Lib subdirectory
with the one provided with this post (i.e. attached file "Indylaz (for
Indy10_5004).zip"). This script has been prepared for the 5004
release, but anyhow the only difference for all of the releases is an
indication of the release version inside the script. You can modify it
by yourself, or leave it as this. In this later case, the display for
the package inside Lazarus will be incorrect; that's all (there is no
other difference).
3/ Replace the resources files present into the concerned
subdirectories of "\Lib" with the ones provided here, as follows:
- "IdRegisterCore.lrs" into "\Lib\Core"
- "IdRegister.lrs" into "\Lib\Protocols"
4/ Start Lazarus and open the lazarus package (as in my previous
sample, "$(LazarusDir)components\indy\indylaz.lpk").
5/ Compile it. Compile it one more time (yes, twice !).
6/ Mark it for installation.
7/ Finally, recompile the Lazarus IDE (optimized version being most
preferable). You should now see the new indy icons at the end of the
palette toolbar.
Final note: 2 compilations are needed because of an FPC compiler
issue, and because subdirectories are used in the package script. The
second compilation is done automatically during the recompilation of
the Lazarus IDE internally, when only one directory is used with all
the needed files (but you have to manually transfer them in this
case).
If you look at the messages into the message box after the second
compilation that I've indicated (look at all messages, included those
hidden), you'll see that one file has been recompiled indeed:
...
Compiling indylaz.pas
Compiling .\System\IdStreamVCL.pas
...
In case of any problem, question, observation,... please feel free to
post them in response.
----------------------------------------------------------------------
JD · 2013-05-03 20:10
Quote from: ChrisF on May 03, 2013, 10:04:04 pm..
Compiling indylaz.pas
Compiling .\System\IdStreamVCL.pas
...
Hmmm, I do remember that IdStreamVCL.pas was a difficult problem. The
compiler was saying something about not being able to find it. I had
to add the directory to the package's Unit path before it worked.
----------------------------------------------------------------------
ChrisF · 2013-05-03 20:42
Yep. It's because the problem doesn't occur during the package
compilation step itself, but when finally building the Lazarus IDE
instead (i.e. lazarus.exe).
Basically:
1/ Indy package compilation step : OK. In fact, "something" is wrong,
but it 's not noticeable at this step
2/ Lazarus IDE final building: all the compiled units are checked.
Those concerning the Indy installation of course, but also all the
main ones concerning the IDE itself and all the other packages.
During this check, something is detected as being not updated (an
incorrect CRC inside one of the PPU files of the Indy package). So,
the process decides to recompile the "offending" file. But the Indy
package script is no more present at this step (it concerns only the
Indy package compilation, certainly not the IDE compilation), and so
an error occurred, as the compiler can't now find the correct Indy
subdirectory.
So, finally the main problem is that an incorrect PPU file is produced
during the Indy package compilation; due to "recursive" call units,
and to inline functions uses (this is well explained into the bug
report links I've provided in one of my former posts).
If the PPU file was correctly produced, the final IDE building step
wouldn't require such an "extra" compilation for one of the Indy
files, and everything would be fine !
**EDIT ** : This is why a second compilation is needed here. It just
updates the wrong PPU Indy file and so, the Lazarus IDE building can
be achieved without any error.
----------------------------------------------------------------------
JD · 2013-05-03 20:59
It worked just as you described. Great job. But you might want to look
at those *.lrs files you posted because the IDE icons are still the
old ugly 16 bit icons.
By the way, I stand corrected. Indy10.5004 is the new Indy10.6 series
That's great since Lazarus/FPC is not being left behind by Delphi
where Indy's evolution is concerned.
We must update that Wiki.
----------------------------------------------------------------------
ChrisF · 2013-05-03 21:22
Concerning the trouble with the icons, it's a bit strange. I've just
made a new Indy re-installation with the current version Indy10.5004
(aka Indy 10.6, you are right), using the resource files I've just
posted before and everything is correct for me (see attached screen
capture).
Are you sure that you've replaced the 2 concerned files, before the
compilation ? In the right sub-directories ? Have you really completed
a new Lazarus recompilation, then ?
In order to check by yourself:
Code: [Select]Old (16 colors) resource files : 10/08/2012
IdRegisterCore.lrs : 51 Kb
IdRegister.lrs : 230 Kb
New (256 colors) resource files : 23/03/2013
IdRegisterCore.lrs : 59 Kb
IdRegister.lrs : 314 Kb
----------------------------------------------------------------------
JD · 2013-05-03 22:03
Yes I followed the instructions to the letter. I don't know why it is
so.
Can you repost the 3 files but from your actual Indy installation?
----------------------------------------------------------------------
ChrisF · 2013-05-04 12:01
OK. Here are EXACTLY the concerned files I've taken from my own Indy
directory, used within Lazarus. But, as you can see by yourself, they
are exactly the same as the former ones.
It's possible that there is something wrong with your last indy
installations/de-installations.
I suggest you to de-install completely your current indy version, and
to re-install it then, with the modified files:
-de-install your current indy package inside Lazarus,
-recompile the Lazarus IDE (optimize version for speed purposes). The
indy icons should now be absent,
-delete you current indy directory and subdirectories, formerly used
within Lazarus,
-recreate it, and process with the indy installation described in my
former post (don't forget to update first the 3 provided files, of
course).
----------------------------------------------------------------------
JD · 2013-05-04 16:05
No change at all. I've done it 3 times and the result is the same.
Dunno. Maybe it has something to do with Windows versions because I'm
using the unreliable Vista.
----------------------------------------------------------------------
ChrisF · 2013-05-04 18:07
Well, even Vista is not "smart" enough to recreate the old resource
files, if you've deleted them or replace them with the new ones.
So, I can see only 2 possible explanations:
-the Indy package compilation is still done with the old resource
files: because of wrong files, wrong places, wrong paths, wrong
i-just-dont-know... Wrong installation path seems to me the more
probable one in this case; especially if you've still got some other
old Indy directories somewhere else on your disk. Have you tried to
search for all the "IdRegister.lrs" files present on your disk, for
instance ? Which date and which size for them ?
-there is a problem during your compilation, and so you are still
using the old Lazarus.exe file (an UAC problem, for instance ?). You
can check the date of this file to be sure about that. BTW, are you
using several versions of Lazarus ? For win32 and win64, for instance
? Or for cross-compilations ? That could be also another possible
reason.
Have you also really seen that all the Indy icons were absent after
having de-installed your old Indy version ? This could also be an
indication, if it wasn't the case.
For an additional check, you may have a look at a specific Indy icon.
Because some them are missing or incorrectly named into the 16 colors
version of the resource files. In this case, a by-default icon is used
for the corresponding component. While there is really a Indy icon in
the 256 colors version ones.
Look at the "Indy - Clients Core" tab, for instance, for the last
component (i.e. "TIdTraceRoute"). With the 16 color version, this icon
is missing; so, a 256 colors by-default icon is provided by Lazarus
(see capture "Check-Palette16.png"). While this icon is really present
with my 256 colors resource files (see capture "Check-
Palette256.png").
Plus the fact that the other ones are 256 colors ones, of course...
----------------------------------------------------------------------
marcov · 2013-05-04 19:42
Quote from: JD on May 03, 2013, 10:10:02 pm
Hmmm, I do remember that IdStreamVCL.pas was a difficult problem. The
compiler was saying something about not being able to find it. I had
to add the directory to the package's Unit path before it worked.
Afaik removing duplicate include files helps too.
----------------------------------------------------------------------
JD · 2013-05-06 13:59
Quote from: marcov on May 04, 2013, 09:42:29 pmQuote from: JD on May
03, 2013, 10:10:02 pm
Hmmm, I do remember that IdStreamVCL.pas was a difficult problem. The
compiler was saying something about not being able to find it. I had
to add the directory to the package's Unit path before it worked.
Afaik removing duplicate include files helps too.
It worked! Finally! Thanks for reminding me of the duplicate files,
marcov. I used my tried and tested system i.e copy all necessary files
(*.pas, *.lrs, *.inc) from the \Lib\Core, \Lib\Protocols, \Lib\System
directories into a directory of my choice taking care not to duplicate
already existing files. I then copied the modified IdRegisterCore.lrs
and IdRegister.lrs (but not the modified IndyLaz.lpk) created by
ChrisF into the directory I created. I then compiled the package
twice, rebuilt the Lazarus IDE & I now have the Indy icons in 256
colors. Where there's a will, there's always a way.
Thanks marcov and ChrisF.
JD
----------------------------------------------------------------------
MISV · 2015-05-23 20:56
Could anyone of you maybe eigh in on the issue I have encountered with
Indy and OSX here:
http://forum.lazarus.freepascal.org/index.php/topic,28476.0.html
My setup works on Windows/Lazarus (1.4) but on OSX I have problems.
I have compiled and installed the indylaz with "-Ur"
When compiling a package that requires indylaz + has a unit from it in
"uses" clause I get error
QuoteCan not find "idFTP used by "UmisvMyPackage", incompatible ppu =
/Users/%myname%/MISV/LazarusComponents/indy_lazarus/Lib/lib/i386-
darwin/idFTP.ppu, package indylaz -- You tried to use a unit of which
the PPU file isn't found by the compiler. Check your configuration
file for the unit paths
If I try compile a new fresh app where I e.g. drop TidFTP and ass
idFTP unit to uses clause I get
QuoteCan not find "idFTP used by "UmisvMyApplication", Make sure all
ppu files of a package are in its output directory = /Users/%myname%/M
ISV/LazarusComponents/indy_lazarus/Lib/lib/i386-darwin/idFTP.ppu,
package indylaz -- You tried to use a unit of which the PPU file isn't
found by the compiler. Check your configuration file for the unit
paths
----------------------------------------------------------------------
marcov · 2015-05-23 21:35
MISV:
I notice something I didn't notice before; "Incompatible PPU" means
different version or architecture.
So somehow either the fpc compiler that is being executed is not what
you think AND/OR the ppu's don't match it.
Earlier I thought it was some minor gotcha that forced recompile but
then the message is "Interface CRC not matching, recompiling' or
something similar.
----------------------------------------------------------------------
MISV · 2015-05-24 09:30
Hi Marcow,
I appreciate all the help you try give me.
I have tried to delete all .ppu files in the indylaz
Lib/lib/i386-darwin/ folder before compiling something that
requires/uses the package - i.e. a dependent package (the error
message about incompatible) or application (where the error is
slightly different)
If I e.g. compile a free new application in Lazarus/OSX, it runs in
OSX. But if I add idFTP component to it, it fails. (So I think that
means FPC/Lazarus/Sources compiler are correct?)
However, maybe there are source files from elsewhere? It is correct I
moved my Indy Lazarus/Windows installing to OSX when I started the
work on porting, but since I have tried removing all the PPU files
then I am not sure what there if left to try? Could there be some
option in a apckage file that survived the move from LAzarus/Windows
to Lazarus/OSX?
----------------------------------------------------------------------
ChrisF · 2015-05-24 12:25
It may sound obvious (i.e. you've probably already verify it), but:
- have you looked at the messages output when compiling Indy before
installing it? Especially the concerned unit i.e. IdFtp ? Is it
compiled correctly ? Without any error or warning ?
- have you looked at the IdFtp.ppu file in the concerned Indy
subdirectory ? Is it present and with the same date/time that the
other ppu files ?
- do you have any other idFtp.ppu file somewhere else ? In your
package ? Or in any path of your package ? Anywhere else ?
Have you installed any other package than Indy (and your package) ?
It's not clear to me if you've done this test: testing IdFtp, but
without your own package. I mean, a fresh FPC/lazarus installation +
the Indy package only ?
What version of Indy are you using ? A recent one, from
http://indy.fulgan.com ?
Is any other component of Indy working properly ? An idHttp component,
for instance, within a simple test project ?
And finally: do you remember what kind of files you have transferred
EXACTLY from Windows to OSX for your package ?
I guess one of them could be a problem (not necessarily a .ppu file).
Theoretically, the whole ...Lib/lib/i386-win32 (or x86_64-win64)
subdirectory should have be omitted during the copy.
It's also possible that there are some differences from "standard"
Windows package files and "standard" OSX ones - i.e. options
added/removed or different by default (sorry, I can't tell for this
part).
Edit:
I'm not sure bout what you mean with "I have tried to delete all .ppu
files in the indylaz Lib/lib/i386-darwin/ folder before compiling
something that requires/uses the package".
What is it just to check something (I mean the compilation can't
succeed any longer, anyway) ?
To see if there is a different error message ?
Why not having just delete the IdFtp.ppu file to check the error
message, in this case ?
Edit2:
Would it be possible that you have any other idftp.ppu file with a
different case orthography (i.e. case sensitive problem - I don't know
how your system is configured) ? Or that your package use a different
case orthography for this unit ?
See: http://wiki.freepascal.org/User_Changes_2.4.0#Case_sensitivity_fo
r_unit_names
Quote...
New behaviour: All file systems are now treated as case-sensitive by
default. The result is that the compiler will no longer always find
units whose filename does not exactly match the unit name as it
appears in the uses clause, even if the unit is located on a case-
insensitive file system.
...
----------------------------------------------------------------------
MISV · 2015-05-24 15:18
His Chris,
I can answer all of your questions / to-list items. I have tried them
all
- I just use "idFTP as an example - it is whatever indy unit that is
first placed in uses section. (So nothing from Indy compiles when used
from anywhere.)
- I do not have any win32 folder in my OSX indy installation (only
darwin)
- I have tried searching system for duplicate ppu file.
- I tried delete all ppu files to make sure they were all built /
generated "fresh" again
- I am using an Indy version a couple of months old. (I only installed
two other packages - lclextensions and virtualtreeview, none of which
interact with Indy AFAIK)
- I have manually inspected the lpk file to see if anything appears
wrong, but it does not appear so. (If anyone has a working Indy
installation on OSX - do please upload it so I can compare?)
- I have tried checking case sensitivty. The .pas, .ppu file,
compilter output error/log all use the same case.
----------------------------------------------------------------------
ChrisF · 2015-05-24 17:24
So, if I'm correctly understanding you, you can compile correctly and
install the Indy package (BTW, do you see its icons in your IDE ?),
but you can't use it in any way.
In this case, could you check your indylaz.lpk file on OSX. Be sure to
have this option:
Code: [Select]
and especially not this one (at least one release of Indy has been
done with an incorrect package file):
Code: [Select]
----------------------------------------------------------------------
MISV · 2015-05-24 21:48
Correct. Yes, I see icons, but I can't compile anything that uses it.
Everything looks correct to me, but I have attached the indylaz.lpk
file here.
----------------------------------------------------------------------
ChrisF · 2015-05-25 03:17
I can't see anything obvious in your package file, though there is one
or two things a bit "strange".
Have you called it "indylaz.txt" instead of "indylaz.lpk" for a good
reason (may be to upload it) ? Are you sure that it is this file which
is used during your package installation, and not an "old" .lpk file
still present ?
Apparently, the version is not the latest one, though it's still a
recent one, indeed. What I find a bit strange is that I've never seen
a recent Indy file build this way: may be because you've changed some
options in your IDE for this package and re-saved it ?
What I find strange, for instance, is that you have only 13 files
count in your package file: in the past it was 15, and since a while
it's 14 AFAIK: IdDsnCoreResourceStrings.pas is missing. Why ? And I've
got 14 both for my Indy 10.6.0 (build 5141) and 10.6.2 (build 5273),
while yours is 10.6.1 (build 5238): just between the two of them.
So, where did you get your whole Indy package, exactly ?
Just to be sure, have you checked inside your IDE that your package
has really been installed as "RunAndDesign" in its option: see
attached capture for my own version.
Sorry, I can't see any other "good" reason explaining your problem. As
a last chance, you can eventually make a try with the current version
of Indy, i.e:
- uninstall your current Indy package, then remove all the Indy files
currently present (sources, binary, config...) into your Indy package
subdirectory,
- download the latest version from http://indy.fulgan.com/ (in ZIP
directory - currently "Indy10_5274.zip");
- install it without any modification (you still need to compile it
twice before rebuilding your IDE for it's final installation step).
BTW, have you also made a try with a simple test project by adding the
absolute path of your Indy binaries into the search path of this
project (-Fu compiler option):
Project - > Project Options - > Compiler options - > Paths - > Other
unit files
----------------------------------------------------------------------
MISV · 2015-05-25 10:54
I renamed it .txt, so it could be uploaded.
If anyone has a working lpk file on OSX - please upload it.
Yes, design and runtime
I originally changed file paths in my lpk because I wanted the paths
to match. So I did not have those red cross over the filenames like in
your screenshot. I believe this was necessary for the fulgan package
to install, but I can not remember the specifics any longer.
I will try a reinstall, but my hopes are pretty low.
I have tried pointing "other files" to the ppu directory of Indy -
does not work either
----------------------------------------------------------------------
MISV · 2015-05-25 11:57
Same problem with a fresh untouched Indy installation. (I even
deleted the old Indy directory and installed the new one in a complete
new directory to make sure there were no leftover references)
Anyone here got Indy working on OSX / Lazarus 1.4?
----------------------------------------------------------------------
ChrisF · 2015-05-25 17:04
I'm afraid there is an issue relative to the OSX environment: sorry...
Eventually, you can try to make a test directly with the Free Pascal
compiler (i.e. not using Lazarus); with only a sample program and
calling directly fpc.
A sample program: test.pas
Code: [Select]program test;
uses
IdFTP;
var MyFTP: TIdFTP;
begin
MyFTP := TIdFTP.Create(nil);
MyFTP.UserName := 'anonymous';
MyFTP.Free;
WriteLn('Done');
end.
Compilation call for Windows, to adapt according to the proper
configuration : comp.bat
Code: [Select]dir
C:\lazarus\components\indy\Lib\lib\i386-win32\IdFTP.*
C:\lazarus\fpc\2.6.4\bin\i386-win32\fpc
-FuC:\lazarus\components\indy\Lib\lib\i386-win32\ test.pas
I'm not familiar with Mac OSX, but I guess it should be (more or less)
equivalent to the following commands: to run into the OSX terminal
Code: [Select]ls -l /path_for_Indy_binaries/IdFTP.*
/path_for_fpc_binaries/fpc -Fu/path_for_Indy_binaries/ test.pas
The aim of the dir/ls commands is to verify that the proper path and
the proper filenames are correct for the Indy binary files (and
eventually the corresponding permissions, too). It could be
interesting to know if you really can "see" them, while fpc can't.
*** Edit ***
I just noticed that the Ftp unit for my Windows version of Indy are
called IdFTP.* (as for in the zip file of Indy), while you are always
referring to idFTP.* everywhere (especially in your error messages).
Of course Windows doesn't care, but it could be the case for OSX:
strange...
If it's really the case, you'll have to modify the test program and
commands: IdFTP -> idFTP.
----------------------------------------------------------------------
balazsszekely · 2015-05-26 05:35
@MISV
My configuration:
- OSX 10.8.5(Mountain Lion)
- Indy 10.6.2.5274(the latest from http://indy.fulgan.com -
downloaded on 25.05.2015)
- Lazarus 1.5 SVN version(r49172 - 26.05.2015)
*I can run a few tests on OSX 10.10(Yosemite) if is necessary, but I
prefer not to, because I have a few project under development(Lazarus
1.2.6)
I have no problem compiling/installing Indy, then building/running
applications.
1. Remove all previous indy installation
2. Download the following package(10.6.2.5274) from:
http://www.2shared.com/file/eCHHk96r/Indy_1062.html
3. Extract the zip to $(LazarusDir)/Components/ directory
4. Open the package file, compile twice
5. Install Indy
6. Create a new project, add a few indy components(IdFTP for example)
then go to Project/Options, add indy directory to Search Paths(http://
i1269.photobucket.com/albums/jj581/balazsszekely/Indy%2010_1_zpsq0ydkw
xb.png)
7. Build then Run (http://i1269.photobucket.com/albums/jj581/balazssze
kely/Indy%2010_2_zpszknc3fwb.png)
----------------------------------------------------------------------
JD · 2015-05-26 07:47
Quote from: GetMem on May 26, 2015, 07:35:27 am6. Create a new
project, add a few indy components(IdFTP for example) then go to
Project/Options, add indy directory to Search Paths(http://i1269.photo
bucket.com/albums/jj581/balazsszekely/Indy%2010_1_zpsq0ydkwxb.png)
7. Build then Run (http://i1269.photobucket.com/albums/jj581/balazssze
kely/Indy%2010_2_zpszknc3fwb.png)
Did you make the Indy About form yourself. It looks great!
Seeing your screenshots gives me assurance that Indy10 works in a Mac
environment. I use it in Windows & Linux but the Mac was the final
frontier for me. I can now say my Indy 10 apps work on all PC
platforms.
JD
----------------------------------------------------------------------
balazsszekely · 2015-05-26 08:05
Quote@JD
Did you make the Indy About form yourself. It looks great!No! It's the
original Indy About form since 2014. Install the latest indy, drop a
component to your form, right click-->About Internet Direct(Indy).
----------------------------------------------------------------------
JD · 2015-05-26 09:17
Quote from: GetMem on May 26, 2015, 10:05:37 amQuote@JD
Did you make the Indy About form yourself. It looks great!No! It's the
original Indy About form since 2014. Install the latest indy, drop a
component to your form, right click-->About Internet Direct(Indy).
OK I see it now. I didn't know that. Thanks for the info.
By the way, have you been able to build Indy apps on the Mac? I don't
have a Mac so I cannot test my apps.
JD
----------------------------------------------------------------------
balazsszekely · 2015-05-26 09:32
QuoteOK I see it now. I didn't know that. Thanks for the info.You're
welcome!
QuoteBy the way, have you been able to build Indy apps on the Mac?
Yes! I created a client/server application(TIdTCPClient/TIdTCPServer).
Actually it's not finished yet, but it's working fine on mac.
QuoteI don't have a Mac so I cannot test my apps.If it's not a secret,
feel free to post the source code. I can run a few tests for you.
*secret => I mean closed source
----------------------------------------------------------------------
JD · 2015-05-26 11:12
Quote from: GetMem on May 26, 2015, 11:32:55 amQuoteI don't have a Mac
so I cannot test my apps.If it's not a secret, feel free to post the
source code. I can run a few tests for you.
*secret => I mean closed source
It actually is because I was commissioned to develop the application
by an NGO.
A non-trivial example you can test for me can be found here
http://www.delphigeist.com/2010/09/custom-client-server-application-
with.html I made a few twists & turns before I got it to work on Linux
some years back. I'd like to know how it runs on a Mac.
Thanks,
JD
----------------------------------------------------------------------
balazsszekely · 2015-05-26 12:10
Quote@JD
A non-trivial example you can test for me can be found here
http://www.delphigeist.com/2010/09/custom-client-server-application-
with.html I made a few twists & turns before I got it to work on Linux
some years back. I'd like to know how it runs on a Mac.It was written
with an old version of Indy 10. Actually this is not a problem, I can
easily convert it to Indy 10.6.2, but it contains a lot of
delphi/windows specific stuff. I hope you don't aspect me to recode a
large part of the project, just for the sake of the demo.
----------------------------------------------------------------------
ChrisF · 2015-05-26 13:12
Quote from: GetMem on May 26, 2015, 07:35:27 am...
1. Remove all previous indy installation
2. Download the following package(10.6.2.5274) from:
http://www.2shared.com/file/eCHHk96r/Indy_1062.html
3. Extract the zip to $(LazarusDir)/Components/ directory
4. Open the package file, compile twice
5. Install Indy
6. Create a new project, add a few indy components(IdFTP for example)
then go to Project/Options, add indy directory to Search Paths(http://
i1269.photobucket.com/albums/jj581/balazsszekely/Indy%2010_1_zpsq0ydkw
xb.png)
7. Build then Run (http://i1269.photobucket.com/albums/jj581/balazssze
kely/Indy%2010_2_zpszknc3fwb.png)
Just for my own information (as I don't have any access to a Mac
neither)...
1/ You are adding the Indy binaries path to your project (step 7). Is
it really necessary ? Is it a specific need for the OSX ? Is it also
the case if you add manually (i.e. when not using a "visual" Indy
component) the Indy package into the required package list ?
I mean, theoretically when using a "visual" component, indylaz is
added automatically in the required package list, and the path to the
Indy binaries are also added automatically when the compilation is
done.
And for the other case, adding the Indy package into the required
package list should be sufficient (this is the way to provide
compatibility between various installations for a package; the exact
location of the package binaries may be different from a user/computer
to another).
Is all this mechanism not working properly for OSX ?
2/ I see you've chosen the "all in one directory" option for
installing Indy. Is it just because you are used to do it (I know it
was necessary in the past, unless modifying the lazarus package file)
? Or is it because the "subdirectory" option is not working when
installing Indy on OSX ?
I mean, the Lazarus package file released currently with Indy is
supposed to now work properly with subdirectories; at least, it's the
case with Windows.
Is it not working with OSX ?
----------------------------------------------------------------------
JD · 2015-05-26 14:26
Quote from: GetMem on May 26, 2015, 02:10:29 pmQuote@JD
A non-trivial example you can test for me can be found here
http://www.delphigeist.com/2010/09/custom-client-server-application-
with.html I made a few twists & turns before I got it to work on Linux
some years back. I'd like to know how it runs on a Mac.It was written
with an old version of Indy 10. Actually this is not a problem, I can
easily convert it to Indy 10.6.2, but it contains a lot of
delphi/windows specific stuff. I hope you don't aspect me to recode a
large part of the project, just for the sake of the demo.
I'll recreate the cross platform (Win/Linux) version I made some years
ago & I'll post it here in a few days time so that you can add any Mac
specific code that is needed. What do you think?
----------------------------------------------------------------------
MISV · 2015-05-26 14:40
It seems the combination of upgrading both to the latest Indy version
+ fixing my case in source seems to help to some degree. (I had some
errors with units names.)
...
Now I have the compiler past the point where I had problems earlier.
before I would *always* get problems when compiling my test
application that required both indylaz and my own package (that also
required and used indy .... typically in a unit found here I would
encounter the problem --- but received a different error when
compiling/installing the package)
...
Instead I am now getting errors inside the Indy units (when compiling
indylaz) that it can't find the other Indy units, but it is a major
step forward!to compile)
Update:
One example: IdHTTP ... it tries to use unit "IdHTTPHeaderInfo"...
This gives an error... I think it is differences in: Unit name on
disk, Unit name in file, unit name in use clause, but I have
researched this to the end yet.
----------------------------------------------------------------------
JD · 2015-05-26 15:42
Quote from: MISV on May 26, 2015, 04:40:24 pmIt seems the combination
of upgrading both to the latest Indy version + fixing my case in
source seems to help to some degree. (I had some errors with units
names.)
@MISV I decided to look into the problems you are having. I
uninstalled my old Indy I0 installation in Linux Mint. I downloaded
the latest version for 26 May 2015 & I just selected indylaz.lpk,
compiling it twice & installed it in the Lazarus 1.2.6 IDE. I then ran
my usual tests after installation & it works fine. I did the same
thing in Windows last week so I know it works.
Your problems may go away if you do a fresh installation of Indy
----------------------------------------------------------------------
balazsszekely · 2015-05-26 16:26
Quote@ChrisF
I see you've chosen the "all in one directory" option for installing
Indy. Is it just because you are used to do it (I know it was
necessary in the past, unless modifying the lazarus package file) ? Or
is it because the "subdirectory" option is not working when installing
Indy on OSX ?Partly because I'm use to it, but most importantly, those
seven steps described in my previous post always works, on every
platform.
Quote@ChrisF
I mean, the Lazarus package file released currently with Indy is
supposed to now work properly with subdirectories; at least, it's the
case with Windows.I will test it tomorrow under OSX with
subdirectories and report back. According to @MISV it's not working
properly.
Quote@JD
I'll recreate the cross platform (Win/Linux) version I made some years
ago & I'll post it here in a few days time so that you can add any Mac
specific code that is needed. What do you think?Ok. Usually if it
works both under windows and linux, with little or no modification
will work on mac too.
Quote@MISV
It seems the combination of upgrading both to the latest Indy version
+ fixing my case in source seems to help to some degree. (I had some
errors with units names.)Did you try my "all in one directory"
package?
----------------------------------------------------------------------
ChrisF · 2015-05-26 18:24
@GetMem:
Yes it's interesting, because depending of your tests and experience
with Indy on OSX, it could be useful to modify the wiki page
concerning Indy (OSX section).
@GetMem and MISV:
If I've correctly understand what I've read, it's possible to indicate
when created if the partition for the FS on OSX have to be case
sensitive or not. May be your configurations for this point are not
identical : i.e. case sensitive for MISV and not for GetMem (it's just
an hypothesis).
----------------------------------------------------------------------
JD · 2015-05-26 20:43
@MISV Sorry if I sound Like a broken record but have you tried to
follow GetMem's step-by-step instructions?
----------------------------------------------------------------------
MISV · 2015-05-26 22:58
Hi,
My best guess right now is that OSX is case sensitive and that both me
(in my own code) and Indy itself sometimes have mismatch between
- filename on disk
- actual unit name (i.e. "Unit xyz")
- how it is referenced in other units in "Uses"
Above problem also manifests itself in different error messages
depending on if I am compiling an application using indylaz or my own
package that uses indy.
I also think the error message is sometimes wrong. i.e. one part of
Lazarus logs/shows one unit name, but it is actual another case
version it can not find. I.e. it may be trying to find "XXX" but show
it can not find "xxx". I think that was partly why I was spending time
on wild goose chases where I could not see what was wrong.
I have found someone else having eperienced something very similar:
http://atozedsoftware.newsgroups.archived.at/indy.general/201005/10053
16656.html
It may also be that my earler version of the Indy library had some
configuration errors (having originally copied it from Windows) - at
least problems manifiested themselves different.
Somehow this may also be an error 40 (i.e. 40 centimeters from screen)
but I spent days trying out many different variations.
I will return at quickest possible time frame when I can somehow
organize my findings into something sensible / reproducable. I am
working actively on this.
----------------------------------------------------------------------
balazsszekely · 2015-05-27 05:34
@ChrisF
I was able to Compile/Install the "subdirectory" version of Indy
10.6.2 under OSX. If I drop a component(TIdFTP for example) to Form1,
indylaz is added to Required Packages, the project is building/running
fine. However in my projects I use TIdSync a lot for updating visual
components from inside threads. TIdSync is located in /Core
subdirectory. If I add IdSync to the uses clauses, the project fails
to build(see attachment). Actually this can be reproduced under
windows and linux too. The same behaviour it's not present when the
"all in one directory" version is used. That's why I prefer latter
one. The necessary files can be copied in less then a minute to a
single directory.
PS: If it helps, my OSX is NOT case sensitive.
----------------------------------------------------------------------
JD · 2015-05-27 08:25
Quote from: GetMem on May 27, 2015, 07:34:56 am@ChrisF
I was able to Compile/Install the "subdirectory" version of Indy
10.6.2 under OSX. If I drop a component(TIdFTP for example) to Form1,
indylaz is added to Required Packages, the project is building/running
fine. However in my projects I use TIdSync a lot for updating visual
components from inside threads. TIdSync is located in /Core
subdirectory. If I add IdSync to the uses clauses, the project fails
to build(see attachment). Actually this can be reproduced under
windows and linux too. The same behaviour it's not present when the
"all in one directory" version is used. That's why I prefer latter
one. The necessary files can be copied in less then a minute to a
single directory.
PS: If it helps, my OSX is NOT case sensitive.
I use IdSync/IdNotify a lot also because my apps are multithreaded. I
got round it by adding IdSync.pas to the IndyLaz package &
recompiling. See screenshot. So the subdirectory version still works.
JD
----------------------------------------------------------------------
balazsszekely · 2015-05-27 08:52
After I add IdSync to IndyLaz package the same problem exists with
IdTask. Who knows how many unit I need to add until I'm able to
compile the project? For now I'm gonna stay with "all in one
directory" version. I guess it's just a personal preference.
----------------------------------------------------------------------
JD · 2015-05-27 09:07
Quote from: GetMem on May 27, 2015, 10:52:04 amAfter I add IdSync to
IndyLaz package the same problem exists with IdTask. Who knows how
many unit I need to add until I'm able to compile the project? For now
I'm gonna stay with "all in one directory" version. I guess it's just
a personal preference.
I actually wrote the "all in one directory" instructions so I have
nothing against it. Can you please test the attached sample project on
your Mac system? I did it in Linux & it did not ask me to add IdTask
even though IdTask is in the uses clause. All this is just so that we
can have coherent installation instructions on the platforms Lazarus
supports.
----------------------------------------------------------------------
balazsszekely · 2015-05-27 09:43
Your test project is working fine under OSX, but I'm still unable to
build my project unless I add IdTask to Indylaz package.
----------------------------------------------------------------------
JD · 2015-05-27 10:51
Quote from: GetMem on May 27, 2015, 11:43:54 amYour test project is
working fine under OSX, but I'm still unable to build my project
unless I add IdTask to Indylaz package.
Now that is very interesting. Thanks for testing it. If you look at
the uses clause of the test project, IdTask is there. Can you try
adding ALL the Indy units in your project to the test project and then
try to recompile it? I want to know if there is a missing dependency
somewhere.
Thanks,
JD
----------------------------------------------------------------------
Cyrax · 2015-05-27 14:05
You might check my version of Lazarus Indy package. You find it
attached in this post.
----------------------------------------------------------------------
ChrisF · 2015-05-27 15:37
Quote from: GetMem on May 27, 2015, 07:34:56 am@ChrisF
I was able to Compile/Install the "subdirectory" version of Indy
10.6.2 under OSX. If I drop a component(TIdFTP for example) to Form1,
indylaz is added to Required Packages, the project is building/running
fine. However in my projects I use TIdSync a lot for updating visual
components from inside threads. TIdSync is located in /Core
subdirectory. If I add IdSync to the uses clauses, the project fails
to build(see attachment). Actually this can be reproduced under
windows and linux too. The same behaviour it's not present when the
"all in one directory" version is used. That's why I prefer latter
one. The necessary files can be copied in less then a minute to a
single directory.
PS: If it helps, my OSX is NOT case sensitive.
Thanks for the test.
So apparently, it's "generally" working but there are still a few
issues concerning the "subdirectories method".
Concerning the TIdSync unit, after verifying it's not surprising: the
TIdSync.ppu file is absent (though TIdSync.dcu is present for the
Delphi version, indeed). As indicated by JD, we could modify the
lazarus package file to add a dependency (i.e. forcing the compilation
of this unit during the installation process).
I've just made a quick check between the Free Pascal and Delphi
binaries, for comparison purposes. There are a few other missing
files, but TIdSync seems to be the more important -missing- one (and
I'm not sure all the other ones are really necessary for Free Pascal).
As for JD, I'm a bit puzzled concerning the IdTask unit. This one is
compiled and present in the binary directory. There is probably
"something else" concerning this problem, and it could be interesting
to know which one.
A final word: you can of course use whatever method prefer to install
Indy (my goal was not to force anybody to use any particular method) ,
but I think it would be easier for other people to just use the
standard package released by default for Indy: so, fixing it (
especially the Lazarus package file) might help them (if we can
identify all the issues).
@Cyrax:
Looking briefly at your package file, the main difference I can see is
the "IncludeFiles" section. For what purposes ? Are there any other
important changes ?
----------------------------------------------------------------------
JD · 2015-05-27 15:48
Quote from: ChrisF on May 27, 2015, 05:37:35 pmAs for JD, I'm a bit
puzzled concerning the IdTask unit. This one is compiled and present
in the binary directory. There is probably "something else" concerning
this problem, and it could be interesting to know which one.
That sort of surprised me too because I did not have an issue with it
until GetMem said it caused problems in OSX. I would also like to know
why that is the case.
----------------------------------------------------------------------
Cyrax · 2015-05-27 17:47
Quote from: ChrisF on May 27, 2015, 05:37:35 pm...
@Cyrax:
Looking briefly at your package file, the main difference I can see is
the "IncludeFiles" section. For what purposes ? Are there any other
important changes ?
I don't remember exactly why I added it there. Probably it was to get
around compilation problems.
I have attached a SVN patch against original version of indylaz.lpk in
to this post so you and others can see what have changed.
----------------------------------------------------------------------
balazsszekely · 2015-05-27 18:44
@ChrisF, @JD
Sorry for the late response! Apparently I was wrong, after a clean
install + deleting all the files from my project's binary folder,
everything is working as it should. The only unit is missing from
Indylaz package is IdSync.
So who's gonna make the patch? It seems that Remy Lebeau is the only
one who is committing nowadays to
https://svn.atozed.com:444/svn/Indy10.
@JD If you want to test the project on Mac, send me a pm or post it
here.
----------------------------------------------------------------------
ChrisF · 2015-05-28 12:50
Yes, AFAIK only Remy Lebeau can do it.
But we can request a modification on the Azoted forum, in order he
applies it: http://forums2.atozed.com/
I've already done it several times in the past. The main problem is
that Remy Lebeau is usually very busy, and it can take time before the
patch being applied.
@MISV:
Have you solved your problems ? At least most of them... I'm asking
it, in case "case-sensitive OSX" would require some other patches.
----------------------------------------------------------------------
MISV · 2015-05-28 12:57
I believe I have found a bug (or at least something that could be
improved) in OSX/Lazarus that is not in Windows/Lazarus
Create a new application. Drop TIdHTTP and TIdFTP on the form.
Add "IdURi" to the usage claus (notice the case spelling)
If I do that, I will get an error that Lazarus in unit "IdHTTP" can
not find the referenced unit "IdURi"... even though the "use"
reference in "IdHTTP" unit is the correct "IdURI".
So in essence Lazarus spits out an error that is very confusing and
make you look the wrong place. The error (wrong case) was actually in
my own application unit. I think that was a contributing factor to my
problem.
...
I will return again as/if I find more similar problems. (I still have
not gotten my own code working, but I am trying work my way through.)