Re: [fpc-devel] resources on non-windows platform

[Jonas Maebe]

Anton Kavalenka wrote:
> {$R script.rc srcipt.res}
> 
> This kind of resource management implies usage of windres (or any other
> RC script compiler)
> 
> With the crosscompilation things became funnier:
> 
> I can under Linux get win32 exe with mingw-windres
> 
> I can under Linux get Mach-O 32 exe with odcc-windres
> 
> I can NOT under MacOS get Mach-O 32/64 exe with resources.

Can't you just convert the the .rc file to .res (with windres on any
platform) and then let FPC convert the .res file to the appropriate
object format?

> Is not the time came for own resource compiler for limited type of
> resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)?

I would argue we already have plenty of things to maintain that are
tangential to the compiler itself. Additionally, while the above might
be enough for use case, it doesn't work to do this for a large and
generic project. We either do something well, or not at all.


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

Re: [fpc-devel] resources on non-windows platform

[Sven Barth]

Am 22.11.2016 08:04 schrieb "Anton Kavalenka" :
> So the question - why current FPC can link .res under any platform (with
the help of fpcres) but cannot build such file under any platform without
foreign tools?

Because there's no cross platform Pascal only tool for this.

> Is not the time came for own resource compiler for limited type of
resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)?

Patches welcome.

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

[fpc-devel] resources on non-windows platform

[Anton Kavalenka]

Dear FPC-all!


I have a big projects with lots of DLLs. All of them are cross-platform 
and link the resources with $R directive.


For version info I use .rc scripts to manage it under VCS and to prevent 
.RES flicker under different compilers (FPC and Delphi)


Version info is a nice example.

{$R script.rc srcipt.res}

This kind of resource management implies usage of windres (or any other 
RC script compiler)


With the crosscompilation things became funnier:

I can under Linux get win32 exe with mingw-windres

I can under Linux get Mach-O 32 exe with odcc-windres

I can NOT under MacOS get Mach-O 32/64 exe with resources.

So the question - why current FPC can link .res under any platform (with 
the help of fpcres) but cannot build such file under any platform 
without foreign tools?


Is not the time came for own resource compiler for limited type of 
resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)?


with best regards,

Anton

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

Re: [fpc-devel] ANN: Management operators - final patch

[Florian Klämpfl]

Am 21.11.2016 um 02:54 schrieb Paul Ishenin:
> 21.11.2016 8:16, Maciej Izak wrote:
> 
> Overall you've made a great job and a perfect example of how to supply 
> patches for FPC.
> 
> I have a small question regards the following commit:
>> 13. 
>> https://github.com/maciej-izak/freepascal/commit/9baa32a49a204686427981d33c9054f64b2057c4
> 
> Use fpc_Copy for Clone and fpc_Addref for Copy is misleading.

Copy is only equal to addref in case of arc types. If a type is only managed 
like a variant, copy is
not an addref operation. So it should not be called addref. As fpc_addref is 
not exposed to users I
think we can handle this.

> 
> I know Florian insisted on Copy and Clone names but still for my taste it 
> would be the best to have
> conformity between compiler and RTL.

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

[fpc-devel] Crosscompiling win towards darwin

[Alfred]

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

[fpc-devel] Crosscompiling win towards darwin

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



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


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

[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

[fpc-devel] Crosscompiling win towards darwin

[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 !

Thanks again for the advice.

Will report back.

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

[fpc-devel] Crosscompiling win towards darwin

[Alfred]

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

Re: [fpc-devel] ANN: Management operators - final patch

[Maciej Izak]

2016-11-21 2:16 GMT+01:00 Maciej Izak :

> I have new dedicated branch located here:
>
> https://github.com/maciej-izak/freepascal/tree/fpc-management-operators
>

note: management operators are also available in version for NewPascal :

https://github.com/maciej-izak/freepascal/tree/management-operators


If someone is interested in tests, "ready to use" compiler with management
operators and latest Lazarus is available at:

http://newpascal.org

-- 
Best regards,
Maciej Izak
___
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

Re: [fpc-devel] ANN: Management operators - final patch

[Maciej Izak]

2016-11-21 2:54 GMT+01:00 Paul Ishenin :

> Use fpc_Copy for Clone and fpc_Addref for Copy is misleading.


First of all I don't like to have Florian in opposition to this feature ;)
it is a teamwork.

Anyway I agree that this is misleading... But as was suggested by Florian
(as far as I understand):

On the language level Clone and Copy is totally new feature. Users don't
have direct access to FPC_COPY nor FPC_ADDREF. FPC_COPY and FPC_ADDREF
naming is outdated and probably renaming to FPC_CLONE and FPC_COPY is good
idea, but old convention is still in usage for backward compatibility with
old code (for "alias"/"public name" feature).

I can't do much in this matter.
-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel