Error during install of fpc-3.2.2.i386-linux

[Steven Pietrobon]

I get the following error when I try to install fpc-3.2.2.i386-linux in Windows cygwin:

$ ./install.sh
This shell script will attempt to install the Free Pascal Compiler
version 3.2.2 with the items you select

./install.sh: eval: line 154: syntax error near unexpected token `('
./install.sh: eval: line 154: `set /usr/local/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32/wbem:/cygdrive/c/Program Files/Intel/iCLS Client:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/DAL:/cygdrive/c/Program Files/Intel/Intel(R) Management Engine Components/IPT:/cygdrive/c/Program Files/ATI Technologies/ATI.ACE/Core-Static:/cygdrive/c/Program Files/GnuPG:/cygdrive/c/Xilinx/bin/nt:/cygdrive/c/Program Files/gnuplot/bin:/cygdrive/d/Steven/Bin:/cygdrive/c/FPC/3.2.2/bin/i386-Win32:/cygdrive/c/altera/11.1sp2/modelsim_ase/win32aloem:/cygdrive/c/Program Files/GPAC:/cygdrive/d/Misc/Programs/mtn-200808a-win32:/usr/openwin/bin'
Install prefix (/usr or /usr/local)  [/usr/local] :

I think the problem might be the "(" symbol in my Windows path. Is there any way to fix this problem?

[dbannon]

Steven, that seems a very convoluted way to install FPC, is there not a native Windows 32bit package available ?

Then you would not need the cygwin approach at all.

Davo

[Zvoni]

What also doesn't make sense:
He's trying to install the 32-Bit Version for Linux (note the "i386")
From https://www.cygwin.com/

32 bit Cygwin

Address space is a very limiting factor for Cygwin. These days, a full 32 bit Cygwin distro is not feasible anymore, and will in all likelihood fail in random places due to an issue with the fork(2) system call.

Therefore we recommend using 32 bit Cygwin only in limited scenarios, with only a minimum of necessary packages installed, and only if there's no way to run 64 bit Cygwin instead.

You have been warned. If you're still sure you really need a 32 bit Cygwin, and there's absolutely no way around it, you may run the setup-x86.exe installer. The signature can be used to verify the validity of this binary.

There are still people using cygwin?
Use VirtualBox, install your preferred Linux-Distro, and be done with it

Or remove Windows all together, and move to Linux (which would be the sensible thing to do)

[rvk]

There are still people using cygwin?
Use VirtualBox, install your preferred Linux-Distro, and be done with it
Or remove Windows all together, and move to Linux (which would be the sensible thing to do)

Or use bash inside WSL2 on Windows.

(For FPC is works fine)

[marcov]

Can cygwin run linux binaries at all ?

Afaik it is an Unix-like environment to compile in, but that doesn't mean the binaries are compatible.

[MarkMLl]

Can cygwin run linux binaries at all ?

Afaik it is an Unix-like environment to compile in, but that doesn't mean the binaries are compatible.

Wasn't there something years (decades!) ago about Cygwin being needed for some of the toolchain stuff on Windows?

He might have been trying to work from a set of obsolete instructions, and trying to merge an up-to-date FPC version.

MarkMLl

[dsiders]

Can cygwin run linux binaries at all ?
Afaik it is an Unix-like environment to compile in, but that doesn't mean the binaries are compatible.

Wasn't there something years (decades!) ago about Cygwin being needed for some of the toolchain stuff on Windows?

He might have been trying to work from a set of obsolete instructions, and trying to merge an up-to-date FPC version.

MarkMLl

FPC currently supplies its own copy of coreutils. Version info says it was packaged by CygWin. So, I guess we all use CygWin. \_(oo)_/

And, no... cygwin cannot run linux executables.

[marcov]

Can cygwin run linux binaries at all ?

Afaik it is an Unix-like environment to compile in, but that doesn't mean the binaries are compatible.

Wasn't there something years (decades!) ago about Cygwin being needed for some of the toolchain stuff on Windows?

Not that I know.  Before (I think )somewhere during the  FPC 2.2.0 cycle, the textmode IDE's GDB is was cygwin based, which is why we distributed a cygwin dll.

Diffutils, binutils and Coreutils and make were based on mingw, at least after 2000. The current versions are mostly based on mingw versions from 2005 because later integrated with MSYS, and were less standalone. The binutils and make are slightly newer (2010/11).

I can vaguely remember in very old days, a cygwin make was used in combination with the dos distribution on windows NT to work around dos make's threading issues and quirks

See also https://wiki.freepascal.org/helper_tools though that isn't probably 100% up to date.

He might have been trying to work from a set of obsolete instructions, and trying to merge an up-to-date FPC version.

I highly doubt it , and they wouldn't have been for a Linux binary tar ball. Maybe applied WSL instructions to cygwin, or just trying random things

FPC currently supplies its own copy of coreutils. Version info says it was packaged by CygWin. So, I guess we all use CygWin. \_(oo)_/

Are you sure, and if so which one? Make sure you don't accidentally use a cygwin binary. But as FPC doesn't package a cygwin dll anymore, this is highly unlikely.

[dsiders]

Are you sure, and if so which one? Make sure you don't accidentally use a cygwin binary. But as FPC doesn't package a cygwin dll anymore, this is highly unlikely.

I stand corrected. That was cygwin intercepting the call i guess. It actially reports GNU fileutils 3.16. My bad.

[dbannon]

Hey Steven, if you are still with us.  Please tell us what you are trying to achieve, as you can see, there is quite lot of concern about the way you are going about it right now. I am pretty sure you will get better advice if you explain what you want to be able to do.

Davo

[Steven Pietrobon]

Thanks for all your responses. You're right that the Linux executables don't run in Cygwin. Due to the legacy software I use, I'm stuck with using 32-bit Windows XP. I use Free Pascal to compile my programs for Windows 32-bit, but a lot of people would like my programs to run in Linux. What I do now is use FP 3.0.4 i386 in Windows and cross compile to Linux. To do that, I installed the Linux i386 version of FP 3.0.4 in Cygwin and the cross-compiler binaries binutils-2.15-win32-i386-linux.zip in C:\FPC\3.0.4\bin\i386-win32. The command I use to cross compile is the following, where %1 is the file to be compiled.

ppc386 -Tlinux -FuC:\cygwin\usr\local\lib\fpc\3.0.4\units\i386-linux\rtl -FuC:\cygwin\usr\local\lib\fpc\3.0.4\units\i386-linux\rtl-console  %1

What I wanted to do was upgrade to FP 3.2.2 and cross compile that to Linux. It would also be nice to test my Linux compilations, as I currently can't do that.

[MarkMLl]

Thanks for all your responses. You're right that the Linux executables don't run in Cygwin. Due to the legacy software I use, I'm stuck with using 32-bit Windows XP.

Either put your sources on a Subversion server and compile separately on Windows and Linux, investigate a cross-compiler, or investigate dual-boot or emulation for different Windows versions.

I'd vote for the first of those, since sooner or later library dependencies etc. will give you problems on XP. I've got a copy which I use extremely infrequently but can't remember whether I've tested FPC/Lazarus on it, but it's a fair bet that the compiler and IDE developers won't be enthusiastic supporting it.

MarkMLl

[dbannon]

....What I do now is use FP 3.0.4 i386 in Windows and cross compile to Linux. To do that, I installed the Linux i386 version of FP 3.0.4 in Cygwin and the cross-compiler binaries binutils-2.15-win32-i386-linux.zip in C:\FPC\3.0.4\bin\i386-win32.

I would have thought you could cross compile to a Linux binary without involving Cygwin I routinely build complete Windows binaries on Linux and don't need any Windows libraries present, someone here must be generating Linux binaries on windows ??

But, personally, I think Mark's suggestion is by a very large margin the best approach. Dual boot your existing computer as long as you have the disk space. Putting your source on a remote repo is a good thing generally but not necessary, Linux will quite happily read and write to your windows file system. And the nice thing is you can test your app under Linux that way too. Scaling can sometimes be a surprise ....

And you can safely take your Linux box onto the net, I sure would hate to do that with Windows XP.....

Davo

[marcov]

There used to be cross binutils on the FTP server, the last time I tried (2015ish I guess).  Then you need to fetch the libraries (.so) you link with and startup code (crt*.o) from the gcc lib on your linux machine. (see e.g. the buildfaq, in the more documentation part of the FPC website)

However textfiles and symbol versioning have made the Linux linking process more complex in the last few years.

[lproven]

Due to the legacy software I use, I'm stuck with using 32-bit Windows XP.

That is a very bad plan indeed in 2022. Can you give us a little more info about what legacy software and why?

Options to explore:

XP can run under 64-bit Win7 as a guest and all the tools are free downloads from MS: the VM and the OS image. This is called "XP Mode" and I described it here:
https://www.theregister.com/2014/04/10/how_to_run_xp_on_new_windows/

More info:
https://www.theregister.com/2009/05/01/windows_7_xp_mode_review/

Win10 is still current and in support. It has a 32-bit version and that can run DOS and 16-bit Windows apps. If you just need some 16- or 32-bit XP software that has drivers or is not compatible with 64-bit Windows, it will almost certainly run natively just fine on 32-bit Win10.

XP is out of support even with the extended support hack described here:
https://www.theregister.com/2014/05/26/german_tinkerer_gets_around_xpocalypse/

It's not safe to run XP online at all now.

Win7 has hacks to get the paid-for enterprise updates. You can run XP Mode on 64-bit Win7 just fine, according to MS itself:
https://answers.microsoft.com/en-us/windows/forum/all/windows-7-professional-64-bit-os-and-xp-mode/26ff56f8-6082-e011-9b4b-68b599b31bf5?auth=1