Has anybody any experience with using osxcross for cross-compiling from Windows towards Darwin ?

https://github.com/tpoechtrager/osxcross

I am experimenting with it at the moment, using cygwin. Osxcross binutils and MacSDK libs are ok on system.

Runs well, until an error when crosscompiling pp.pas: '.' is not recognized as an internal or external command.

Follow up.

With the osxcross tools, cross-compilation of non-LCL programs from Windows to Darwin is now successful.

When compiling with LCL, one final error keeps popping up: Error: linker: Undefined symbols for architecture i386: Error: linker: "FPC_RESSYMBOL", referenced from: Debug: "FPC_RESSYMBOL", referenced from:
Debug: FPC_RESLOCATION in project1.o
ld: symbol(s) not found for architecture i386

I have done a Google:
https://www.spinics.net/lists/gcchelp/msg31042.html http://www.freepascal.org/docs-html/3.0.0/fclres/format%20of%20resources%20in%20object%20files.html http://forum.lazarus.freepascal.org/index.php?topic=24555.0

But, for me, this is not easily solved.
Can somebody shed a light ??

Thanks.

FPC_RESSYMBOL is created by the resource writer (fpcres) in the object file generated from the resources.

You shouldn't need a complete Lazarus program to test this, tests/test/units/system/tres.pp should be sufficient.

If you compile that test with -va, you should see something like this:

[1.113] Calling resource compiler "/usr/local/bin/fpcres" with "-o tres.or -a i386 -s all -of mach-o -v '@tres.reslst'" as command line

In particular, the "-of macho-o" is important. There should be a tres.or file afterwards that defines FPC_RESSYMBOL. If your osxcross tools include a copy of the nm binary, you can use that to check: "nm tres.or" should print something like "00000000 S FPC_RESSYMBOL" (otherwise copy the file to a Mac and run nm there). On a Mac, you can also use "file tres.or" to verify that it is actually an i386 Mach-O object file.

This tres.or file should also be linked into the generated binary. Compile with -a -s and check whether tres.or appears in link.res and/or in the command line when calling the linker from ppas.bat. Run the generated ppas.bat file to see whether the linker prints any errors that Lazarus or the compiler hid.

Jonas

Thanks for this info and advice.

Sticking with Lazarus, I can see with "nm project1.or" S FPC_RESSYMBOL

I can see with "nm project1.o"
U FPC_RESSYMBOL

The link-script includes project1.or and project1.o (naturally), so now I am puzzled.

Any ideas ?

Please skip my previous mail.

I think I found the problem.
I had to patch osxcross-tools to work with FPC.
Now I need a new patch to include .or files !

Thanks again for the advice.

Will report back.

In how far did you have to patch the tools? The .or file should already be part of the linker script that FPC generates (you can get that with -sh, it's the link.res file).

Regards,
Sven

Well.

All files that are needed by the linker, have to be found by the linker. The osxcrosstools use a findfile process that is a bit peculiar. And not fully understood by me. Perhaps you can help.

c++ code.

findFile(path):
Options::FileInfo Options::findFile(const std::string &path) const calls:
if ( findFile(path, {".tbd"}, result) )

		return result;

findFile(path,{...},result):
bool Options::findFile(const std::string &path, const std::vector<std::string> &tbdExtensions, FileInfo& result) const calls
for ( const auto &ext : tbdExtensions ) {
auto newPath = replace_extension(path, ext);
bool found = tbdInfo.checkFileExists(*this, newPath.c_str()); }

So, as far as I understand correctly, if a fpc abc.o file is presented towards the linker, it replaces the extension with tbd and goes looking for abc.tbd.
I checked: if I add a dummy abc.tbd in the same location, all goes well.

That why I patched the search-process. But this very rude patch only took care of .o files.
I forgot about the .or files.

Trying new patches at the moment to no avail unfortunately.

------ Origineel bericht ------
Van: "Sven Barth"
Aan: "Alfred" ; "FPC developers' list"

Verzonden: 21-11-2016 11:17:30
Onderwerp: Re: [fpc-devel] Crosscompiling win towards darwin

Alfred wrote on Mon, 21 Nov 2016:

I would strongly recommend you try to get in touch with a developer of that project and ask him, because this kind of hacking is bound to lead to only more problems in the future. And questions about things where we have to blindly guess how your hacks and a third party packaging of some Apple tools interact. We can only support the official Apple tools.

Jonas

fully understood by me. Perhaps you can help.

std::vector<std::string> &tbdExtensions, FileInfo& result) const

towards the linker, it replaces the extension with tbd and goes looking for abc.tbd.

I checked: if I add a dummy abc.tbd in the same location, all goes well. That why I patched the search-process. But this very rude patch only took

care of .o files.

I forgot about the .or files. Trying new patches at the moment to no avail unfortunately.

IMHO they should first try to match the file as-is and only then use their own extension.
So your patch of Options::findFile should first check the passed on file name path and if that's found fill the result information as is done when the loop sets result to true. Only if that fails it should loop. If that works you might want to present the patch to the developers.

Regards,
Sven

"Alfred" wrote

c++ code.

Comments added inline.

findFile(path): Options::FileInfo Options::findFile(const std::string &path) const calls:

You should check before this call whether the file exists. "tbdInfo.checkFileExists(*this, path.c_str());" should do it and then you need to fill the result and return it.

std::vector<std::string> &tbdExtensions, FileInfo& result) const

Regards,
Sven

Fwiw, here's an explanation of what those .tbd files are: https://forums.developer.apple.com/thread/4572

That means they are at most relevant when linking libraries, and even in that case they're only a new way of distributing stub libraries. That means the linker code should definitely never only look for .tbd files. It may first try that and then fall back to the original name if nothing is found, but that's it.

Jonas

Thanks all for your help !

Cross-compiling LCL (GUI) works now !

(Simple) culprit : line-endings differences.

I will add a screen-shot of an app compiled with Lazarus on Windows, running on Mac.
Attachments are rejected by this list unfortunately.

See: http://bugs.freepascal.org/view.php?id=30964

Thanks again, Alfred.

Follow up.

To enable cross from Windows towards Darwin, some changes in FPC were needed.
They have been added into NewPascal, and can be found here: https://github.com/newpascal/freepascal/commit/a99fe9054957d2c42c780c4d05e59c6fbda31621 Not meant to be 100% correct, but working.

Summary:

New rtl-makefile for Darwin.

Some small changes in script.pas were needed to generate valid Windows batch-code for Darwin.

Changes in t_bsd.pas were more than trivial.
The Windows Darwin linker does not allow pipes. So, it needs a res that has to be serialized on the command line. But Windows limits the length of the command line to 8196 characters. Which is not enough when linking a lot of files in different directories. So the filelist option has to be used on Windows. Files are added into this filelist, the rest remains in res.
This also means that the default fpc.cfg does not work anymore, due to the default -ap switch for Darwin. This does not work on Windows.

A very minor patch was added into the crosstools to allow the successful find of files that are needed by the linker.
https://github.com/LongDirtyAnimAlf/osxcross/commit/44235f030ab49167bb5e7ddf323d4a1793f74cdf

Thanks again for your help.

Hi,

Alfred wrote

To enable cross from Windows towards Darwin, some changes in FPC were needed. They have been added into NewPascal, and can be found here: https://github.com/newpascal/freepascal/commit/a99fe9054957d2c42c780c4d05e59c6fbda31621 Not meant to be 100% correct, but working.

For a starter, if you should do something like:

if target_info.system in [system_i386_darwin,...] then...

instead of $IFDEF-ing HASUNIX. It's just a random idea, but because of HASUNIX, your patch might have actually broken Win->Linux crosscompiling... Plus

Also I haven't actually verified this, but if you actually need to use Unix-style scripting for Win->Darwin crosscompile, you could have just added an exception somehow to use Unix scripts in that case, instead of hacking it into the DOS-format scripts like this, really...

TL;DR: if this patch was accepted into NewPascal w/o comments or concerns, then "ouch"...

Charlie

Thanks for your advice.
This is exactly why NewPascal is here !

Have an idea. Implement. Make public.
perfect:=false;
while (NOT perfect) Use; Get feedback; Correct mistakes; Test; if ok
then perfect:=true; end;

All in a cycle of moments like hours or days.

I will have a look at the patches again.

Hi,

Well, we're talking about two different things. In this interpretation, NewPascal serves as some kind of FPC-experimental branch. Which is nice, and nothing to have against it.

But still, before merging anything to a master branch, there should be a way to review patches for obvious mistakes, or simply doing things in a wrong way. I see your pull request was accepted without comments in four hours after its submission. Which - given the amount of IFDEFs it contains, still "ouch", IMO. No offense, and nothing personal, just the criticism of the general approach towards code quality in a project with the size of FPC.

However, I agree that the FPC team should have a more streamlined way of accepting and reviewing patches, than posting diffs to a bugtracker or a mailing list. The Bazaar went elsewhere over the years, which is always a problem for an opensource project. But the tooling problem is only part of the story.

I will have a look at the patches again.

Cool, please keep us posted for updates.

Charlie

Thanks for your elaboration.
And again, this is why we needed NewPascal.
I know that my patches are not perfect, and perhaps also not valid. Meaning that we would have to wait for ages to get things done in FPC trunk.
Which is good IMHO: FPC trunk must be 100% ok for all.

All NewPascal changes are out in the open. Ready for use and review. The NewPascal contributors hope that one day, after thorough review, these changes will find their way into FPC.
And yes, sometimes these changes will cause an "ough", but that is also part of the fun ... ;-)