why can't one locate easily installable, pre-packaged "add-ons" (not correct term) for cross-compiling capabilities?

for example, one might install the win32 flavor of Laz/FPC and then simply install the win32 flavor of the "linux cross-compile add-on"... the "linux cross-compile add-on" would have everything necessary for cross-compiling to linux... no rebuilding this or rebuilding that... simply tell the compiler that the target is linux, hit the build or compile button and the compiler spits out the proper binary...

so, your development workstation is a *nix flavor? install the *nix flavor of Laz/FPC followed by the *nix flavor of the "Win32 cross-compile add-on" that has the win32 code and libs for cross-compiling to the win32 platform from linux... same for OS/2 or OSX or any of the other OS' that Laz/FPC can compile for... each base install flavor would have packaged "add-ons" in that flavor for the other platforms that can be cross-compiled for...

does that make sense?? i don't think that these "add-on" packages would really be all that large, either... they're mostly source code and a binary or three, right?

sure, there may need to be a way of denoting the project's compiled binary file name for each flavor so that they don't stomp on each other because their name is the same since it is derived from the project name...

ie: foo : linux
foo.exe : DOS
foop.exe : OS/2
foog32.exe : DOS w/GO32 extender (pulled off top of my head) foow32.exe : windows 32bit
foow64.exe : windows 64bit

i dunno... it just seems so difficult... much more difficult than it could be or should be... but i'm still here... reading and learning what i can and offering up my two centavos here and there...

ahhh... and here's something i haven't seen anyone mention... i have a few apps from long ago that are one binary that runs under several OS'... one executable that runs natively on OS/2 and on DOS... i believe that binary also runs natively on windows but i haven't tried it since i don't use windows for that particular task (old style Fidonet BBS for those who really want to know)... so, how would/could something like that be done? is it possible with Laz/FPC? is it necessary? would it be nice to distribute one binary no matter what platform it was going to be executed on?

waldo kitty wrote

does that make sense?? i don't think that these "add-on" packages would really be all that large, either...

There is definitely a demand for this. With Lazarus IDE this is a nightmare - just too many settings to fiddle with. MSEide is *much* it's different build modes and user defined
macro's it is rather easy to accomplish. fpGUI's IDE (not available to the public yet), this is also available in much the same way as MSEide. With one mouse click I can now build for Linux 32, or Linux 64, or Windows 32, or Windows ME.

apps from long ago that are one binary that runs under several OS'... one executable that runs natively on OS/2 and on DOS... i believe that binary

There is something called FatELF executables (Google it for more information). But this allows you to inject various platforms executable into one "fat" executable. Similar type of thing as the Universal Binary idea from Apple. As an example of how well FatELF works, they make a 32 & 64 bit Ubuntu distribution. One CD supporting both platforms. I wonder if FPC could be modified to generate such executables.

Does it support Windows XP -> linux 32 ?

Vincent

Compiling for any *nix platform requires a set of libraries to link against, since LD works that way. First: you can't simply distribute them (licensing). Second: they are version dependant. If I would compile against a much newer glibc than on my target system (or just one which is compiled differently) it might "go wrong". I had such cases - it cross-compiled fine but always crashed on _some_ target systems.
Cross-compiling is not easiest you can currently get is probably the Lazarus distribution called CodeTyphon[1]. I haven't extensively tried cross compiling with it, though. But it offers it as feature, so you might want to give it a shot :-)

Best Regards,
Andreas.

[1]:
http://www.pilotlogic.com/sitejoom/index.php?option=com_content&view=article&id=96&Itemid=147

How does it handle binutils? Do you need to prepare them before building, or does it somehow install them when needed?

Regards,
Juha

Vincent Snijders wrote

Does it support Windows XP -> linux 32 ?

I have not tried that configuration. My main OS is Linux, so I cross-compile from there to other systems. But if FPC supports that setup, then it should be possible with MSEide too. The main point being that MSEide is very flexible with switching configurations with the least amount of effort.

Juha Manninen wrote

How does it handle binutils? Do you need to prepare them before building, or does it somehow install them when needed?

I already had lines as follows in the ~/.fpc.cfg file from previous attempts, but these could just as easily have been specified from inside the IDE via build modes compiler parameters.

eg:

# cross-compiling to i386 support - special library path #IFDEF cpui386
-Fl/usr/lib32
-Xd
#ENDIF

what is "it"? MSEide?

hunh? the compiled shared .so files and their source cannot be distributed? i'm mainly thinking about GPLed type stuff although i am sure that there are other *nix libs out there that have their own "problems" with distribution like this...

Second: they are version dependant. If I would compile against a much newer glibc than on my target system (or just one which is compiled differently) it might "go wrong". I had such cases - it cross-compiled fine but always crashed on _some_ target systems.

hummm... that does, indeed, complicate things... at the least, it means that several "sub-flavors" of the basic "cross-compile add-on" would need to be available... or at least the shared .so files would need to be...

i have heard of and briefly looked at it but shied away because i wasn't sure about support nor how current it is/was... as i tried to depict, it really ought to be easier than it currently is... i have numerous projects that would really benefit from this capability but, as it stands, it is too complicated to easily enable such at this point in time... hopefully one day it will be as simple as installing the base product and then simply ticking all of the other platforms you want to compile for and at the end, you end up with a binary for each of those chosen platforms (ie: tick several, hit the build or compile button, go get a cuppa' joe, and return to 2, 3 or more fresh binaries that only need be packaged for their destination OS platform :)

waldo kitty wrote

hopefully one day it will be as simple as installing the base product and then simply ticking all of the other platforms you want to compile for and at the end, you end up with a binary for each of those chosen platforms (ie: tick several, hit

Then take a look at RealBasic - that is exactly how they do it. Tick the platforms and click Build. How they actually accomplished this feat is another story. :)

See the first screenshot on this page:
http://www.realsoftware.com/realbasic/featurelist

No, fpGUI's IDE.

Vincent

Four platforms (macosx universal is not an own) is doable. An FPC installer for four platforms might be 100 MB and when one gets >100 Eur or US-$, one can also waste the bandwidth and disk space for such a package or when one expects to sell 100 of these packages to waste one month of time to implement flawless on the fly compilation of the cross packages if needed.

Same answer as the one I gave for MSEide. I have not tried that configuration as my main OS is Linux and I cross-compile from there.

[off topic]
I finally got some (very basic) syntax highlighting in fpGUI IDE working. :-)

Do they link dynamic at all? Do they target all distributions? Do they support features at all that are not in their oldest supported distro?

etc etc

Marco van de Voort wrote

Do they link dynamic at all? Do they target all distributions? Do they support features at all that are not in their oldest supported distro?

I don't know, I don't use REAL Studio (previous know as RealBasic). Their website does say Linux distro independent. It also mentions that it requires no VB runtime libraries like Microsoft Visual Basic did (that's a good thing). Download the 30-day trial and try it yourself, or email their support staff with your questions.

Or maybe their online help will answer your questions. http://docs.realsoftware.com/index.php/Main_Page

My point was simply that a ISV did manage to make cross-compiling as simple as possible with just a few mouse clicks.

hahaha! thanks but no thanks! ;)

i left B.A.S.I.C. in the dust back in the late '70's or early '80's when i taught myself ASM and picked up my first copy of TP... i think that was TP2 but it may have been TP1... the first thing i did was to "rewrite" (read as completely re-develop) a menuing program in a few days... it ran circles around the one i had written in B.A.S.I.C. it was faster, easier to maintain, offered more features and didn't crash when someone sneezed or looked at the screen cross-eyed...

How they actually accomplished this feat is another story. :)

i'm not sure i really want to know, either :shock: :lol:

waldo kitty wrote

i left B.A.S.I.C. in the dust back in the late '70's or early '80's when i taught myself ASM and picked up my first copy of TP... i think that was TP2

I don't use RealBasic, but to be fair, RealBasic's language is nothing like the Basic from the 80's or VB6. Just like Object Pascal is near nothing like Turbo Pascal 1. The RealBasic language has classes, inheritance etc...

They seem to be in the same boat as we are. When people see the words "basic" or "pascal", they think of the language 20+ years ago. :-/ That was probably the main driving force for Borland to rename the language to "delphi", to break that chain of thought.

Graeme Geldenhuys wrote

There is something called FatELF executables (Google it for more information). But this allows you to inject various platforms executable into one "fat" executable. Similar type of thing as the Universal Binary idea from Apple.

I was thinking of that one as soon as I saw the original question. Trouble is it needs a kernel patch for unix, and I don't see much chance of it working with MS OSes. Simplistically, you could probably do the same with a shell archive.

Another thing that might be relevant is the Crosstool scripts for GCC, you tell them what host and target you want and (eventually) get a tailored compiler.