Re: [fpc-devel] Crosscompiling win towards darwin

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 23 Nov 2016, Alfred wrote:

> > 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.

> I will have a look at the patches again.

Cool, please keep us posted for updates.

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

Re: [fpc-devel] Crosscompiling win towards darwin

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 23 Nov 2016, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Crosscompiling win towards darwin

[Jonas Maebe]

> On 21 Nov 2016, at 11:40, Alfred  wrote:
> 
> 
> 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-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Crosscompiling win towards darwin

[Sven Barth]

Am 21.11.2016 11:40 schrieb "Alfred" :
> c++ code.

Comments added inline.

>
> findFile(path):
> Options::FileInfo Options::findFile(const std::string ) 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.

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

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Crosscompiling win towards darwin

[Sven Barth]

Am 21.11.2016 11:40 schrieb "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.
>
> c++ code.
>
> findFile(path):
> Options::FileInfo Options::findFile(const std::string ) const
> calls:
> if ( findFile(path, {".tbd"}, result) )
> return result;
>
> findFile(path,{...},result):
> bool Options::findFile(const std::string , const
std::vector , FileInfo& result) const
> calls
> for ( const auto  : 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.

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Crosscompiling win towards darwin

[Jonas Maebe]

Alfred wrote on Mon, 21 Nov 2016:

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-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Crosscompiling win towards darwin

[Sven Barth]

Am 21.11.2016 10:15 schrieb "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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Crosscompiling win towards darwin

[Jonas Maebe]

Alfred wrote:
> 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

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 " 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-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel