[fpc-pascal] Packaging shared libraries for OSX, recommendations?

[Bruce Tulloch]

What is the *recommended* way to build and package a shared library for OSX?

Our aim is that ordinary users can "just install it" such that other
applications that depend on the library "just run" (without requiring
authors of those other applications to include a copy of the library in
their bundle or users to fiddle with command line command to configure them
if they don't).

This library facilitates low level I/O. There are no UI or other resources
but it has headers for those who want to build apps against it. If this
were just UNIX we'd put under /usr/lib (and /use/include and perhaps
/usr/share) but doing this this seems to be discouraged when reading the
Apple's developer docs.

We don't want to depend on MacPorts, Fink or Brew etc. Should we be
packaging this as a framework, albeit a simple one? What do Mac users (and
Mac app programmers) prefer or expect when using shared libraries these
days?

Thanks, Bruce.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] TGZStream and Int64-sized streams

[Roland Schäfer]

Hi all,

I'm wondering if anyone is maintaining TGZFileStream, because TStream
has Int64-typed Position, Size, and Seek-Offset, and I need this in
TGZStream for some large files I process. Any solutions?

Cheers!
Roland
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] is there a ready to use FPC Cross compiler x86-Linux -> MIPS-linux?

[Jonas Maebe]

On 09 Jun 2013, at 19:08, Dennis Poon wrote:



Also, in Lazarus, it still report /usr/bin/fpc does not support  
mips-linux.


Should I go into the .lazarus folder in my user folder and change  
the environmentoptions.xml

from 
to 
?

Frankly, I don't understand why I have to BOTH change the compiler  
path AND change the project's option "Code Generation"->"Target  
Platform".

That looks redundant to me.


It's not redundant because /usr/bin/fpc cannot automagically find a  
ppcmips binary located in a random directory on your system.


I tried changing the environmentoptions.xml but that seems not  
enough. Upon starting lazarus, it complained under Compiler Tab:

system.ppu not found. Check fpc.cfg

Where I can locate that fpc.cfg?


This is explained in the manual: http://www.freepascal.org/docs-html/user/usersu10.html 
 . However, you should not modify the global fpc.cfg file. Instead,  
in your home directory create a file .fpc.cfg (note the leading ".";  
this is also mentioned in the manual at the same place) with as contents


#include /etc/fpc.cfg
#ifdef cpumips
-Fu/home/dennis/fpc/$fpcversion/units/$fpctarget
-Fu/home/dennis/fpc/$fpcversion/units/$fpctarget/*
-Fu/home/dennis/fpc/$fpcversion/units/$fpctarget/rtl
#endif


Also, if complained under "FPC Source" tab when I entered "/home/ 
dennis/fpc/rtl"

"Warning directory rtl not found"


That's because there is no /home/dennis/fpc/rtl/rtl directory.  
Additionally, you have to point it to the top level directory  
containing the FPC *sources*. Since your previous mails showed that  
you specified "/home/dennis/fpc" as the INSTALL_PREFIX, I hope "/home/ 
dennis/fpc" is not also your source directory. It shouldn't break  
anything in case it is, but it's not very clean to install there.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Packaging shared libraries for OSX, recommendations?

[Jonas Maebe]

On 10 Jun 2013, at 09:22, Bruce Tulloch wrote:

What is the *recommended* way to build and package a shared library  
for OSX?


Our aim is that ordinary users can "just install it" such that other
applications that depend on the library "just run" (without requiring
authors of those other applications to include a copy of the library  
in
their bundle or users to fiddle with command line command to  
configure them

if they don't).


The above is the non-recommended way. The recommended way is to have  
application packagers include the library (or framework) within their  
application bundle in order to prevent version conflicts or the  
absence of the correct version on the system to cause problems. And to  
give them the ability to just copy the application from one system to  
another and have it keep working without having to hunt everywhere for  
other components they also have to copy (although this is not possible  
for all applications, for most it is).


This library facilitates low level I/O. There are no UI or other  
resources
but it has headers for those who want to build apps against it. If  
this

were just UNIX we'd put under /usr/lib (and /use/include and perhaps
/usr/share) but doing this this seems to be discouraged when reading  
the

Apple's developer docs.


Under Mac OS X (and *BSD, and probably even most Linux distributions  
these days), you would put it under /usr/local/[lib,include,share]. / 
usr/lib etc are reserved for system usage.



We don't want to depend on MacPorts, Fink or Brew etc. Should we be
packaging this as a framework, albeit a simple one?


If you absolutely want to distribute it as a standalone framework, you  
would generally install it under /Library/Frameworks or under /Library/ 
Application Support/YourProductName.



Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Packaging shared libraries for OSX, recommendations?

[Bruce Tulloch]

On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe wrote:

Under Mac OS X (and *BSD, and probably even most Linux distributions these
> days), you would put it under /usr/local/[lib,include,share].


Understood. So if we install our library, headers etc to
/usr/local/[lib,include,share] is it true that like any UN*X, in OSX:

   - Command line programs *and* GUI apps will be able to use our library,

   - XCode will be able to find and access the headers and,

   - XCode App programmers can copy the .dylib file (from
   /usr/local/lib/libMyLib.dylib) to their project to include the library and
   avoid the need to redistribute our package?

Presuming the answers are all yes, is packagemaker the tool we should be
using to package the library for distribution?

Bruce.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Packaging shared libraries for OSX, recommendations?

[Jonas Maebe]

On 10 Jun 2013, at 11:41, Bruce Tulloch wrote:

On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe >wrote:


Under Mac OS X (and *BSD, and probably even most Linux  
distributions these

days), you would put it under /usr/local/[lib,include,share].


Understood. So if we install our library, headers etc to
/usr/local/[lib,include,share] is it true that like any UN*X, in OSX:

  - Command line programs *and* GUI apps will be able to use our  
library,


There is no difference between the two as far as the dynamic linker is  
concerned.



  - XCode will be able to find and access the headers and,


Yes.


  - XCode App programmers can copy the .dylib file (from
  /usr/local/lib/libMyLib.dylib) to their project to include the  
library and

  avoid the need to redistribute our package?


The last part is incorrect. See e.g. http://qin.laya.com/tech_coding_help/dylib_linking.html 
 and https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac 
 for more information. You need at least two versions of your  
library, or tell developers that want to include the library in their  
program to adapt the library's path with install_name_tool and compile/ 
link against this modified version because otherwise their application  
will still insist on only looking for the /usr/local/lib version  
(which is why distributing a /usr/local/lib version is such a bad  
idea, because developers won't notice on their own machine if they  
make a mistake since that version can be used without them realising it)


Presuming the answers are all yes, is packagemaker the tool we  
should be

using to package the library for distribution?


Yes.


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Packaging shared libraries for OSX, recommendations?

[Bruce Tulloch]

Okay, got it, thanks Jonas. -b


On Mon, Jun 10, 2013 at 7:55 PM, Jonas Maebe wrote:

>
> On 10 Jun 2013, at 11:41, Bruce Tulloch wrote:
>
>  On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe *
>> *wrote:
>>
>>  Under Mac OS X (and *BSD, and probably even most Linux distributions
>>> these
>>> days), you would put it under /usr/local/[lib,include,share]**.
>>>
>>
>> Understood. So if we install our library, headers etc to
>> /usr/local/[lib,include,share] is it true that like any UN*X, in OSX:
>>
>>   - Command line programs *and* GUI apps will be able to use our library,
>>
>
> There is no difference between the two as far as the dynamic linker is
> concerned.
>
>- XCode will be able to find and access the headers and,
>>
>
> Yes.
>
>- XCode App programmers can copy the .dylib file (from
>>
>>   /usr/local/lib/libMyLib.dylib) to their project to include the library
>> and
>>   avoid the need to redistribute our package?
>>
>
> The last part is incorrect. See e.g. http://qin.laya.com/tech_**
> coding_help/dylib_linking.htmland
> https://blogs.oracle.com/**dipol/entry/dynamic_libraries_**rpath_and_macfor
>  more information. You need at least two versions of your library, or
> tell developers that want to include the library in their program to adapt
> the library's path with install_name_tool and compile/link against this
> modified version because otherwise their application will still insist on
> only looking for the /usr/local/lib version (which is why distributing a
> /usr/local/lib version is such a bad idea, because developers won't notice
> on their own machine if they make a mistake since that version can be used
> without them realising it)
>
>
>  Presuming the answers are all yes, is packagemaker the tool we should be
>> using to package the library for distribution?
>>
>
> Yes.
>
>
>
> Jonas
> __**_
> fpc-pascal maillist  -  
> fpc-pascal@lists.freepascal.**org
> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] AWS S3 RESTAuthentication

[Marcos Douglas]

Hi,

Someone know how translate the "code" bellow to Pascal?
http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

=== code ===
Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;

Signature = Base64( HMAC-SHA1( YourSecretAccessKeyID,
UTF-8-Encoding-Of( StringToSign ) ) );

StringToSign = HTTP-Verb + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedAmzHeaders +
CanonicalizedResource;

CanonicalizedResource = [ "/" + Bucket ] +
 +
[ sub-resource, if present. For example "?acl", "?location",
"?logging", or "?torrent"];

CanonicalizedAmzHeaders = 

=== code ===

I tried something like:

  function StringToSign: string;
  begin
Result := HTTPVerb + #10   // GET, PUT, etc
+ '' + #10// ContentMD5
+ '' + #10// ContentType
+ RfcDateValue + #10  // Date
+ ''  // CanonicalizedAmzHeaders
+ '/'; //+BucketName; // CanonicalizedResource;
  end;

  function GetSignature: string;
  begin
Result := EncodeBase64(HMACSHA1(FSecretKey, UTF8Encode(StringToSign)));
  end;



Thank you very much.

Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Re: AWS S3 RESTAuthentication

[Marcos Douglas]

On Mon, Jun 10, 2013 at 9:43 PM, Marcos Douglas  wrote:
> Hi,
>
> Someone know how translate the "code" bellow to Pascal?
> http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
>
> === code ===
> Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;
>
> Signature = Base64( HMAC-SHA1( YourSecretAccessKeyID,
> UTF-8-Encoding-Of( StringToSign ) ) );
>
> StringToSign = HTTP-Verb + "\n" +
> Content-MD5 + "\n" +
> Content-Type + "\n" +
> Date + "\n" +
> CanonicalizedAmzHeaders +
> CanonicalizedResource;
>
> CanonicalizedResource = [ "/" + Bucket ] +
>  +
> [ sub-resource, if present. For example "?acl", "?location",
> "?logging", or "?torrent"];
>
> CanonicalizedAmzHeaders = 
>
> === code ===
>
> I tried something like:
>
>   function StringToSign: string;
>   begin
> Result := HTTPVerb + #10   // GET, PUT, etc
> + '' + #10// ContentMD5
> + '' + #10// ContentType
> + RfcDateValue + #10  // Date
> + ''  // CanonicalizedAmzHeaders
> + '/'; //+BucketName; // CanonicalizedResource;
>   end;
>
>   function GetSignature: string;
>   begin
> Result := EncodeBase64(HMACSHA1(FSecretKey, UTF8Encode(StringToSign)));
>   end;
>
>
>
> Thank you very much.
>
> Marcos Douglas

Ok, I got it.   ;-)

Marcos Douglas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Some RTL functions cry big tears when mixing Pchar and Ansistring/String

[m...@rpzdesign.com]

Under Linux using Lazarus 1.0.8/Fpc 2.6.2/Fedora 14 x64:

it seems like mixing Ansistrings and Pchars on certain run time 
functions is a real no-no.


I just spent HOURs, trying to see why I was not getting good program 
behavior.


Lesson #1: Never call function like Copy( pchar, start, length),

ONLY use Copy( ansistring/string, start, length)

Other functions like PosEx( ) do not generate compiler
errors but you really do NOT want a Pchar to this function,
only an ansistring/string.

Passing a Pchar gives weird, erratic behavior

Maybe the RTL library team could put compiler WARNINGS about only 
allowing for strings/ansistrings
on copy( ), posex( ), and other functions who have really no business 
taking pchar arguments.


Cheers,

md

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Packaging shared libraries for OSX, recommendations?

[Bruce Tulloch]

So just to be clear, if we create a framework designed for others to bundle
with their own apps where our framework (for the library) looks like this:

MyFramework.framework
|-- MyFramework -> Versions/Current/MyFramework
|-- Headers -> Versions/Current/Headers
|-- Resources -> Versions/Current/Resources
`-- Versions
|-- A
|   |-- MyFramework
|   |-- Headers
|   |   |-- MyFramework.h
|   |   `-- MyFramework.pas
|   `-- Resources
|   |-- English.lproj
|   |   `-- Documentation
|   |   `-- MyFrameworkAPI.html
|   `-- Info.plist
`-- Current -> A

Xcode users of our library just include the framework binary (i.e. the
dylib, also called MyFramework in this example) in their project. However,
as part of our library build process we MUST use install_name_tool to
modify the canonic path in the dylib to be relative to the executable
location in the app bundle created by Xcode (when they build their app) and
this relative location will always be as described in the linked examples
you referred us to (i.e. @executable_path/../Frameworks/MyFramework).

Have we understood this correctly?

Can you give me some background on why it works this way? My understanding
is that even if an app finds the dylib it needs in its own bundled
Frameworks folder, ld refuses to load it because the dylib says its canonic
home is somewhere else and this therefore requires the publisher of that
dylib to modify the path to be where any app that uses it expects to locate
the dylib even if said app already knows the location of the necessary
dylib. This seems to be a rule (or bug?) which is apparently more
inflexible than the standard UNIX way ld uses to locate libraries.

Thanks for your pearls of wisdom on this strange (to us) topic :-)

Cheers, Bruce.



On Mon, Jun 10, 2013 at 7:55 PM, Jonas Maebe wrote:

>
> On 10 Jun 2013, at 11:41, Bruce Tulloch wrote:
>
>  On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe *
>> *wrote:
>>
>>  Under Mac OS X (and *BSD, and probably even most Linux distributions
>>> these
>>> days), you would put it under /usr/local/[lib,include,share]**.
>>>
>>
>> Understood. So if we install our library, headers etc to
>> /usr/local/[lib,include,share] is it true that like any UN*X, in OSX:
>>
>>   - Command line programs *and* GUI apps will be able to use our library,
>>
>
> There is no difference between the two as far as the dynamic linker is
> concerned.
>
>- XCode will be able to find and access the headers and,
>>
>
> Yes.
>
>- XCode App programmers can copy the .dylib file (from
>>
>>   /usr/local/lib/libMyLib.dylib) to their project to include the library
>> and
>>   avoid the need to redistribute our package?
>>
>
> The last part is incorrect. See e.g. http://qin.laya.com/tech_**
> coding_help/dylib_linking.htmland
> https://blogs.oracle.com/**dipol/entry/dynamic_libraries_**rpath_and_macfor
>  more information. You need at least two versions of your library, or
> tell developers that want to include the library in their program to adapt
> the library's path with install_name_tool and compile/link against this
> modified version because otherwise their application will still insist on
> only looking for the /usr/local/lib version (which is why distributing a
> /usr/local/lib version is such a bad idea, because developers won't notice
> on their own machine if they make a mistake since that version can be used
> without them realising it)
>
>
>  Presuming the answers are all yes, is packagemaker the tool we should be
>> using to package the library for distribution?
>>
>
> Yes.
>
>
>
> Jonas
> __**_
> fpc-pascal maillist  -  
> fpc-pascal@lists.freepascal.**org
> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Some RTL functions cry big tears when mixing Pchar and Ansistring/String

[Jeppe Græsdal Johansen]

Den 11-06-2013 04:49, m...@rpzdesign.com skrev:


Passing a Pchar gives weird, erratic behavior 

Could you maybe describe this weird, erratic behavior?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Some RTL functions cry big tears when mixing Pchar and Ansistring/String

[Marco van de Voort]

In our previous episode, m...@rpzdesign.com said:
> 
> Passing a Pchar gives weird, erratic behavior

Please make minimal examples in a few lines, and add them to the bugtracker.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal