portmaster, portupgrade, etc

[Adam Weinberger]

> On 5 Oct, 2017, at 9:25, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
> 
> On Thu, Oct 05, 2017 at 05:59:41PM +0300, Konstantin Belousov wrote:
>> On Thu, Oct 05, 2017 at 07:51:16AM -0700, Steve Kargl wrote:
>>> On Thu, Oct 05, 2017 at 11:35:58AM +0300, Konstantin Belousov wrote:
>>>> On Wed, Oct 04, 2017 at 05:27:11PM -0700, Don Lewis wrote:
>>>>>> The system in question is my last i686 laptop, which I 
>>>>>> use for libm development and testing.  Once I cannot use
>>>>>> that laptop (whether hardware failure or inability to 
>>>>>> update the installed ports), I'll stop worrying about a
>>>>>> functional libm on 32-bit hardware.
>>>>> 
>>>>> As an aside, this sort of thing could be done in an i386 VM or maybe an
>>>>> i386 jail on amd64 hardware.
>>>> 
>>>> You do not need even a jail for this. Base cc -m32 works on amd64 for
>>>> long time, and 32bit binaries can be executed from host environment,
>>>> assuming all third-party libs are provided somewhere in the 32bit
>>>> variant.
>>>> 
>>>> The environment with regard to the hardware configuration should be
>>>> identical to modern i386-arch machine with SSE2.  Incompatibilities are
>>>> considered as bugs and are usually fixed fast when reported.
>>> 
>>> Does this required WITH_LIB32=yes in src.conf?
>> Yes, but this is the default.
>> 
>>> 
>>> More concerning is that the FPU on i686 is set-up in npx to
>>> use 53-bit precision instead of 64-bit.  See x86/fpu.h where
>>> there is a large comment and the settings
>>> 
>>> #define __INITIAL_FPUCW__       0x037F
>>> #define __INITIAL_FPUCW_I386__  0x127F
>>> #define __INITIAL_NPXCW__       __INITIAL_FPUCW_I386__
>>> 
>>> Does cc -m32 on amd64 cause the amd64 fpu to act (exactly?) like
>>> and i387?
>> It is not cc -m32.
>> 
>> Kernel sets up x87 FPU differently for 64 and 32bit processes. See
>> ia32_setregs() where pcb is adjusted for 32bit, and r189423.
> 
> Yes, I know the kernel sets up npx on i686.  If one is testing libm
> changes or new code for libm, then cc -m32 will be insufficient in
> testing the behavior one might get from i387 in 53-bit mode as 
> oppose to 64-bit.  This is the reason the macro LD80C exists in
> math_private.h.
> 
> Which brings me back to my i686 laptop with limited resources.
> If portmgr makes it impractical/impossible to easily install ports
> without a sledge hammer, then testing possible future patches to 
> libm will simply skip i686 class hardware.

I'm not clear what role you think portmgr has in this. Portmgr merely brings new features to the ports tree. Portmgr itself is responsible for no build tool other than "make install".

I don't know how many times I need to keep saying this, but portmgr is not killing off portmaster. There is simply nobody developing portmaster anymore, and that is not portmgr's responsibility. There ARE people developing poudriere, and that is why poudriere continues to work with new ports tree features.

# Adam


-- 
Adam Weinberger
adamw at adamw.org
https://www.adamw.org