Discussion:
Crosscompiling win towards darwin
(too old to reply)
Alfred
2016-11-21 06:56:16 UTC
Permalink
Raw Message
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.
Jonas Maebe
2016-11-21 08:35:49 UTC
Permalink
Raw Message
Post by Alfred
With the osxcross tools, cross-compilation of non-LCL programs from
Windows to Darwin is now successful.
Debug: FPC_RESLOCATION in project1.o
ld: symbol(s) not found for architecture i386
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Alfred
2016-11-21 09:09:26 UTC
Permalink
Raw Message
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 ?

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Alfred
2016-11-21 09:15:22 UTC
Permalink
Raw Message
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.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Sven Barth
2016-11-21 10:17:30 UTC
Permalink
Raw Message
Post by Alfred
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 !
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
Alfred
2016-11-21 10:40:33 UTC
Permalink
Raw Message
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" <***@googlemail.com>
Aan: "Alfred" <***@consulab.nl>; "FPC developers' list"
<fpc-***@lists.freepascal.org>
Verzonden: 21-11-2016 11:17:30
Onderwerp: Re: [fpc-devel] Crosscompiling win towards darwin
Post by Sven Barth
Post by Alfred
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 !
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
Jonas Maebe
2016-11-21 10:59:22 UTC
Permalink
Raw Message
Post by Alfred
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.
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Sven Barth
2016-11-21 13:39:43 UTC
Permalink
Raw Message
Post by Alfred
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.
Post by Alfred
c++ code.
Options::FileInfo Options::findFile(const std::string &path) const
if ( findFile(path, {".tbd"}, result) )
return result;
bool Options::findFile(const std::string &path, const
std::vector<std::string> &tbdExtensions, FileInfo& result) const
Post by Alfred
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.
Post by Alfred
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.
Post by Alfred
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
Sven Barth
2016-11-21 13:42:39 UTC
Permalink
Raw Message
Post by Alfred
c++ code.
Comments added inline.
Post by Alfred
Options::FileInfo Options::findFile(const std::string &path) const
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.
Post by Alfred
if ( findFile(path, {".tbd"}, result) )
return result;
bool Options::findFile(const std::string &path, const
std::vector<std::string> &tbdExtensions, FileInfo& result) const
Post by Alfred
calls
for ( const auto &ext : tbdExtensions ) {
auto newPath = replace_extension(path, ext);
bool found = tbdInfo.checkFileExists(*this, newPath.c_str());
}
Regards,
Sven
Jonas Maebe
2016-11-21 14:00:28 UTC
Permalink
Raw Message
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.
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Alfred
2016-11-21 14:07:50 UTC
Permalink
Raw Message
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.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Alfred
2016-11-23 10:58:40 UTC
Permalink
Raw Message
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.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Karoly Balogh (Charlie/SGR)
2016-11-23 11:40:03 UTC
Permalink
Raw Message
Hi,
To enable cross from Windows towards Darwin, some changes in FPC were needed.
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
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Alfred
2016-11-23 11:58:48 UTC
Permalink
Raw Message
Post by Karoly Balogh (Charlie/SGR)
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.

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Karoly Balogh (Charlie/SGR)
2016-11-25 09:56:58 UTC
Permalink
Raw Message
Hi,
Post by Alfred
Post by Karoly Balogh (Charlie/SGR)
TL;DR: if this patch was accepted into NewPascal w/o comments or concerns,
then "ouch"...
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;
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.
Post by Alfred
I will have a look at the patches again.
Cool, please keep us posted for updates.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Alfred
2016-11-25 10:29:53 UTC
Permalink
Raw Message
Post by Karoly Balogh (Charlie/SGR)
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.
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 ... ;-)

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Loading...