> On Mar 5, 2017, at 11:58, Ryan Schmidt wrote:
>
>
>> On Mar 4, 2017, at 10:39, Richard L. Hamilton wrote:
>>
>> libarchive/archive_read_disk_entry_from_file.c:677: error: ‘ACL_SYNCHRONIZE’
>> undeclared here (not in a function)
>>
>> What it boils down to is that the source is now using a
On Sun, Mar 5, 2017 at 1:47 PM, Michael wrote:
>
> On 2017-03-05, at 9:49 AM, Brandon Allbery wrote:
> > Also fixed-*path* libraries are part of the Mach-O format and the
> tooling does not exist to override this well...
>
> Is this why a program compiled against a brew installation of qt5 in
> /
Oh you can build stuff statically but that is a kind of manual work and not for
MP to do.
> On 5. Mar 2017, at 19:47, Michael wrote:
>
>
>> On 2017-03-05, at 9:49 AM, Brandon Allbery wrote:
>> Also fixed-*path* libraries are part of the Mach-O format and the tooling
>> does not exist to over
On 2017-03-05, at 9:49 AM, Brandon Allbery wrote:
> Also fixed-*path* libraries are part of the Mach-O format and the tooling
> does not exist to override this well...
Is this why a program compiled against a brew installation of qt5 in /usr/opt
won't work with a ports installation of qt5 in /
I have had a failure to complete an update using a script that I have used
for quite a while. I attach the script and the end part of the main.log.
Can someone please take a look and offer some likely cause(s)?
Thanks very much.
Comer
`/opt/local/var/macports/build/_opt_local_var_macports_sources
On Sun, Mar 5, 2017 at 12:33 PM, Michael wrote:
> I'm curious more as to: Why do we still generate code that links against a
> fixed-name library? Why does that name not include a version/API reference?
> Why not make static linked stuff, so that changes in the libraries don't
> break things?
M
On 2017-03-05, at 9:27 AM, Brandon Allbery wrote:
>
> On Sun, Mar 5, 2017 at 11:43 AM, Michael wrote:
> Why does Macports generate libraries that follow the 1970-era linking
> strategy?
>
> ... And we are not in a position to rewrite/reimplement stuff into a
> frameworks-based model, if ups
On Sun, Mar 5, 2017 at 11:43 AM, Michael wrote:
> Why does Macports generate libraries that follow the 1970-era linking
> strategy?
Because MacPorts is ports of programs for other platforms which don't have
frameworks... and do have politics (for example: Debian's strict adherence
to their pack
> On Mar 4, 2017, at 10:39, Richard L. Hamilton wrote:
>
> libarchive/archive_read_disk_entry_from_file.c:677: error: ‘ACL_SYNCHRONIZE’
> undeclared here (not in a function)
>
> What it boils down to is that the source is now using a symbol that was not
> defined in Snow Leopard (without chec
So here's a real basic question: Why dynamic linking? Why dynamic linking of
libraries by library name (as opposed to linking by library name + API version)?
I understand that, way way back in the dawn of time, computer drives were
small, computer memory was small, and needing to reuse code on d
On 5 Mar 2017, at 01:58, Michael wrote:
> Ok, how?
>
> Is it as simple as "copy these files out of the git tree into the /opt tree"?
> And if so, will that "clean up" automatically the next time I do a selfupdate?
>
> Is there an environment variable I can set to say "Find the portfiles here,
11 matches
Mail list logo
