Re: macOS 11 and Apple Silicon

[Stephen J. Butler]

I'd think the promotion of implicit-function-declaration is something you'd
be able to work on and fix in the x86 architecture too, and that seems to
be the major first step here.

On Tue, Jun 23, 2020 at 1:41 AM Vincent Habchi  wrote:

>
> > On 22 Jun 2020, at 22:19, Jeremy Huddleston Sequoia <
> jerem...@macports.org> wrote:
> >
> > I just pushed some changes to base/master and dports/master to better
> support macOS 11 and Apple Silicon, but there's quite a bit of work ahead
> of us.
>
> […]
>
> >  Please reach out if you have any questions or concerns.
>
> We’re undoubtedly heading into a turbulence zone. Because not all of us
> will have early access to the new hardware (I won’t personally, and happen
> to have ordered the latest MacBook Air with an i7 CPU a few days ago…), it
> means that those who will will probably have to bear the burden of testing
> a lot of ports and reporting errors, while the maintainers won’t have the
> ability to test the fixes.
>
> Wouldn’t it be possible to somehow set up a new hardware machine with
> MacPorts installed and give all maintainers the possibility to log into it
> and test their ports?
>
> V.
>
>

Re: get user's home

[Stephen J. Butler]

For example, suppose I work in IT and someone needs ipfs on their machine.
I might SSH in, run "sudo port install ipfs", and then say "All done!" But
I'm not the one that will use that software, so it's not proper to encode
my username anywhere as a default.

On Fri, Aug 4, 2017 at 3:46 PM, Umesh Singla 
wrote:

> On a side note, I didn't get this part:
>
> The user installing the port is not necessarily the one that will use it.
>
>
>
>

Re: get user's home

[Stephen J. Butler]

If this is a system level daemon that's being started, then it seems to me
that it should be storing its data in a system level location.
/opt/local/var/ipfs or /opt/local/var/lib/ipfs or /opt/local/var/spool/ipfs
depending on various preferences.

On Fri, Aug 4, 2017 at 2:41 PM, db  wrote:

> On 4 Aug 2017, at 16:05, Joshua Root  wrote:
> > Should be in $user_home (if it could be determined, which is not
> guaranteed). But why do you need it? The user installing the port is not
> necessarily the one that will use it.
>
> That worked, thanks. I used it for an env var's default value in ipfs'
> startup item (#54566). I don't know if we could pass a different value on
> install or load, for that matter. Everything's fine as in works_for_me. How
> come schraderbräu has it and macports not?

Re: Is it time for a libc_fixes library yet?

[Stephen J. Butler]

I just noticed that the getdelim code manipulates the FILE* directly, so
that's not allowed in your lib. But it's essentially just filling a buffer
with data, processing it, and checking feof()/ferror() along the way.
Nothing complicated you can't reproduce with std api's.

On Mon, Jul 3, 2017 at 4:01 PM, Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> No reason at all, other than how I discovered them along the way! I have
> used AOS exclusively for months; I think these were the two original ones I
> replaced, last year.
>
> I will see how these can replace the existing ones.
>
> In the end, I sincerely hope this helps make supporting these older
> systems so easy that it is a non-issue for port developers. No tickets
> means happy port devs and happy users!
>
> Ken
>
> On 2017-07-03, at 1:56 PM, Stephen J. Butler wrote:
>
> Is there a reason to not use the Apple/FreeBSD Libc versions? I see you
> used the same one they did for memmem and wcsdup.
>
> https://opensource.apple.com/source/Libc/Libc-1158.50.2/
> stdio/FreeBSD/getdelim.c.auto.html
>
> https://opensource.apple.com/source/Libc/Libc-1158.50.2/
> stdio/FreeBSD/getline.c.auto.html
>
> https://opensource.apple.com/source/Libc/Libc-1158.50.2/
> string/FreeBSD/strndup.c.auto.html
>
> https://opensource.apple.com/source/Libc/Libc-1158.50.2/
> string/FreeBSD/strnlen.c.auto.html
>
>
>
>
> On Mon, Jul 3, 2017 at 3:26 PM, Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
>
>> I see a general frustration with the current situation has led things to
>> move along rather quicker than I had originally thought they might.
>>
>> I will never know as much about licensing as you do. I hope this can be
>> worked out to advantage. I notice most of this code is already being pasted
>> in as patches, and it's in the files directory of many ports...
>>
>> Right now this library is a dylib, as you previously recommended. Hope
>> that helps. Will seek out any more liberal implementations. Most of these
>> came for Apple open source, I think, over the past year.
>>
>>
>> K
>>
>>
>> On 2017-07-03, at 1:09 PM, Rainer Müller wrote:
>>
>> > On 2017-07-03 19:07, Ken Cunningham wrote:
>> >> So the last 10 or so tickets in trac seem like they are all for
>> >> basically the same issue - a few missing symbols from libc prior to
>> 10.7.
>> >
>> > Well, I would take this as a reason to just drop support for such an old
>> > OS release... I know, I cannot convince you to do that yet. ;-)
>> >
>> >> It is easy enough, but time consuming, to patch each individual source
>> >> file that is missing the definition (there might be several, also, so
>> >> you might have to do it multiple times in different files).
>> >>
>> >> With this library of these missing functions
>> >> <https://github.com/kencu/snowleopardfixes>, all of them from the
>> Apple
>> >> open source website IIRC, all you need to do is the following in the
>> >> Portfile:
>> >>
>> >> if{${os.platform}eq "darwin"&& ${os.major} < 11} |{ depends_lib-append
>> >> port:snowleopardfixes configure.ldflags-append -lsnowleopardfixes } |
>> >
>> > Taking a quick look at this library, all implementations seem to be
>> > covered by GPL-2+.
>> >
>> > That makes this library not suitable for many ports, as the result after
>> > linking would no longer be distributable. It would be better to use
>> > implementations under a non-copyleft license such BSD, MIT, ISC, etc.
>> >
>> >> It could be better named, perhaps libcfixes, as it applies to 10.4 to
>> >> 10.6, not just SnowLeopard.
>> >
>> > I would not declare theses as "fixes", but rather as "supplements"
>> > providing additional functions not available in libc.
>> >
>> >> Addendum 1
>> >>
>> >> I have a header in there as well to provide the function definitions,
>> >> but that header can cause trouble by bringing in other #defines, and it
>> >> seems that no port actually needs the header. Perhaps the header idea
>> >> can be improved by someone with more knowledge of #include_next, etc,
>> or
>> >> more specific defines.
>> >
>> > I guess you would see compiler warnings about implicit declarations?
>> >
>> > As an example, if the compiler assumes a declaration like
>> >  int strnlen(int, int)
>> > instead of
&g