from:"manphiz"

Update msmtp 1.8.19 and remove from maintainer

2021-12-13 Thread manphiz

Hi,

Please find in the attached diff updates mail/msmtp to 1.8.19.  Also as
my involvement in maintaining this port has become more and more
infrequent it doesn't serve a good example of maintainership so I'm
removing myself as well.

Thanks.

Index: Makefile
===
RCS file: /cvs/ports/mail/msmtp/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- Makefile	8 Jul 2021 10:05:11 -	1.49
+++ Makefile	14 Dec 2021 04:32:36 -
@@ -2,12 +2,10 @@
 
 COMMENT =		SMTP plugin for MUAs
 
-DISTNAME =		msmtp-1.8.15
+DISTNAME =		msmtp-1.8.19
 CATEGORIES =		mail
 
 HOMEPAGE =		https://marlam.de/msmtp/
-
-MAINTAINER =		Xiyue Deng 
 
 # GPLv3+
 PERMIT_PACKAGE =	Yes
Index: distinfo
===
RCS file: /cvs/ports/mail/msmtp/distinfo,v
retrieving revision 1.32
diff -u -p -r1.32 distinfo
--- distinfo	8 Jul 2021 10:05:11 -	1.32
+++ distinfo	14 Dec 2021 04:32:36 -
@@ -1,2 +1,2 @@
-SHA256 (msmtp-1.8.15.tar.xz) = ImXcY56/Lt8waf/+CjvXZ0n4tY9AAdXN6uGYc5SQmc4=
-SIZE (msmtp-1.8.15.tar.xz) = 370736
+SHA256 (msmtp-1.8.19.tar.xz) = NKHhmBF2h02+TuZu4NkQPJCYmqTc3Ehh5N4Fzn5EUms=
+SIZE (msmtp-1.8.19.tar.xz) = 383100


signature.asc
Description: PGP signature

Re: 回复：Error: Libraries in packing-lists in the ports tree and libraries from installed packages don't match

2021-11-12 Thread manphiz

"songzongquan"  writes:

> I installed openbsd7.0 on Loongson2F notebook. Indeed, this is the
> last supported version, and I can't find the compiled package of this
> architecture. So I have to use ports to install the software I want. I
> tried to install the 6.9 version of the compiled package, but it
> didn't work properly.
>

I happen to have the exact machine and has been using OpenBSD sinc 6.5
on it since no other Linux or BSD distribution has good support for the
box.  The base system has definitely been working fine, though it's
package is very lacking because the machine is super slow by today's
standard and the packages may take months to be built and made
available.  So I mainly just build my own packages from ports using dpb
with proot, which takes about a week to get Emacs and dependencies ready
so that I can use Gnus to get mails from the mailing lists.  Here is a
blog[1] that can help you set up the tools.

> According to the FAQ, I should download the - release or - stable ports tree,
>
> But I'm not sure I downloaded the correct version of the port tree.
>
> I from https://cdn.openbsd.org/pub/OpenBSD/7.0/ports.tar.gz Downloaded
> it.

I have been following the these instructions[2], especially under the
section "Using CVS to Get and Update Your Source Trees" which has both
instructions for -current and -stable.

HTH.

[1] https://dataswamp.org/~solene/2021-05-30-openbsd-dpb.html
[2] https://www.openbsd.org/anoncvs.html

>
>
> --
> 发件人：Stefan Hagen 
> 发送时间：2021年11月12日(星期五) 16:05
> 收件人：songzongquan 
> 抄　送：ports 
> 主　题：Re: Error: Libraries in packing-lists in the ports tree and libraries 
> from installed packages don't match
>
> Hello songzongquan,
>
> songzongquan wrote:
>> In your way, I didn't find any useful information. I didn't understand
>> what you said in your last email? What happens to mips64el? But thank
>> you for your reply
>
> Can you provide more information about what you are trying to do?
>
> Which OpenBSD version did you install? I assume 6.9, because I don't 
> see 7.0 mips64el on the mirror.
>
> What ports tree did you download?
>
> It looks like your ports tree does not match the installed packages.
> This should not happen on a -release.
>
> Are you trying to manually compile and update your system to 7.0?
>
> Just out of interest: What is the device you're running OpenBSD on?
>
> Best Regards,
> Stefan
>
>> --
>> 发件人：Stuart Henderson 
>> 发送时间：2021年11月11日(星期四) 18:51
>> 收件人：songzongquan ; ports 
>> 主 题：Re: Error: Libraries in packing-lists in the ports tree and libraries 
>> from installed packages don't match
>> 
>> On 2021/11/11 10:46, Stuart Henderson wrote:
>> > On 2021/11/11 17:09, songzongquan wrote:
>> > > Error: Libraries in packing-lists in the ports tree
>> > >and libraries from installed packages don't match
>> > > --- /tmp/dep_cache.qcDR47LYJ/portstree-python-gdbm-3.8.12   Thu Nov 
>> > > 11 16:54:17 2021
>> > > +++ /tmp/dep_cache.qcDR47LYJ/inst-python-gdbm-3.8.12Thu Nov 11 
>> > > 16:54:18 2021
>> > > @@ -1,3 +1,3 @@
>> > >  -W gdbm.5.1
>> > >  -W pthread.26.1
>> > > --W python3.8.0.0
>> > > +-W python3.8.1.0
>> > > *** Error 1 in /usr/ports/lang/python/3.8 
>> > > (/usr/ports/infrastructure/mk/bsd.port.mk:3441 'wantlib-args': @case 
>> > > X${_DEPENDS_CACHE} in  X) _DE...)
>> > > *** Error 2 in /usr/ports/lang/python/3.8 
>> > > (/usr/ports/infrastructure/mk/bsd.port.mk:2142 
>> > > '/usr/packages/mips64el/all/python-gdbm-3.8.12.tgz')
>> > > *** Error 2 in /usr/ports/lang/python/3.8 
>> > > (/usr/ports/infrastructure/mk/bsd.port.mk:2623 '_internal-package': 
>> > > @case X${_DEPENDS_CACHE} in  X...)
>> > > 
>> > 
>> > See this:
>> > 
>> >  man bsd.port.mk | less "+/Error: Libraries in packing-lists"
>> > 
>> > For what reason are you building from ports? Normally it is recommended
>> > to use packages.
>> > 
>> 
>> Ah, I see, mips64el.


signature.asc
Description: PGP signature

Re: GCC 8.4.0 fails to build on loongson

2021-07-19 Thread manphiz

I've recently upgraded to -current on loongson and retried building GCC
8.4.0 and unfortunately it failed with the same error.  Looks like Clang
miscompiles bootstrapping GCC on mips64el/loongson.  Should I report
this upstream?  Any tips (like system info or logs to include) on filing
the bug?

Thanks.


manp...@gmail.com writes:

> (Adding bugs@ and ports@ back to CC)
>
> On 6/13/21 7:37 PM, Brad Smith wrote:
>> On Thu, May 27, 2021 at 01:27:17AM -0700, manp...@gmail.com wrote:
 Synopsis:  lang/gcc/8 fails to build on loongson
 Category:  ports
 Environment:
>>> System  : OpenBSD 6.9
>>> Details : OpenBSD 6.9 (GENERIC) #78: Thu Apr 22 20:28:58 MDT 2021
>>>  
>>> dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC
>>>
>>> Architecture: OpenBSD.loongson
>>> Machine : loongson
 Description:
>>>  lang/gcc/8 fails to build on loongson
 How-To-Repeat:
>>>  Reproducible on loongson when building using dpb.  Build log is
>>> attached.
 Fix:
>>> No idea.
>>>
>>> dmesg:
>>> OpenBSD 6.9 (GENERIC) #78: Thu Apr 22 20:28:58 MDT 2021
>>>  dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC
>>> real mem = 1073741824 (1024MB)
>>> avail mem = 1052065792 (1003MB)
>>> random: boothowto does not indicate good seed
>>> mainbus0 at root: Lemote Yeeloong
>>> cpu0 at mainbus0: STC Loongson2F CPU 797 MHz, STC Loongson2F FPU
>>> cpu0: cache L1-I 64KB D 64KB 4 way, L2 512KB 4 way
>>> bonito0 at mainbus0: memory and PCI-X controller, rev 1
>>> pci0 at bonito0 bus 0
>>> rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 5, address
>>> 00:23:8b:33:d4:7f
>>> rlphy0 at rl0 phy 0: RTL internal PHY
>>> smfb0 at pci0 dev 8 function 0 "Silicon Motion LynxEM+" rev 0xb0: 1024x600,
>>> 16bpp
>>> wsdisplay0 at smfb0 mux 1: console (std, vt100 emulation)
>>> ohci0 at pci0 dev 9 function 0 "NEC USB" rev 0x44: irq 7, version 1.0
>>> ehci0 at pci0 dev 9 function 1 "NEC USB" rev 0x05: irq 7
>>> usb0 at ehci0: USB revision 2.0
>>> uhub0 at usb0 configuration 1 interface 0 "NEC EHCI root hub" rev 2.00/1.00
>>> addr 1
>>> glxpcib0 at pci0 dev 14 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
>>> 3579545Hz timer, watchdog, gpio, i2c
>>> isa0 at glxpcib0
>>> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
>>> pckbd0 at pckbc0 (kbd slot)
>>> wskbd0 at pckbd0: console keyboard, using wsdisplay0
>>> pms0 at pckbc0 (aux slot)
>>> wsmouse0 at pms0 mux 0
>>> mcclock0 at isa0 port 0x70/2: mc146818 or compatible
>>> ykbec0 at isa0 port 0x381/3
>>> gpio1 at glxpcib0: 32 pins
>>> iic at glxpcib0 not configured
>>> glxclk0 at glxpcib0: clock, prof
>>> pciide0 at pci0 dev 14 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
>>> wired to compatibility, channel 1 wired to compatibility
>>> wd0 at pciide0 channel 0 drive 0: 
>>> wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
>>> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
>>> pciide0: channel 1 ignored (disabled)
>>> auglx0 at pci0 dev 14 function 3 "AMD CS5536 Audio" rev 0x01: isa irq 9,
>>> CS5536 AC97
>>> ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0)
>>> audio0 at auglx0
>>> ohci1 at pci0 dev 14 function 4 "AMD CS5536 USB" rev 0x02: isa irq 11,
>>> version 1.0, legacy support
>>> ehci1 at pci0 dev 14 function 5 "AMD CS5536 USB" rev 0x02: isa irq 11
>>> usb1 at ehci1: USB revision 2.0
>>> uhub1 at usb1 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00
>>> addr 1
>>> usb2 at ohci0: USB revision 1.0
>>> uhub2 at usb2 configuration 1 interface 0 "NEC OHCI root hub" rev 1.00/1.00
>>> addr 1
>>> usb3 at ohci1: USB revision 1.0
>>> uhub3 at usb3 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00
>>> addr 1
>>> apm0 at mainbus0
>>> umass0 at uhub1 port 1 configuration 1 interface 0 "Generic USB2.0-CRW" rev
>>> 2.00/58.87 addr 2
>>> umass0: using SCSI over Bulk-Only
>>> scsibus0 at umass0: 2 targets, initiator 0
>>> sd0 at scsibus0 targ 1 lun 0:  removable
>>> serial.0bda015811417340
>>> urtw0 at uhub1 port 4 configuration 1 interface 0 "Realtek
>>> RTL8187B_WLAN_Adapter" rev 2.00/2.00 addr 3
>>> urtw0: RTL8187B rev E, address 00:17:c4:4d:ea:21
>>> vscsi0 at root
>>> scsibus1 at vscsi0: 256 targets
>>> softraid0 at root
>>> scsibus2 at softraid0: 256 targets
>>> pmon bootpath: bootduid=b0c7a9c3d196767f
>>> root on wd0a (b0c7a9c3d196767f.a) swap on wd0b dump on wd0b
>>>
>>> usbdevs:
>>> Controller /dev/usb0:
>>> addr 01: 1033: NEC, EHCI root hub
>>>  high speed, self powered, config 1, rev 1.00
>>>  driver: uhub0
>>> Controller /dev/usb1:
>>> addr 01: 1022: AMD, EHCI root hub
>>>  high speed, self powered, config 1, rev 1.00
>>>  driver: uhub1
>>> addr 02: 0bda:0158 Generic, USB2.0-CRW
>>>  high speed, power 500 mA, config 1, rev 58.87, iSerial 
>>> 2007111417340
>>>  driver: umass0
>>> addr 03: 0bda:8189 Realtek, RTL8187B_WLAN_Adapter
>>>  high speed, power 500 mA, config 1, rev 2.00, iSerial 0

[manphiz] Re: [Maintainer Update] msmtp -> 1.8.15

2021-07-08 Thread manphiz

Forgot to CC to list.  Forwarding now.

 Start of forwarded message 
From: manphiz 
To: Stuart Henderson 
Subject: Re: [Maintainer Update] msmtp -> 1.8.15
Date: Thu, 08 Jul 2021 23:13:07 -0700

Stuart Henderson  writes:

> On 2021/07/08 00:18, Xiyue Deng wrote:
>> Update msmtp to version 1.8.15
>> 
>> Changelog:
>> https://git.marlam.de/gitweb/?p=msmtp.git;a=blob_plain;f=NEWS;hb=5ff9207795557ab0a843096385f4a7c275a2b06f
>> 
>> Updated dependency requirement with security/gnutls>=3.4 which is
>> required for xoauth2 support.
>> 
>> Tested on Loongson.
>> 
>
> Needs a PLIST sync, and there's not much point listing the gnutls version
> requirement which has been satisfied since 2016. I'll take care of it.

Thanks Stuart!  Please see the updated patch attached.

>
>>  HOMEPAGE =  https://marlam.de/msmtp/
>> @@ -18,7 +18,7 @@ MASTER_SITES = https://marlam.de/msmtp/
>>  EXTRACT_SUFX =  .tar.xz
>>  
>>  LIB_DEPENDS =   devel/libidn2 \
>> -security/gnutls
>> +security/gnutls>=3.4
>>  
>>  SEPARATE_BUILD =Yes
>>  CONFIGURE_STYLE =   gnu
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/mail/msmtp/distinfo,v
>> retrieving revision 1.31
>> diff -u -p -r1.31 distinfo
>> --- distinfo 6 Feb 2020 11:26:10 -   1.31
>> +++ distinfo 8 Jul 2021 07:08:19 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (msmtp-1.8.7.tar.xz) = mlO83CROxbGoBpNOzHdG2dCdtYH1h77fWX6dovSMUfE=
>> -SIZE (msmtp-1.8.7.tar.xz) = 340908
>> +SHA256 (msmtp-1.8.15.tar.xz) = ImXcY56/Lt8waf/+CjvXZ0n4tY9AAdXN6uGYc5SQmc4=
>> +SIZE (msmtp-1.8.15.tar.xz) = 370736

Index: Makefile
===
RCS file: /cvs/ports/mail/msmtp/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile	6 Feb 2020 11:26:10 -	1.48
+++ Makefile	9 Jul 2021 06:08:46 -
@@ -2,7 +2,7 @@
 
 COMMENT =		SMTP plugin for MUAs
 
-DISTNAME =		msmtp-1.8.7
+DISTNAME =		msmtp-1.8.15
 CATEGORIES =		mail
 
 HOMEPAGE =		https://marlam.de/msmtp/
Index: distinfo
===
RCS file: /cvs/ports/mail/msmtp/distinfo,v
retrieving revision 1.31
diff -u -p -r1.31 distinfo
--- distinfo	6 Feb 2020 11:26:10 -	1.31
+++ distinfo	9 Jul 2021 06:08:46 -
@@ -1,2 +1,2 @@
-SHA256 (msmtp-1.8.7.tar.xz) = mlO83CROxbGoBpNOzHdG2dCdtYH1h77fWX6dovSMUfE=
-SIZE (msmtp-1.8.7.tar.xz) = 340908
+SHA256 (msmtp-1.8.15.tar.xz) = ImXcY56/Lt8waf/+CjvXZ0n4tY9AAdXN6uGYc5SQmc4=
+SIZE (msmtp-1.8.15.tar.xz) = 370736
Index: pkg/PLIST
===
RCS file: /cvs/ports/mail/msmtp/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST	7 Jul 2015 01:31:40 -	1.9
+++ pkg/PLIST	9 Jul 2021 06:08:46 -
@@ -1,7 +1,9 @@
 @comment $OpenBSD: PLIST,v 1.9 2015/07/07 01:31:40 gsoares Exp $
 @bin bin/msmtp
+@bin bin/msmtpd
 @info info/msmtp.info
 @man man/man1/msmtp.1
+@man man/man1/msmtpd.1
 share/examples/msmtp/
 share/examples/msmtp/msmtp-enqueue.sh
 share/examples/msmtp/msmtp-listqueue.sh
@@ -13,6 +15,12 @@ share/examples/msmtp/msmtprc-system.exam
 share/examples/msmtp/msmtprc-user.example
 share/examples/msmtp/set_sendmail.sh
 share/locale/de/LC_MESSAGES/msmtp.mo
+share/locale/eo/LC_MESSAGES/msmtp.mo
+share/locale/fr/LC_MESSAGES/msmtp.mo
+share/locale/pt_BR/LC_MESSAGES/msmtp.mo
+share/locale/sr/LC_MESSAGES/msmtp.mo
+share/locale/ta/LC_MESSAGES/msmtp.mo
+share/locale/uk/LC_MESSAGES/msmtp.mo
 share/msmtp/
 share/msmtp/README.msmtpq
 share/msmtp/msmtpqueue/


signature.asc
Description: PGP signature
 End of forwarded message

Re: GCC 8.4.0 fails to build on loongson

2021-06-06 Thread manphiz


On 6/6/21 2:34 AM, Stuart Henderson wrote:

To set expectations approriately: not many developers have mips64el
hardware (not sure if any ports developers do), and it seems few users
do too (only 3 dm...@openbsd.org submissions since 2015 using it).

Also, there are not really many porters who can work on the gcc port.

If you want better support in ports for this hardware, especially in
low-level things like gcc, you're going to need to do most of the work
yourself.


Hi Stuart,

Understood.  I'll try to provide as much info as needed for debugging.



At the bottom of your build log, it says

configure: error: cannot compute sizeof (double)
See `config.log' for more details.

There might possibly be something useful in that file (there will be
multiple config.log files in the build directory, look for the newest).

Maybe the fix will be something simple, maybe not.


Looks like it caused the compiler to ICE when configuring 
mips64el-unknown-openbsd6.9/libgcc.  I'm afraid it may be harder to fix. 
 The relevant logs look like below (full log attached):


---8<---
configure:4273: checking size of double
configure:4278: /usr/ports/pobj/gcc-8.4.0/build-mips64el/./gcc/xgcc 
-B/usr/ports/pobj/gcc-8.4.0/build-mips64el/./gcc/ 
-B/usr/local/mips64el-unknown-openbsd6.9/bin/ 
-B/usr/local/mips64el-unknown-openbsd6.9/lib/ -isystem 
/usr/local/mips64el-unknown-openbsd6.9/include -isystem 
/usr/local/mips64el-unknown-openbsd6.9/sys-include-c -O2 -g 
conftest.c >&5

during RTL pass: dse1
conftest.c: In function 'main':
conftest.c:18:1: internal compiler error: Segmentation fault
 }
 ^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:4278: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| /* none */
| int
| main ()
| {
| static int test_array [1 - 2 * !(((long int) (sizeof (double))) >= 0)];
| test_array [0] = 0
|
|   ;
|   return 0;
| }
---8<---

I tried to recompile the conftest.c by adding "-v" to the compiler flag 
but it didn't seem to provide anything more useful:


---8<---
Reading specs from /usr/ports/pobj/gcc-8.4.0/build-mips64el/./gcc/specs
COLLECT_GCC=/usr/ports/pobj/gcc-8.4.0/build-mips64el/./gcc/xgcc
Target: mips64el-unknown-openbsd6.9
Configured with: /usr/ports/pobj/gcc-8.4.0/gcc-8.4.0/configure --verbose 
--program-transform-name='s,^,e,' --disable-nls --with-system-zlib 
--disable-libmudflap --disable-libgomp --disable-libssp --disable-tls 
--with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t 
--with-gmp=/usr/local --enable-languages=c,c++,fortran,objc 
--disable-libstdcxx-pch --enable-default-ssp --enable-default-pie 
--without-isl --enable-cpp --prefix=/usr/local --sysconfdir=/etc 
--mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var 
--disable-silent-rules --disable-gtk-doc

Thread model: posix
gcc version 8.4.0 (GCC)
COLLECT_GCC_OPTIONS='-B' 
'/usr/ports/pobj/gcc-8.4.0/build-mips64el/./gcc/' '-B' 
'/usr/local/mips64el-unknown-openbsd6.9/bin/' '-B' 
'/usr/local/mips64el-unknown-openbsd6.9/lib/' '-isystem' 
'/usr/local/mips64el-unknown-openbsd6.9/include' '-isystem' 
'/usr/local/mips64el-unknown-openbsd6.9/sys-include' '-v' '-c' '-O2' '-g'
 /usr/ports/pobj/gcc-8.4.0/build-mips64el/./gcc/cc1 -quiet -v -iprefix 
/usr/ports/pobj/gcc-8.4.0/build-mips64el/gcc/../lib/gcc/mips64el-unknown-openbsd6.9/8.4.0/ 
-isystem /usr/ports/pobj/gcc-8.4.0/build-mips64el/./gcc/include -isystem 
/usr/ports/pobj/gcc-8.4.0/build-mips64el/./gcc/include-fixed -isystem 
/usr/local/mips64el-unknown-openbsd6.9/include -isystem 
/usr/local/mips64el-unknown-openbsd6.9/sys-include /tmp/conftest.c 
-quiet -dumpbase conftest.c -auxbase conftest -g -O2 -version -o 
/tmp//ccNNBakd.s

GNU C17 (GCC) version 8.4.0 (mips64el-unknown-openbsd6.9)
compiled by GNU C version OpenBSD Clang 10.0.1 , GMP version 
6.2.1, MPFR version 4.1.0, MPC version 1.1.0, isl version none

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory 
"/usr/local/mips64el-unknown-openbsd6.9/include"
ignoring nonexistent directory 
"/usr/local/mips64el-unknown-openbsd6.9/sys-include"
ignoring nonexistent directory 
"/usr/ports/pobj/gcc-8.4.0/build-mips64el/gcc/../lib/gcc/mips64el-unknown-openbsd6.9/8.4.0/include"
ignoring nonexistent directory 
"/usr/ports/pobj/gcc-8.4.0/build-mips64el/gcc/../lib/gcc/mips64el-unknown-openbsd6.9/8.4.0/include-fixed"
ignoring nonexiste

Re: GCC 8.4.0 fails to build on loongson

2021-06-05 Thread manphiz


Friendly ping.

On 5/27/21 1:27 AM, manp...@gmail.com wrote:

 >Synopsis:    lang/gcc/8 fails to build on loongson
 >Category:    ports
 >Environment:
 System  : OpenBSD 6.9
 Details : OpenBSD 6.9 (GENERIC) #78: Thu Apr 22 20:28:58 MDT 2021
  
dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC


 Architecture: OpenBSD.loongson
 Machine : loongson
 >Description:
     lang/gcc/8 fails to build on loongson
 >How-To-Repeat:
     Reproducible on loongson when building using dpb.  Build log is 
attached.

 >Fix:
 No idea.

dmesg:
OpenBSD 6.9 (GENERIC) #78: Thu Apr 22 20:28:58 MDT 2021
 
dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC

real mem = 1073741824 (1024MB)
avail mem = 1052065792 (1003MB)
random: boothowto does not indicate good seed
mainbus0 at root: Lemote Yeeloong
cpu0 at mainbus0: STC Loongson2F CPU 797 MHz, STC Loongson2F FPU
cpu0: cache L1-I 64KB D 64KB 4 way, L2 512KB 4 way
bonito0 at mainbus0: memory and PCI-X controller, rev 1
pci0 at bonito0 bus 0
rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 5, address 
00:23:8b:33:d4:7f

rlphy0 at rl0 phy 0: RTL internal PHY
smfb0 at pci0 dev 8 function 0 "Silicon Motion LynxEM+" rev 0xb0: 
1024x600, 16bpp

wsdisplay0 at smfb0 mux 1: console (std, vt100 emulation)
ohci0 at pci0 dev 9 function 0 "NEC USB" rev 0x44: irq 7, version 1.0
ehci0 at pci0 dev 9 function 1 "NEC USB" rev 0x05: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "NEC EHCI root hub" rev 
2.00/1.00 addr 1
glxpcib0 at pci0 dev 14 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 
32-bit 3579545Hz timer, watchdog, gpio, i2c

isa0 at glxpcib0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
mcclock0 at isa0 port 0x70/2: mc146818 or compatible
ykbec0 at isa0 port 0x381/3
gpio1 at glxpcib0: 32 pins
iic at glxpcib0 not configured
glxclk0 at glxpcib0: clock, prof
pciide0 at pci0 dev 14 function 2 "AMD CS5536 IDE" rev 0x01: DMA, 
channel 0 wired to compatibility, channel 1 wired to compatibility

wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
auglx0 at pci0 dev 14 function 3 "AMD CS5536 Audio" rev 0x01: isa irq 9, 
CS5536 AC97

ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0)
audio0 at auglx0
ohci1 at pci0 dev 14 function 4 "AMD CS5536 USB" rev 0x02: isa irq 11, 
version 1.0, legacy support

ehci1 at pci0 dev 14 function 5 "AMD CS5536 USB" rev 0x02: isa irq 11
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "AMD EHCI root hub" rev 
2.00/1.00 addr 1

usb2 at ohci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "NEC OHCI root hub" rev 
1.00/1.00 addr 1

usb3 at ohci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "AMD OHCI root hub" rev 
1.00/1.00 addr 1

apm0 at mainbus0
umass0 at uhub1 port 1 configuration 1 interface 0 "Generic USB2.0-CRW" 
rev 2.00/58.87 addr 2

umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  removable 
serial.0bda015811417340
urtw0 at uhub1 port 4 configuration 1 interface 0 "Realtek 
RTL8187B_WLAN_Adapter" rev 2.00/2.00 addr 3

urtw0: RTL8187B rev E, address 00:17:c4:4d:ea:21
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
pmon bootpath: bootduid=b0c7a9c3d196767f
root on wd0a (b0c7a9c3d196767f.a) swap on wd0b dump on wd0b

usbdevs:
Controller /dev/usb0:
addr 01: 1033: NEC, EHCI root hub
  high speed, self powered, config 1, rev 1.00
  driver: uhub0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
  high speed, self powered, config 1, rev 1.00
  driver: uhub1
addr 02: 0bda:0158 Generic, USB2.0-CRW
  high speed, power 500 mA, config 1, rev 58.87, iSerial 
2007111417340

  driver: umass0
addr 03: 0bda:8189 Realtek, RTL8187B_WLAN_Adapter
  high speed, power 500 mA, config 1, rev 2.00, iSerial 00e04c01
  driver: urtw0
Controller /dev/usb2:
addr 01: 1033: NEC, OHCI root hub
  full speed, self powered, config 1, rev 1.00
  driver: uhub2
Controller /dev/usb3:
addr 01: 1022: AMD, OHCI root hub
  full speed, self powered, config 1, rev 1.00
  driver: uhub3




OpenPGP_signature
Description: OpenPGP digital signature

Re: libexecinfo-0.3p2v0 fails to build on loongson

2021-05-26 Thread manphiz




On 5/25/21 6:07 PM, George Koehler wrote:

On Sun, 23 May 2021 07:08:38 -0700
manp...@gmail.com wrote:


cc -O2 -pipe -D__BUILTIN_HACK -Wall -ggdb3 -I/usr/local/include  -MD -MP  
-nostdinc -idirafter /usr/include -c backtrace.c -o backtrace.o
error: return address can be determined only for current frame
error: return address can be determined only for current frame
2 errors generated.


Does this diff help?  It avoids _builtin_frame_address(1), but I don't
know if it would fix your compiler error.

We pass -D__BUILTIN_HACK on mips64* | hppa | sh to disable most of the
backtrace code.  I don't have the hardware to check.

--George

Index: Makefile
===
RCS file: /cvs/ports/devel/libexecinfo/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile3 Jan 2020 15:16:59 -   1.26
+++ Makefile26 May 2021 00:46:48 -
@@ -9,7 +9,7 @@ GH_PROJECT= backtrace
  DISTNAME =${GH_PROJECT}-${V}
  PKGNAME = libexecinfo-$V
  EPOCH =   0
-REVISION = 2
+REVISION = 3
  CATEGORIES =  devel
  
  SHARED_LIBS =	execinfo	2.0

Index: patches/patch-libbacktrace_backtrace_c
===
RCS file: /cvs/ports/devel/libexecinfo/patches/patch-libbacktrace_backtrace_c,v
retrieving revision 1.4
diff -u -p -r1.4 patch-libbacktrace_backtrace_c
--- patches/patch-libbacktrace_backtrace_c  11 Mar 2016 19:46:13 -  
1.4
+++ patches/patch-libbacktrace_backtrace_c  26 May 2021 00:46:48 -
@@ -3,17 +3,22 @@ $OpenBSD: patch-libbacktrace_backtrace_c
  - __builtin_return_address() and __builtin_frame_address()
may not always have a !0 argument.
  
 libbacktrace/backtrace.c.orig	Thu Mar  3 10:15:09 2016

-+++ libbacktrace/backtrace.c   Thu Mar  3 10:15:38 2016
-@@ -65,6 +65,7 @@ bt_create_backtrace(void **buffer, int depth, int flag
+Index: libbacktrace/backtrace.c
+--- libbacktrace/backtrace.c.orig
 libbacktrace/backtrace.c
+@@ -64,7 +64,10 @@ bt_create_backtrace(void **buffer, int depth, int flag
+   do {
/* number of HANDLE_FRAME must match BT_MAX_DEPTH */
switch (i) {
-   HANDLE_FRAME(0, i, addr);
+-  HANDLE_FRAME(0, i, addr);
++  case 0:
++  addr = __builtin_return_address(0);
++  break;
  +#ifndef __BUILTIN_HACK
HANDLE_FRAME(1, i, addr);
HANDLE_FRAME(2, i, addr);
HANDLE_FRAME(3, i, addr);
-@@ -192,6 +193,7 @@ bt_create_backtrace(void **buffer, int depth, int flag
+@@ -192,6 +195,7 @@ bt_create_backtrace(void **buffer, int depth, int flag
HANDLE_FRAME(125, i, addr);
HANDLE_FRAME(126, i, addr);
HANDLE_FRAME(127, i, addr);



Hi George,

You patch works and I have a successfully built libexecinfo now.  Would 
be great to have the patch committed so that we can all benefit from it 
(both HEAD and 6.9 branch)!  Thanks!




OpenPGP_signature
Description: OpenPGP digital signature

Re: libexecinfo-0.3p2v0 fails to build on loongson

2021-05-23 Thread manphiz


On 5/23/21 7:35 AM, Stuart Henderson wrote:

On 2021/05/23 07:08, manp...@gmail.com wrote:

(Please keep me in CC.)


Synopsis:   libexecinfo-0.3p2v0 fails to build on loongson
Category:   
Environment:

System  : OpenBSD 6.9
Details : OpenBSD 6.9 (GENERIC) #78: Thu Apr 22 20:28:58 MDT 2021
 
dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC

Architecture: OpenBSD.loongson
Machine : loongson

Description:

libexecinfo-0.3p2v0 fails to build on loongson.


How-To-Repeat:

Reproducible when building using dpb.  Could apply to other archs as 
well.
Build log attached.


Currently fails on mips64 (octeon/sgi/etc) and mips64el (loongson).

In many cases you can just remove the libexecinfo dependency from whatever
else it is that you're trying to build; most of them are only there
because the other port picks up the execinfo.h header if present at
build time, and aren't actually required to build.



Thanks Stuart.  It's just that too many ports depend on libexecinfo that 
it's hard to track which dependency chain pulls it in.  Is there a 
tracking bug for this issue that we can check for updates?




OpenPGP_signature
Description: OpenPGP digital signature

libexecinfo-0.3p2v0 fails to build on loongson

2021-05-23 Thread manphiz


(Please keep me in CC.)

>Synopsis:   libexecinfo-0.3p2v0 fails to build on loongson
>Category:   
>Environment:
System  : OpenBSD 6.9
Details : OpenBSD 6.9 (GENERIC) #78: Thu Apr 22 20:28:58 MDT 2021
 
dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC

Architecture: OpenBSD.loongson
Machine : loongson
>Description:
libexecinfo-0.3p2v0 fails to build on loongson.

>How-To-Repeat:
	Reproducible when building using dpb.  Could apply to other archs as 
well.  Build log attached.


>Fix:
No idea.


dmesg:
OpenBSD 6.9 (GENERIC) #78: Thu Apr 22 20:28:58 MDT 2021
dera...@loongson.openbsd.org:/usr/src/sys/arch/loongson/compile/GENERIC
real mem = 1073741824 (1024MB)
avail mem = 1052065792 (1003MB)
random: boothowto does not indicate good seed
mainbus0 at root: Lemote Yeeloong
cpu0 at mainbus0: STC Loongson2F CPU 797 MHz, STC Loongson2F FPU
cpu0: cache L1-I 64KB D 64KB 4 way, L2 512KB 4 way
bonito0 at mainbus0: memory and PCI-X controller, rev 1
pci0 at bonito0 bus 0
rl0 at pci0 dev 7 function 0 "Realtek 8139" rev 0x10: irq 5, address 
00:23:8b:33:d4:7f

rlphy0 at rl0 phy 0: RTL internal PHY
smfb0 at pci0 dev 8 function 0 "Silicon Motion LynxEM+" rev 0xb0: 
1024x600, 16bpp

wsdisplay0 at smfb0 mux 1: console (std, vt100 emulation)
ohci0 at pci0 dev 9 function 0 "NEC USB" rev 0x44: irq 7, version 1.0
ehci0 at pci0 dev 9 function 1 "NEC USB" rev 0x05: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "NEC EHCI root hub" rev 
2.00/1.00 addr 1
glxpcib0 at pci0 dev 14 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 
32-bit 3579545Hz timer, watchdog, gpio, i2c

isa0 at glxpcib0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
mcclock0 at isa0 port 0x70/2: mc146818 or compatible
ykbec0 at isa0 port 0x381/3
gpio1 at glxpcib0: 32 pins
iic at glxpcib0 not configured
glxclk0 at glxpcib0: clock, prof
pciide0 at pci0 dev 14 function 2 "AMD CS5536 IDE" rev 0x01: DMA, 
channel 0 wired to compatibility, channel 1 wired to compatibility

wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
auglx0 at pci0 dev 14 function 3 "AMD CS5536 Audio" rev 0x01: isa irq 9, 
CS5536 AC97

ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0)
audio0 at auglx0
ohci1 at pci0 dev 14 function 4 "AMD CS5536 USB" rev 0x02: isa irq 11, 
version 1.0, legacy support

ehci1 at pci0 dev 14 function 5 "AMD CS5536 USB" rev 0x02: isa irq 11
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "AMD EHCI root hub" rev 
2.00/1.00 addr 1

usb2 at ohci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "NEC OHCI root hub" rev 
1.00/1.00 addr 1

usb3 at ohci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "AMD OHCI root hub" rev 
1.00/1.00 addr 1

apm0 at mainbus0
umass0 at uhub1 port 1 configuration 1 interface 0 "Generic USB2.0-CRW" 
rev 2.00/58.87 addr 2

umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  removable 
serial.0bda015811417340
urtw0 at uhub1 port 4 configuration 1 interface 0 "Realtek 
RTL8187B_WLAN_Adapter" rev 2.00/2.00 addr 3

urtw0: RTL8187B rev E, address 00:17:c4:4d:ea:21
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
pmon bootpath: bootduid=b0c7a9c3d196767f
root on wd0a (b0c7a9c3d196767f.a) swap on wd0b dump on wd0b

usbdevs:
Controller /dev/usb0:
addr 01: 1033: NEC, EHCI root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
 high speed, self powered, config 1, rev 1.00
 driver: uhub1
addr 02: 0bda:0158 Generic, USB2.0-CRW
 high speed, power 500 mA, config 1, rev 58.87, iSerial 
2007111417340
 driver: umass0
addr 03: 0bda:8189 Realtek, RTL8187B_WLAN_Adapter
 high speed, power 500 mA, config 1, rev 2.00, iSerial 00e04c01
 driver: urtw0
Controller /dev/usb2:
addr 01: 1033: NEC, OHCI root hub
 full speed, self powered, config 1, rev 1.00
 driver: uhub2
Controller /dev/usb3:
addr 01: 1022: AMD, OHCI root hub
 full speed, self powered, config 1, rev 1.00
 driver: uhub3
>>> Building on localhost under devel/libexecinfo
 DIST = [devel/libexecinfo:backtrace-0.3.tar.gz]
 FULLPKGNAME = libexecinfo-0.3p2v0
distfiles size=4395
>>> Running patch in devel/libexecinfo at 1620339424.62
===> devel/libexecinfo
===>  Verifying specs:  c
===>  found c.96.0
===>  Checking files for libexecinfo-0.3p2v0
`/usr/ports/distfiles/backtrace-0.3.tar.gz' is up to date.
>> (SHA256) backtrace-0.3.tar.gz: OK
===>  Extracting for libexecinf

Re: Fails to build textproc/mupdf on mips64el/loongson

2019-12-05 Thread manphiz

On Thu, Dec 05, 2019 at 06:02:39PM -0500, Brian Callahan wrote:
> Date: Thu, 5 Dec 2019 18:02:39 -0500
> From: Brian Callahan 
> To: Xiyue Deng , ports@openbsd.org, Stuart Henderson
>  
> Subject: Re: Fails to build textproc/mupdf on mips64el/loongson
> User-Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:68.0) Gecko/20100101
>  Thunderbird/68.2.2
> 
> 
> 
> On 2019-12-05 6:00 PM, Brian Callahan wrote:
> > 
> > 
> > On 2019-12-05 5:55 PM, Stuart Henderson wrote:
> > > On 2019/12/04 16:35, Xiyue Deng wrote:
> > > > >     # https://marc.info/?l=openbsd-ports&m=156448467232400&w=2
> > > > >   # possible alignment issue?
> > > > > -MODULES +=    gcc4
> > > > > +MODULES +=    gcc4 lang/clang
> > > > >   MODGCC4_ARCHS =    armv7
> > > > >   MODGCC4_LANGS =    c
> > > > > +MODCLANG_ARCHS = mips64 mips64el
> > > > > +MODCLANG_LANGS = c
> > > > Thanks for the updated patch.  It's definitely clearner this way.
> > > > 
> > > > As it's now using clang from ports, it needs to build lang/clang first
> > > > which may take a few days on this loongson box.  Will report back as
> > > > soon as it's finished.
> > > hmm, actually can you skip the MODULES/MODCLANG_* change above and see
> > > if it works with base-gcc? I doubt it needs to build with a different
> > > compiler, just use the different linker..
> > 
> > base-gcc doesn't support the -fuse-ld= option. What you're suggesting
> > was already tried and unfortunately didn't work.
> > 
> 
> That is to say, it will link the font files with lld but link the code and
> font files together with bfd; the combination didn't work :(
>

Can confirm that I had tried that locally and didn't work as Brian
suggsted.  Will wait for LLVM to be built and report back (currently
~20% done :()

> ~Brian
> 
> > ~Brian
> > 
> > > > Just curious: Is it OK to just whitelist /usr/bin/clang?
> > > I think that would really be a last resort, we try to avoid it in ports.
> > > 
> > > > Also is there
> > > > a plan to add mips64* to base-clang archs?
> > > "when it's ready" :)
> > > 
> > 
> 


signature.asc
Description: PGP signature

Re: Patch from George to fix libnettle build on mips64el (was Fwd: "undefined reference to `__builtin_bswap64'" on mips64el/loongson)

2019-12-04 Thread manphiz

On 12/3/19 10:28 PM, Antoine Jacoutot wrote:
> On Tue, Dec 03, 2019 at 05:58:52PM -0800, manp...@gmail.com wrote:
>> On 12/3/19 6:42 AM, Stuart Henderson wrote:
>>> On 2019/12/03 00:03, manp...@gmail.com wrote:
 Hi Ports maintainers,

 Just to forward George's patch to fix libnettle build on mips64el in
 case it's buried in a misleading title.
>>>
>>> It's best to include the relevant maintainer if you're going to ask about
>>> a port. Sometimes it makes sense to CC ports@ as well but definitely include
>>> the maintainer.
>>>
>>> See "make show=MAINTAINER" or "pkg_info ".
>>>
>>
>> Thanks for the tip Stuart!  I'm adding the maintainer Antoine and CCing
>> George.  The patch is reattached here.
> 
> Looks fine, ok.
> 

Thanks Antoine!  Can you also help commit it (I don't have permission)?

>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/security/libnettle/Makefile,v
>> retrieving revision 1.24
>> diff -u -p -r1.24 Makefile
>> --- Makefile 29 Jun 2019 22:26:25 -  1.24
>> +++ Makefile 30 Nov 2019 20:38:46 -
>> @@ -4,6 +4,7 @@ COMMENT= cryptographic library
>>  
>>  DISTNAME=   nettle-3.5.1
>>  PKGNAME=lib${DISTNAME}
>> +REVISION=   0
>>  
>>  SHARED_LIBS +=  hogweed   3.0 # 6.5
>>  SHARED_LIBS +=  nettle5.0 # 4.5
>> Index: patches/patch-configure
>> ===
>> RCS file: /cvs/ports/security/libnettle/patches/patch-configure,v
>> retrieving revision 1.8
>> diff -u -p -r1.8 patch-configure
>> --- patches/patch-configure  29 Jun 2019 22:26:25 -  1.8
>> +++ patches/patch-configure  30 Nov 2019 20:38:46 -
>> @@ -1,5 +1,8 @@
>>  $OpenBSD: patch-configure,v 1.8 2019/06/29 22:26:25 ajacoutot Exp $
>>  
>> +The test for __builtin_bswap64 must fail if the linker can't find the
>> +symbol.  We need this for base-gcc on little endian, like mips64el.
>> +
>>  Fix relocation errors on (at least) sparc64.
>>  
>>  We don't want extra debug flags in regular builds.
>> @@ -7,6 +10,15 @@ We don't want extra debug flags in regul
>>  Index: configure
>>  --- configure.orig
>>  +++ configure
>> +@@ -6062,7 +6062,7 @@ uint64_t y = __builtin_bswap64(x);
>> +   return 0;
>> + }
>> + _ACEOF
>> +-if ac_fn_c_try_compile "$LINENO"; then :
>> ++if ac_fn_c_try_link "$LINENO"; then :
>> +   nettle_cv_c_builtin_bswap64=yes
>> + else
>> +   nettle_cv_c_builtin_bswap64=no
>>  @@ -6720,6 +6720,7 @@ else
>>  bsdi4.*)CCPIC="-fPIC" ;;
>>  bsdi*)  CCPIC="" ;;
> 
> 
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: Fails to build textproc/mupdf on mips64el/loongson

2019-12-03 Thread manphiz



On 12/3/19 5:05 PM, manp...@gmail.com wrote:
> On 12/1/19 5:24 PM, manp...@gmail.com wrote:
>> Hi Ports maintainer,
>>
>> Hit another problem when trying to build textproc/mupdf, which says
>> failed to link 32-bit and 64-bit code:
>>
>> /usr/bin/ld: build/release/libmupdf.a(Dingbats.cff.o): warning: linking
>> PIC files with non-PIC files
>> /usr/bin/ld: build/release/libmupdf.a(Dingbats.cff.o): linking 32-bit
>> code with 64-bit code
>> /usr/bin/ld: failed to merge target specific data of file
>> build/release/libmupdf.a(Dingbats.cff.o)
>> /usr/bin/ld: build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o): warning:
>> linking PIC files with non-PIC files
>> /usr/bin/ld: build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o): linking
>> 32-bit code with 64-bit code
>> /usr/bin/ld: failed to merge target specific data of file
>> build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o)
>>
>> The full build log is attached.
>>
> 
> With help from Brian, I finally get it built (thanks a lot Brian!)  The
> problem is that the default linker (ld.bfd) cannot handle the font
> archive format well and when linking with fonts and code archive so it
> gives the errors in the log.  ld.lld is required to make this work.
> Also because the linker will be called through compiler, we need to
> explicitly use clang.  The patch is attached.  Please consider refine
> and submit.  Thanks!
> 

Adding maintainer to CC (forgot to do so in previous mail.)



signature.asc
Description: OpenPGP digital signature

Re: Patch from George to fix libnettle build on mips64el (was Fwd: "undefined reference to `__builtin_bswap64'" on mips64el/loongson)

2019-12-03 Thread manphiz

On 12/3/19 6:42 AM, Stuart Henderson wrote:
> On 2019/12/03 00:03, manp...@gmail.com wrote:
>> Hi Ports maintainers,
>>
>> Just to forward George's patch to fix libnettle build on mips64el in
>> case it's buried in a misleading title.
> 
> It's best to include the relevant maintainer if you're going to ask about
> a port. Sometimes it makes sense to CC ports@ as well but definitely include
> the maintainer.
> 
> See "make show=MAINTAINER" or "pkg_info ".
> 

Thanks for the tip Stuart!  I'm adding the maintainer Antoine and CCing
George.  The patch is reattached here.
Index: Makefile
===
RCS file: /cvs/ports/security/libnettle/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile29 Jun 2019 22:26:25 -  1.24
+++ Makefile30 Nov 2019 20:38:46 -
@@ -4,6 +4,7 @@ COMMENT=cryptographic library
 
 DISTNAME=  nettle-3.5.1
 PKGNAME=   lib${DISTNAME}
+REVISION=  0
 
 SHARED_LIBS +=  hogweed   3.0 # 6.5
 SHARED_LIBS +=  nettle5.0 # 4.5
Index: patches/patch-configure
===
RCS file: /cvs/ports/security/libnettle/patches/patch-configure,v
retrieving revision 1.8
diff -u -p -r1.8 patch-configure
--- patches/patch-configure 29 Jun 2019 22:26:25 -  1.8
+++ patches/patch-configure 30 Nov 2019 20:38:46 -
@@ -1,5 +1,8 @@
 $OpenBSD: patch-configure,v 1.8 2019/06/29 22:26:25 ajacoutot Exp $
 
+The test for __builtin_bswap64 must fail if the linker can't find the
+symbol.  We need this for base-gcc on little endian, like mips64el.
+
 Fix relocation errors on (at least) sparc64.
 
 We don't want extra debug flags in regular builds.
@@ -7,6 +10,15 @@ We don't want extra debug flags in regul
 Index: configure
 --- configure.orig
 +++ configure
+@@ -6062,7 +6062,7 @@ uint64_t y = __builtin_bswap64(x);
+   return 0;
+ }
+ _ACEOF
+-if ac_fn_c_try_compile "$LINENO"; then :
++if ac_fn_c_try_link "$LINENO"; then :
+   nettle_cv_c_builtin_bswap64=yes
+ else
+   nettle_cv_c_builtin_bswap64=no
 @@ -6720,6 +6720,7 @@ else
bsdi4.*)CCPIC="-fPIC" ;;
bsdi*)  CCPIC="" ;;


signature.asc
Description: OpenPGP digital signature

Re: Fails to build textproc/mupdf on mips64el/loongson

2019-12-03 Thread manphiz

On 12/1/19 5:24 PM, manp...@gmail.com wrote:
> Hi Ports maintainer,
> 
> Hit another problem when trying to build textproc/mupdf, which says
> failed to link 32-bit and 64-bit code:
> 
> /usr/bin/ld: build/release/libmupdf.a(Dingbats.cff.o): warning: linking
> PIC files with non-PIC files
> /usr/bin/ld: build/release/libmupdf.a(Dingbats.cff.o): linking 32-bit
> code with 64-bit code
> /usr/bin/ld: failed to merge target specific data of file
> build/release/libmupdf.a(Dingbats.cff.o)
> /usr/bin/ld: build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o): warning:
> linking PIC files with non-PIC files
> /usr/bin/ld: build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o): linking
> 32-bit code with 64-bit code
> /usr/bin/ld: failed to merge target specific data of file
> build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o)
> 
> The full build log is attached.
> 

With help from Brian, I finally get it built (thanks a lot Brian!)  The
problem is that the default linker (ld.bfd) cannot handle the font
archive format well and when linking with fonts and code archive so it
gives the errors in the log.  ld.lld is required to make this work.
Also because the linker will be called through compiler, we need to
explicitly use clang.  The patch is attached.  Please consider refine
and submit.  Thanks!
Index: Makefile
===
RCS file: /cvs/ports/textproc/mupdf/Makefile,v
retrieving revision 1.92
diff -u -p -r1.92 Makefile
--- Makefile17 Sep 2019 09:22:51 -  1.92
+++ Makefile4 Dec 2019 01:02:32 -
@@ -53,6 +53,17 @@ MAKE_FLAGS = CC="${CC}" CXX="${CXX}" \
USE_SYSTEM_LIBS=yes \
build=release verbose=yes
 
+# mips64* needs lld to link the font files so clang is required.
+# Neither is in LLD_ARCHS, so need to explicitly declare LLD_EMUL.
+.if ${MACHINE_ARCH} == "mips64" || ${MACHINE_ARCH} == "mips64el"
+MAKE_FLAGS +=  CC="/usr/bin/clang" CXX="/usr/bin/clang++" 
LDFLAGS="-fuse-ld=lld" LD="/usr/bin/ld.lld"
+.  if ${MACHINE_ARCH} == "mips64"
+MAKE_FLAGS +=  LLD_EMUL="-melf64btsmip"
+.  else
+MAKE_FLAGS +=  LLD_EMUL="-melf64ltsmip"
+.  endif
+.endif
+
 FAKE_FLAGS =   prefix=${PREFIX} mandir=${PREFIX}/man
 
 pre-configure:


signature.asc
Description: OpenPGP digital signature

Patch from George to fix libnettle build on mips64el (was Fwd: "undefined reference to `__builtin_bswap64'" on mips64el/loongson)

2019-12-03 Thread manphiz

Hi Ports maintainers,

Just to forward George's patch to fix libnettle build on mips64el in
case it's buried in a misleading title.

Thanks!


 Forwarded Message 
Subject: Re: "undefined reference to `__builtin_bswap64'" on
mips64el/loongson
Date: Sat, 30 Nov 2019 16:26:40 -0500
From: George Koehler 
To: manp...@gmail.com
CC: ports@openbsd.org

On Sat, 30 Nov 2019 01:10:56 -0800
manp...@gmail.com wrote:

> Hi OpenBSD ports maintainers,
> 
> I'm having trouble building security/libnettle on mips64el/loongson
> which is caused by missing symbol of "__builtin_bswap64" when linking.
> It looks like this symbol is introduced since GCC 4.3[1], while mips64el
> ships with GCC 4.2.1.  It's interesting because I can compile with the
> symbol but cannot link.  Would like to hear from the ports maintainers'
> opinion on how to solve this issue?

Bad luck!  libnettle uses __builtin_bswap64 only on little-endian
platforms.  My big-endian powerpc/macppc also uses base-gcc 4.2.1 but
can use the powerpc snapshot package of libnettle.

The configure test for __builtin_bswap64 is wrong.  It is a compile
test, but you got a link error, not a compile error.  Here is a diff
to do a link test.  On my powerpc with base-gcc, the compile test
passed but the link test fails.  The regression tests look good:
"make test" reports "All 98 tests passed", "All 3 tests passed".

For big endian, the test for __builtin_bswap64 should have no effect.
For little endian, the failing test should disable a special case for
block_size == 16 in WRKSRC/ctr.c ctr_crypt().

Does this diff fix the problem on mips64el/longsoon?

Index: Makefile
===
RCS file: /cvs/ports/security/libnettle/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile29 Jun 2019 22:26:25 -  1.24
+++ Makefile30 Nov 2019 20:38:46 -
@@ -4,6 +4,7 @@ COMMENT=cryptographic library
  DISTNAME= nettle-3.5.1
 PKGNAME=   lib${DISTNAME}
+REVISION=  0
  SHARED_LIBS +=  hogweed   3.0 # 6.5
 SHARED_LIBS +=  nettle5.0 # 4.5
Index: patches/patch-configure
===
RCS file: /cvs/ports/security/libnettle/patches/patch-configure,v
retrieving revision 1.8
diff -u -p -r1.8 patch-configure
--- patches/patch-configure 29 Jun 2019 22:26:25 -  1.8
+++ patches/patch-configure 30 Nov 2019 20:38:46 -
@@ -1,5 +1,8 @@
 $OpenBSD: patch-configure,v 1.8 2019/06/29 22:26:25 ajacoutot Exp $
 +The test for __builtin_bswap64 must fail if the linker can't find the
+symbol.  We need this for base-gcc on little endian, like mips64el.
+
 Fix relocation errors on (at least) sparc64.
  We don't want extra debug flags in regular builds.
@@ -7,6 +10,15 @@ We don't want extra debug flags in regul
 Index: configure
 --- configure.orig
 +++ configure
+@@ -6062,7 +6062,7 @@ uint64_t y = __builtin_bswap64(x);
+   return 0;
+ }
+ _ACEOF
+-if ac_fn_c_try_compile "$LINENO"; then :
++if ac_fn_c_try_link "$LINENO"; then :
+   nettle_cv_c_builtin_bswap64=yes
+ else
+   nettle_cv_c_builtin_bswap64=no
 @@ -6720,6 +6720,7 @@ else
bsdi4.*)CCPIC="-fPIC" ;;
bsdi*)  CCPIC="" ;;



signature.asc
Description: OpenPGP digital signature

Re: Fails to build devel/spidermonkey60 on mips64el/loongson

2019-12-01 Thread manphiz

On 12/1/19 10:18 PM, Kurt Mosiejczuk wrote:
> On Mon, Dec 02, 2019 at 01:15:17AM -0500, Brian Callahan wrote:
>> On 2019-12-02 12:48 AM, manp...@gmail.com wrote:
>>> Thanks so much Brian! This patch works flawlessly!
> 
>> Great; in that case, anyone want to give an ok for the patch?
> 
> Looks alright to me and doesn't look to have any impact outside of
> MIPS. 
> 
> ok kmos
> 
> --Kurt
> 

Friendly reminder to include "--disable-ion" for MIPS* as well.  Thanks
Brian again!

Re: Fails to build devel/spidermonkey60 on mips64el/loongson

2019-12-01 Thread manphiz

Thanks so much Brian! This patch works flawlessly!

On 12/1/19 6:45 AM, Brian Callahan wrote:
> Untested, but can you try adding the attached patch? It looks like
> spidermonkey just forgot to copy some defines over for mips. If not I'll
> take a closer look at it.
> 
> ~Brian
> 
> On 2019-12-01 5:14 AM, manp...@gmail.com wrote:
>> Hi Ports maintainers,
>>
>> I'm having trouble to get devel/spidermonkey60 to build on mips64el.
>> The initial problem was the following error:
>>
>> --8<--
>> usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/jit/mips64/LIR-mips64.h:17:45:
>>
>> error: no matching function for call to 'js::jit::LInstructionHelper<1,
>> 1, 0>::LInstructionHelper()'
>>     explicit LUnbox(const LAllocation& input) { setOperand(0, input); }
>> --8<--
>>
>> It turned out that JIT was not well supported on MIPS as suggested in
>> the Debian bug[1], and the solution is to disable JIT on MIPS[2].  I
>> added it to the configure args and get passed this issue.  Probably this
>> patch[7] should be applied.
>>
>> However the second issue is more complicated.  The error message is the
>> following:
>>
>> --8<--
>> /usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:101:26:
>>
>> error: 'ucontext_t' {aka 'struct sigcontext'} has no member named
>> 'sc_rsp'; did you mean 'sc_mask'?
>>   #define RSP_sig(p) ((p)->sc_rsp)
>>    ^~
>> /usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:450:19:
>>
>> note: in expansion of macro 'RSP_sig'
>>   #define SP_sig(p) RSP_sig(p)
>>     ^~~
>> /usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:481:37:
>>
>> note: in expansion of macro 'SP_sig'
>>     return reinterpret_cast(SP_sig(context));
>>   ^~
>> In file included from
>> /usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/js/src/Unified_cpp_js_src41.cpp:2:
>>
>> /usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:
>>
>> In function 'uint8_t* ContextToLR(ucontext_t*)':
>> /usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:451:19:
>>
>> error: 'R31_sig' was not declared in this scope
>>   #define LR_sig(p) R31_sig(p)
>> --8<--
>>
>> It seems that some members are missing from "struct sigcontext".  The
>> relevant code from Firefox can be found at [3], which assumes some
>> members are available on OpenBSD.  However, it turns out they are
>> available for some archs (e.g. AMD64[4]), but it's not for MIPS64[5].
>> The latest version of Firefox provides a more fine-grained check of
>> symbols for OpenBSD archs[6] but still assumes some symbols to be
>> available for all archs which are missing in MIPS64.  And I'm not sure
>> about how this can be handled properly.
>>
>> On the other hand, I think this target is dragged in as an indirect
>> dependency of Emacs because I think it needs gjs and WASM may not be
>> required.  Is there a way to disable compiling the WASM part?
>>
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908486
>> [2]
>> https://salsa.debian.org/gnome-team/mozjs60/blob/debian/master/debian/rules#L42
>>
>> [3]
>> https://hg.mozilla.org/mozilla-central/file/e33efdb3e1517d521deb949de3fcd6d9946ea440/js/src/wasm/WasmSignalHandlers.cpp#l103
>>
>> [4]
>> https://github.com/openbsd/src/blob/b66614995ab119f75167daaa7755b34001836821/sys/arch/amd64/include/signal.h#L54
>>
>> [5]
>> https://github.com/openbsd/src/blob/b66614995ab119f75167daaa7755b34001836821/sys/arch/mips64/include/signal.h#L56
>>
>> [6]
>> https://hg.mozilla.org/mozilla-central/file/8504d70d827261346737af1cbe9b96acf6756b6d/js/src/wasm/WasmSignalHandlers.cpp#l80
>>
>> [7] Patch for disabling JIT on MIPS* archs:
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/devel/spidermonkey60/Makefile,v
>> retrieving revision 1.12
>> diff -u -p -r1.12 Makefile
>> --- Makefile    26 Sep 2019 13:00:21 -  1.12
>> +++ Makefile    1 Dec 2019 10:12:07 -
>> @@ -78,6 +78,12 @@ CONFIGURE_ARGS = --disable-debug \
>>   # /usr/bin/ld.lld: error: undefined symbol:
>> std::__1::basic_ostream
>>> ::operator<<(unsigned long long)
>>   CONFIGURE_ARGS +=  --disable-js-shell
>>
>> +# Build failure on mips64{,el}.  Related bug on Debian:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908486
>> +# error: no matching function for call to
>> 'js::jit::LInstructionHelper<1, 1, 0>::LInstructionHelper()'
>> +.if ${MACHINE_ARCH} == "mips64" || ${MACHINE_ARCH} == "mips64el"
>> +CONFIGURE_ARGS +=  --disable-ion
>> +.endif
>> +
>>   SO_VERSION =   ${LIBmozjs-${MOZILLA_VERSION}_VERSION}
>>   SUBST_VARS +=  SO_VERSION
>>
>> cvs server: Diffing patches
>> cvs server: Diffing pkg
>>
> 



signature.asc
Description: OpenPGP digital signature

Fails to build textproc/mupdf on mips64el/loongson

2019-12-01 Thread manphiz

Hi Ports maintainer,

Hit another problem when trying to build textproc/mupdf, which says
failed to link 32-bit and 64-bit code:

/usr/bin/ld: build/release/libmupdf.a(Dingbats.cff.o): warning: linking
PIC files with non-PIC files
/usr/bin/ld: build/release/libmupdf.a(Dingbats.cff.o): linking 32-bit
code with 64-bit code
/usr/bin/ld: failed to merge target specific data of file
build/release/libmupdf.a(Dingbats.cff.o)
/usr/bin/ld: build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o): warning:
linking PIC files with non-PIC files
/usr/bin/ld: build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o): linking
32-bit code with 64-bit code
/usr/bin/ld: failed to merge target specific data of file
build/release/libmupdf.a(NimbusMonoPS-Bold.cff.o)

The full build log is attached.


mupdf.log.gz
Description: GNU Zip compressed data


signature.asc
Description: OpenPGP digital signature

Fails to build devel/spidermonkey60 on mips64el/loongson

2019-12-01 Thread manphiz

Hi Ports maintainers,

I'm having trouble to get devel/spidermonkey60 to build on mips64el.
The initial problem was the following error:

--8<--
usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/jit/mips64/LIR-mips64.h:17:45:
error: no matching function for call to 'js::jit::LInstructionHelper<1,
1, 0>::LInstructionHelper()'
   explicit LUnbox(const LAllocation& input) { setOperand(0, input); }
--8<--

It turned out that JIT was not well supported on MIPS as suggested in
the Debian bug[1], and the solution is to disable JIT on MIPS[2].  I
added it to the configure args and get passed this issue.  Probably this
patch[7] should be applied.

However the second issue is more complicated.  The error message is the
following:

--8<--
/usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:101:26:
error: 'ucontext_t' {aka 'struct sigcontext'} has no member named
'sc_rsp'; did you mean 'sc_mask'?
 #define RSP_sig(p) ((p)->sc_rsp)
  ^~
/usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:450:19:
note: in expansion of macro 'RSP_sig'
 #define SP_sig(p) RSP_sig(p)
   ^~~
/usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:481:37:
note: in expansion of macro 'SP_sig'
   return reinterpret_cast(SP_sig(context));
 ^~
In file included from
/usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/js/src/Unified_cpp_js_src41.cpp:2:
/usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:
In function 'uint8_t* ContextToLR(ucontext_t*)':
/usr/ports/pobj/spidermonkey-60.8.0/firefox-60.8.0/js/src/wasm/WasmSignalHandlers.cpp:451:19:
error: 'R31_sig' was not declared in this scope
 #define LR_sig(p) R31_sig(p)
--8<--

It seems that some members are missing from "struct sigcontext".  The
relevant code from Firefox can be found at [3], which assumes some
members are available on OpenBSD.  However, it turns out they are
available for some archs (e.g. AMD64[4]), but it's not for MIPS64[5].
The latest version of Firefox provides a more fine-grained check of
symbols for OpenBSD archs[6] but still assumes some symbols to be
available for all archs which are missing in MIPS64.  And I'm not sure
about how this can be handled properly.

On the other hand, I think this target is dragged in as an indirect
dependency of Emacs because I think it needs gjs and WASM may not be
required.  Is there a way to disable compiling the WASM part?


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908486
[2]
https://salsa.debian.org/gnome-team/mozjs60/blob/debian/master/debian/rules#L42
[3]
https://hg.mozilla.org/mozilla-central/file/e33efdb3e1517d521deb949de3fcd6d9946ea440/js/src/wasm/WasmSignalHandlers.cpp#l103
[4]
https://github.com/openbsd/src/blob/b66614995ab119f75167daaa7755b34001836821/sys/arch/amd64/include/signal.h#L54
[5]
https://github.com/openbsd/src/blob/b66614995ab119f75167daaa7755b34001836821/sys/arch/mips64/include/signal.h#L56
[6]
https://hg.mozilla.org/mozilla-central/file/8504d70d827261346737af1cbe9b96acf6756b6d/js/src/wasm/WasmSignalHandlers.cpp#l80
[7] Patch for disabling JIT on MIPS* archs:

Index: Makefile
===
RCS file: /cvs/ports/devel/spidermonkey60/Makefile,v
retrieving revision 1.12
diff -u -p -r1.12 Makefile
--- Makefile26 Sep 2019 13:00:21 -  1.12
+++ Makefile1 Dec 2019 10:12:07 -
@@ -78,6 +78,12 @@ CONFIGURE_ARGS = --disable-debug \
 # /usr/bin/ld.lld: error: undefined symbol:
std::__1::basic_ostream
>::operator<<(unsigned long long)
 CONFIGURE_ARGS +=  --disable-js-shell

+# Build failure on mips64{,el}.  Related bug on Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908486
+# error: no matching function for call to
'js::jit::LInstructionHelper<1, 1, 0>::LInstructionHelper()'
+.if ${MACHINE_ARCH} == "mips64" || ${MACHINE_ARCH} == "mips64el"
+CONFIGURE_ARGS +=  --disable-ion
+.endif
+
 SO_VERSION =   ${LIBmozjs-${MOZILLA_VERSION}_VERSION}
 SUBST_VARS +=  SO_VERSION

cvs server: Diffing patches
cvs server: Diffing pkg



signature.asc
Description: OpenPGP digital signature

Re: "undefined reference to `__builtin_bswap64'" on mips64el/loongson

2019-11-30 Thread manphiz



On 11/30/19 1:26 PM, George Koehler wrote:
> On Sat, 30 Nov 2019 01:10:56 -0800
> manp...@gmail.com wrote:
> 
>> Hi OpenBSD ports maintainers,
>>
>> I'm having trouble building security/libnettle on mips64el/loongson
>> which is caused by missing symbol of "__builtin_bswap64" when linking.
>> It looks like this symbol is introduced since GCC 4.3[1], while mips64el
>> ships with GCC 4.2.1.  It's interesting because I can compile with the
>> symbol but cannot link.  Would like to hear from the ports maintainers'
>> opinion on how to solve this issue?
> 
> Bad luck!  libnettle uses __builtin_bswap64 only on little-endian
> platforms.  My big-endian powerpc/macppc also uses base-gcc 4.2.1 but
> can use the powerpc snapshot package of libnettle.
> 
> The configure test for __builtin_bswap64 is wrong.  It is a compile
> test, but you got a link error, not a compile error.  Here is a diff
> to do a link test.  On my powerpc with base-gcc, the compile test
> passed but the link test fails.  The regression tests look good:
> "make test" reports "All 98 tests passed", "All 3 tests passed".
> 
> For big endian, the test for __builtin_bswap64 should have no effect.
> For little endian, the failing test should disable a special case for
> block_size == 16 in WRKSRC/ctr.c ctr_crypt().
> 
> Does this diff fix the problem on mips64el/longsoon?
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/libnettle/Makefile,v
> retrieving revision 1.24
> diff -u -p -r1.24 Makefile
> --- Makefile  29 Jun 2019 22:26:25 -  1.24
> +++ Makefile  30 Nov 2019 20:38:46 -
> @@ -4,6 +4,7 @@ COMMENT=  cryptographic library
>  
>  DISTNAME=nettle-3.5.1
>  PKGNAME= lib${DISTNAME}
> +REVISION=0
>  
>  SHARED_LIBS +=  hogweed   3.0 # 6.5
>  SHARED_LIBS +=  nettle5.0 # 4.5
> Index: patches/patch-configure
> ===
> RCS file: /cvs/ports/security/libnettle/patches/patch-configure,v
> retrieving revision 1.8
> diff -u -p -r1.8 patch-configure
> --- patches/patch-configure   29 Jun 2019 22:26:25 -  1.8
> +++ patches/patch-configure   30 Nov 2019 20:38:46 -
> @@ -1,5 +1,8 @@
>  $OpenBSD: patch-configure,v 1.8 2019/06/29 22:26:25 ajacoutot Exp $
>  
> +The test for __builtin_bswap64 must fail if the linker can't find the
> +symbol.  We need this for base-gcc on little endian, like mips64el.
> +
>  Fix relocation errors on (at least) sparc64.
>  
>  We don't want extra debug flags in regular builds.
> @@ -7,6 +10,15 @@ We don't want extra debug flags in regul
>  Index: configure
>  --- configure.orig
>  +++ configure
> +@@ -6062,7 +6062,7 @@ uint64_t y = __builtin_bswap64(x);
> +   return 0;
> + }
> + _ACEOF
> +-if ac_fn_c_try_compile "$LINENO"; then :
> ++if ac_fn_c_try_link "$LINENO"; then :
> +   nettle_cv_c_builtin_bswap64=yes
> + else
> +   nettle_cv_c_builtin_bswap64=no
>  @@ -6720,6 +6720,7 @@ else
>   bsdi4.*)CCPIC="-fPIC" ;;
>   bsdi*)  CCPIC="" ;;
> 

Thanks George! This patch works just fine!

BTW, I still wonder why GCC 4.2.1 on OpenBSD has the symbol but cannot
link it?  It's more curious as this builtin should not be available till
GCC 4.3.  Maybe the compiler needs to be fixed to avoid other configure
falsely detect it all together?



signature.asc
Description: OpenPGP digital signature

Re: Packages for 6.6

2019-11-30 Thread manphiz

Thanks Stuart!  Looking forward to it!

On 11/30/19 1:25 AM, Stuart Henderson wrote:
> Yes, probably in a couple of days. For now, use pkg_add -Dsnap.
> 
> -- 
> Sent from a phone, apologies for poor formatting.
> 
> On 30 November 2019 08:55:47 manp...@gmail.com wrote:
> 
>> Hi OpenBSD ports maintainers,
>>
>> It seems that mips64el packages for 6.6 are available according to the
>> OpenBSD 6.6 release page[1] and are available in snapshots tree[2].
>> Will they be copied into the 6.6 packages directories so that we can use
>> it directly?  Thanks!
>>
>>
>> [1] https://www.openbsd.org/66.html
>> [2] https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el/
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

"undefined reference to `__builtin_bswap64'" on mips64el/loongson

2019-11-30 Thread manphiz

Hi OpenBSD ports maintainers,

I'm having trouble building security/libnettle on mips64el/loongson
which is caused by missing symbol of "__builtin_bswap64" when linking.
It looks like this symbol is introduced since GCC 4.3[1], while mips64el
ships with GCC 4.2.1.  It's interesting because I can compile with the
symbol but cannot link.  Would like to hear from the ports maintainers'
opinion on how to solve this issue?

Here are some tests for showing the problem (please let me know if you
need more information):

$ uname -a
OpenBSD yeeloong.lan 6.6 GENERIC#18 loongson
$ gcc -v
Reading specs from /usr/lib/gcc-lib/mips64el-unknown-openbsd6.6/4.2.1/specs
Target: mips64el-unknown-openbsd6.6
Configured with: OpenBSD/mips64el system compiler
Thread model: posix
gcc version 4.2.1 20070719
$ cat test.c
#include 

int
main ()
{

uint64_t x = 17;
uint64_t y = __builtin_bswap64(x);

  ;
  return 0;
}
$ gcc -c test.c
$ gcc test.c
/tmp//ccw1b7KO.o: In function `main':
test.c:(.text+0x2c): undefined reference to `__builtin_bswap64'
test.c:(.text+0x30): undefined reference to `__builtin_bswap64'
collect2: ld returned 1 exit status

[1] http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Other-Builtins.html



signature.asc
Description: OpenPGP digital signature

Packages for 6.6

2019-11-30 Thread manphiz

Hi OpenBSD ports maintainers,

It seems that mips64el packages for 6.6 are available according to the
OpenBSD 6.6 release page[1] and are available in snapshots tree[2].
Will they be copied into the 6.6 packages directories so that we can use
it directly?  Thanks!


[1] https://www.openbsd.org/66.html
[2] https://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/mips64el/



signature.asc
Description: OpenPGP digital signature

Re: aspell/core fails to compile on -current/loongson

2019-01-31 Thread manphiz

Friendly ping.

On 1/27/19 12:18 AM, manp...@gmail.com wrote:
> Hi,
> 
> Trying to compile mutt,-gpgme but stuck on textproc/aspell/core build
> faliure due the following error:
> 
> 8<
> /usr/bin/ld: BFD 2.17 internal error, aborting at
> /usr/src/gnu/usr.bin/binutils-2.17/bfd/elfxx-mips.c line 4797 in
> mips_elf_create_dynamic_relocation
> 
> /usr/bin/ld: Please report this bug.
> 
> collect2: error: ld returned 1 exit status
> 8<
> 
> The full build log is also attached. Please advice on how to fix. Thanks.
> 



signature.asc
Description: OpenPGP digital signature

aspell/core fails to compile on -current/loongson

2019-01-27 Thread manphiz

Hi,

Trying to compile mutt,-gpgme but stuck on textproc/aspell/core build
faliure due the following error:

8<
/usr/bin/ld: BFD 2.17 internal error, aborting at
/usr/src/gnu/usr.bin/binutils-2.17/bfd/elfxx-mips.c line 4797 in
mips_elf_create_dynamic_relocation

/usr/bin/ld: Please report this bug.

collect2: error: ld returned 1 exit status
8<

The full build log is also attached. Please advice on how to fix. Thanks.
>>> Building on localhost under textproc/aspell/core
	 BDEPENDS = [lang/gcc/4.9,-libs;lang/gcc/4.9,-c++;archivers/bzip2;devel/gettext;lang/gcc/4.9]
	 DIST = [textproc/aspell/core:aspell/aspell-0.60.6.1.tar.gz;textproc/aspell/core:aspell/aspell6-en-7.1-0.tar.bz2]
	 FULLPKGNAME = aspell-0.60.6.1p8
	 RDEPENDS = [lang/gcc/4.9,-libs;devel/gettext]
>>> Running clean in textproc/aspell/core at 1548551522
===> textproc/aspell/core
===>  Cleaning for aspell-0.60.6.1p8
(Junk lock obtained for localhost at 1548551523)
>>> Running depends in textproc/aspell/core at 1548551523
/usr/sbin/pkg_add -aI -Drepair bzip2-1.0.6p9 g++-4.9.4p15 gcc-4.9.4p15 gcc-libs-4.9.4p15 gettext-0.19.8.1p3
was: /usr/sbin/pkg_add -aI -Drepair bzip2-1.0.6p9 g++-4.9.4p15 gcc-4.9.4p15 gcc-libs-4.9.4p15 gettext-0.19.8.1p3
/usr/sbin/pkg_add -aI -Drepair bzip2-1.0.6p9 g++-4.9.4p15 gcc-4.9.4p15 gcc-libs-4.9.4p15 gettext-0.19.8.1p3
>>> Running show-prepare-results in textproc/aspell/core at 1548551529
===> textproc/aspell/core
===> aspell-0.60.6.1p8 depends on: gcc->=4.9,<4.10 -> gcc-4.9.4p15
===> aspell-0.60.6.1p8 depends on: g++->=4.9,<4.10 -> g++-4.9.4p15
===> aspell-0.60.6.1p8 depends on: bzip2-* -> bzip2-1.0.6p9
===> aspell-0.60.6.1p8 depends on: gettext-* -> gettext-0.19.8.1p3
===> aspell-0.60.6.1p8 depends on: gcc-libs->=4.9,<4.10 -> gcc-libs-4.9.4p15
===>  Verifying specs:  c iconv intl m ncursesw pthread estdc++>=17 pthread estdc++>=17
===>  found c.93.0 iconv.6.0 intl.6.0 m.10.1 ncursesw.14.0 pthread.25.1 estdc++.17.1
bzip2-1.0.6p9
g++-4.9.4p15
gcc-4.9.4p15
gcc-libs-4.9.4p15
gettext-0.19.8.1p3
(Junk lock released for localhost at 1548551538)
distfiles size=2053523
>>> Running patch in textproc/aspell/core at 1548551538
===> textproc/aspell/core
===>  Checking files for aspell-0.60.6.1p8
`/usr/ports/distfiles/aspell/aspell-0.60.6.1.tar.gz' is up to date.
`/usr/ports/distfiles/aspell/aspell6-en-7.1-0.tar.bz2' is up to date.
>> (SHA256) aspell/aspell-0.60.6.1.tar.gz: OK
>> (SHA256) aspell/aspell6-en-7.1-0.tar.bz2: OK
===>  Extracting for aspell-0.60.6.1p8
===>  Patching for aspell-0.60.6.1p8
===>   Applying OpenBSD patch patch-Makefile_in
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-Makefile_in,v 1.4 2012/01/17 10:59:27 ajacoutot Exp $
|--- Makefile.in.orig	Mon Jul  4 10:58:49 2011
|+++ Makefile.in	Tue Jan 17 10:55:18 2012
--
Patching file Makefile.in using Plan A...
Hunk #1 succeeded at 482.
done
===>   Applying OpenBSD patch patch-common_cache-t_hpp
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-common_cache-t_hpp,v 1.1 2018/11/15 21:12:45 bcallah Exp $
|
|Fix segfault when building dictionaries on macppc
|see https://github.com/GNUAspell/aspell/pull/532
|
|Index: common/cache-t.hpp
|--- common/cache-t.hpp.orig
|+++ common/cache-t.hpp
--
Patching file common/cache-t.hpp using Plan A...
Hunk #1 succeeded at 16.
done
===>   Applying OpenBSD patch patch-common_cache_cpp
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-common_cache_cpp,v 1.1 2018/11/15 21:12:45 bcallah Exp $
|
|Fix segfaults while building dictionaries on macppc
|see https://github.com/GNUAspell/aspell/pull/532
|
|Index: common/cache.cpp
|--- common/cache.cpp.orig
|+++ common/cache.cpp
--
Patching file common/cache.cpp using Plan A...
Hunk #1 succeeded at 5.
Hunk #2 succeeded at 70.
Hunk #3 succeeded at 80.
done
===>   Applying OpenBSD patch patch-common_lock_hpp
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-common_lock_hpp,v 1.1 2012/01/17 10:59:27 ajacoutot Exp $
|
|common/lock.hpp:63: error: 'NULL' was not declared in this scope
|
|--- common/lock.hpp.orig	Tue Jan 17 11:20:03 2012
|+++ common/lock.hpp	Tue Jan 17 11:20:13 2012
--
Patching file common/lock.hpp using Plan A...
Hunk #1 succeeded at 16.
done
===>   Applying OpenBSD patch patch-configure
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-configure,v 1.7 2017/04/17 21:05:21 sthen Exp $
|--- configure.orig	Mon Jul  4 09:58:50 2011
|+++ configure	Mon Apr 17 22:05:04 2017
--
Patching file configure using Plan A...
Hunk #1 succeeded at 2645.
Hunk #2 succeeded at 20216.
done
===>   Applying OpenBSD patch

Using clang from base install instead of from ports on loongson-current

2019-01-13 Thread manphiz

Hi,

Since loongson on current now provides llvm/clang, is it possible to
prefer this over devel/llvm from ports when building ports?



signature.asc
Description: OpenPGP digital signature

Re: librsvg fails to download on 6.4-release/stable

2018-12-06 Thread manphiz



On 12/5/18 4:14 AM, Stuart Henderson wrote:
> On 2018/12/05 00:29, manp...@gmail.com wrote:
>> Thanks Antoine! Can you also apply the fix to stable, please?
> 
> It is in stable already:
> 
> Date: 2018/12/02 11:20:54
> Author: ajacoutot
> Branch: OPENBSD_6_4
> Tag: (none)
> Log:
> Override MASTER_SITES provided by the gnome MODULE because we are
> fetching from 2 different URLs.
> Should unbreak make fetch on a clean system.
> 
> issue reported by manphiz at gmail dot com
> 
> Members:
> Makefile:1.138.2.1->1.138.2.2
> 

Indeed, I seemed to have mixed up the repo update.  Thanks Stuart!



signature.asc
Description: OpenPGP digital signature

Re: librsvg fails to download on 6.4-release/stable

2018-12-05 Thread manphiz

Thanks Antoine! Can you also apply the fix to stable, please?


On 12/2/18 3:21 AM, Antoine Jacoutot wrote:
> On Sun, Dec 02, 2018 at 03:07:28AM -0800, manp...@gmail.com wrote:
>> Hi ports,
>>
>> It seems librsvg fails to download due to wrong URL.  Relevant fetch bad
>> log is included below.  It looks like it is using the old version path
>> for stable version package.  I'm not familiar how ports system handles
>> gnome related URL and it seems the -current version doesn't touch this
>> issue either.  Any suggestion is appreciated.
> 
> Fixed. Thanks for the report.
> 
>> $ grep librsvg bad.log
>> https://ftp.acc.umu.se/pub/GNOME/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> https://ftp.gnome.org/pub/GNOME/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> https://ftp1.nluug.nl/windowing/gnome/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> https://mirrors.ustc.edu.cn/gnomesources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> http://ftp.belnet.be/ftp.gnome.org/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> http://ftp.df.lth.se/pub/gnome/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> ftp://ftp.cse.buffalo.edu/pub/Gnome/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> ftp://ftp.nara.wide.ad.jp/pub/X11/GNOME/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> http://mirror.nbtelecom.com.br/gnome/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
>> https://ftp.openbsd.org/pub/OpenBSD/distfiles/librsvg-2.44.7.tar.xz
>> https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/librsvg-2.44.7.tar.xz
>> https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/librsvg-2.44.7.tar.xz
>>
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

librsvg fails to download on 6.4-release/stable

2018-12-02 Thread manphiz

Hi ports,

It seems librsvg fails to download due to wrong URL.  Relevant fetch bad
log is included below.  It looks like it is using the old version path
for stable version package.  I'm not familiar how ports system handles
gnome related URL and it seems the -current version doesn't touch this
issue either.  Any suggestion is appreciated.


$ grep librsvg bad.log
https://ftp.acc.umu.se/pub/GNOME/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
https://ftp.gnome.org/pub/GNOME/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
https://ftp1.nluug.nl/windowing/gnome/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
https://mirrors.ustc.edu.cn/gnomesources/librsvg/2.40/librsvg-2.44.7.tar.xz
http://ftp.belnet.be/ftp.gnome.org/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
http://ftp.df.lth.se/pub/gnome/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
ftp://ftp.cse.buffalo.edu/pub/Gnome/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
ftp://ftp.nara.wide.ad.jp/pub/X11/GNOME/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
http://mirror.nbtelecom.com.br/gnome/sources/librsvg/2.40/librsvg-2.44.7.tar.xz
https://ftp.openbsd.org/pub/OpenBSD/distfiles/librsvg-2.44.7.tar.xz
https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/librsvg-2.44.7.tar.xz
https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/librsvg-2.44.7.tar.xz



signature.asc
Description: OpenPGP digital signature

Re: Fix libtorrent-rasterbar for gcc 4.9 on -rOPENBSD_6_3 (tested on OpenBSD/Loongson)

2018-04-26 Thread manphiz


Hi,

Emergent fix below.

On 4/26/18 4:17 AM, manp...@gmail.com wrote:

Hi,

On 4/23/18 10:32 PM, manp...@gmail.com wrote:

Hi Stuart,

On 4/23/18 10:48 AM, Stuart Henderson wrote:

On 2018/04/22 15:54, manp...@gmail.com wrote:

On 4/22/18 4:39 AM, manp...@gmail.com wrote:

On 4/15/18 1:25 PM, manp...@gmail.com wrote:

The patch attached fixes building libtorrent-rasterbar on
OpenBSD/Loongson for -rOPENBSD_6_3. It added several missing
includes, added "-std=gnu++14" to CXXFLAGS as it is now default for
newer compiler and the code uses those new features, and another
patch from -current. I'm not sure whether this is the correct way to
update ports for a -stable branch so let me know.

Thanks.


It seems that there is another problem with the setup.py of python
binding that relies on existence of environment variable CXX to be
defined, otherwise it will use "cc" instead of "c++" to build the
binding, which then lead to another problem: the main library would be
built using C++14 that enabled using std::chrono, while the bindings
would not and used boost::chrono instead, and the bindings will 
fail to

load due to missing symbols (actually symbol mismatch). The fix is to
define CXX=c++ in Makefile.am of python binding.

The revised patch against -rOPENBSD_6_3 is attached.


And it turns out it's a bad idea to patch configure.ac and 
Makefile.am which
will require "autoreconf". Attaching the patch dropping those parts. 
1.1.7
on -current has similar issue and I'll provide a separate patch and 
also try

to incorporate upstream.


No loongson here so I can't test any of this, but a few things:

- we work on -current primarily, sometimes things can be backported 
but if

this is broken on -current at the moment, that needs fixing first



Agreed.

- compilers should come from the environment rather than hardcoded, 
maybe

try something like:

MAKE_ENV =  CC="${CC}" CXX="${CXX}"
CXXFLAGS += --std=gnu++14



I'm currently working with upstream to incorporate those patches as 
well. Once the patches are incorporated I'll backport them to -current 
and then -stable.


This is the corresponding patch for -stable similar to the one against 
-current in my other mail[1].


[1] https://marc.info/?l=openbsd-ports&m=152474002010011&w=2


Sorry my previous patch was missing a line. This revised patch should 
work and attached.
diff -Naur Makefile Makefile
--- MakefileWed Feb  7 22:30:34 2018
+++ MakefileThu Apr 26 03:58:27 2018
@@ -3,6 +3,7 @@
 COMMENT =  C++ library implementing a BitTorrent client
 
 MODPY_EGG_VERSION =1.1.6
+REVISION = 0
 DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
 
 SHARED_LIBS += torrent-rasterbar 0.0   # 9.0.0
@@ -36,7 +37,9 @@
--with-libiconv
 CONFIGURE_ENV +=   CPPFLAGS="-Wno-deprecated-declarations \
  -Wno-macro-redefined \
- -pthread"
+ -pthread" \
+   PYTHON_CXXFLAGS="${PYTHON_CXXFLAGS} -std=gnu++14"
+MAKE_ENV = CC=${CC} CXX=${CXX}
+CXXFLAGS +=-std=gnu++14
 
 .ifdef DEBUG
 CONFIGURE_ARGS +=  --enable-debug
diff -Naur patches/patch-include_libtorrent_aux__session_interface_hpp 
patches/patch-include_libtorrent_aux__session_interface_hpp
--- patches/patch-include_libtorrent_aux__session_interface_hpp Wed Dec 31 
16:00:00 1969
+++ patches/patch-include_libtorrent_aux__session_interface_hpp Thu Apr 26 
03:56:01 2018
@@ -0,0 +1,14 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- include/libtorrent/aux_/session_interface.hpp.orig
 include/libtorrent/aux_/session_interface.hpp
+@@ -52,6 +52,7 @@ POSSIBILITY OF SUCH DAMAGE.
+ 
+ #ifndef TORRENT_DISABLE_LOGGING
+ #include 
++#include  // for va_list
+ #endif
+ 
+ #ifdef TORRENT_USE_OPENSSL
+
diff -Naur patches/patch-src_disk_io_thread_cpp 
patches/patch-src_disk_io_thread_cpp
--- patches/patch-src_disk_io_thread_cppWed Dec 31 16:00:00 1969
+++ patches/patch-src_disk_io_thread_cppThu Apr 26 03:56:01 2018
@@ -0,0 +1,13 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- src/disk_io_thread.cpp.orig
 src/disk_io_thread.cpp
+@@ -62,6 +62,7 @@ POSSIBILITY OF SUCH DAMAGE.
+ #if __cplusplus >= 201103L || defined __clang__
+ 
+ #if DEBUG_DISK_THREAD
++#include  // for va_list
+ #define DLOG(...) debug_log(__VA_ARGS__)
+ #else
+ #define DLOG(...) do {} while(false)
diff -Naur patches/patch-src_kademlia_dht_tracker_cpp 
patches/patch-src_kademlia_dht_tracker_cpp
--- patches/patch-src_kademlia_dht_tracker_cpp  Wed Dec 31 16:00:00 1969
+++ patches/patch-src_kademlia_dht_tracker_cpp  Thu Apr 26 03:56:01 2018
@@ -0,0 +1,18 @@
+$OpenBSD: patch-src_kademlia_dht_tracker_cpp,v 1.1 2018/04/12 04:40:41 bentley 
Exp $
+
+https://github.com/arvidn/libtorrent/pull/2931
+
+Index: src/kademlia/dht_tracker.cpp
+--- src/kademlia/dht_tracker.cpp.orig
 src/kade

Re: Fix libtorrent-rasterbar for gcc 4.9 on -rOPENBSD_6_3 (tested on OpenBSD/Loongson)

2018-04-26 Thread manphiz


Hi,

On 4/23/18 10:32 PM, manp...@gmail.com wrote:

Hi Stuart,

On 4/23/18 10:48 AM, Stuart Henderson wrote:

On 2018/04/22 15:54, manp...@gmail.com wrote:

On 4/22/18 4:39 AM, manp...@gmail.com wrote:

On 4/15/18 1:25 PM, manp...@gmail.com wrote:

The patch attached fixes building libtorrent-rasterbar on
OpenBSD/Loongson for -rOPENBSD_6_3. It added several missing
includes, added "-std=gnu++14" to CXXFLAGS as it is now default for
newer compiler and the code uses those new features, and another
patch from -current. I'm not sure whether this is the correct way to
update ports for a -stable branch so let me know.

Thanks.


It seems that there is another problem with the setup.py of python
binding that relies on existence of environment variable CXX to be
defined, otherwise it will use "cc" instead of "c++" to build the
binding, which then lead to another problem: the main library would be
built using C++14 that enabled using std::chrono, while the bindings
would not and used boost::chrono instead, and the bindings will fail to
load due to missing symbols (actually symbol mismatch). The fix is to
define CXX=c++ in Makefile.am of python binding.

The revised patch against -rOPENBSD_6_3 is attached.


And it turns out it's a bad idea to patch configure.ac and 
Makefile.am which
will require "autoreconf". Attaching the patch dropping those parts. 
1.1.7
on -current has similar issue and I'll provide a separate patch and 
also try

to incorporate upstream.


No loongson here so I can't test any of this, but a few things:

- we work on -current primarily, sometimes things can be backported 
but if

this is broken on -current at the moment, that needs fixing first



Agreed.


- compilers should come from the environment rather than hardcoded, maybe
try something like:

MAKE_ENV =  CC="${CC}" CXX="${CXX}"
CXXFLAGS += --std=gnu++14



I'm currently working with upstream to incorporate those patches as 
well. Once the patches are incorporated I'll backport them to -current 
and then -stable.


This is the corresponding patch for -stable similar to the one against 
-current in my other mail[1].


[1] https://marc.info/?l=openbsd-ports&m=152474002010011&w=2
diff -Naur Makefile Makefile
--- MakefileWed Feb  7 22:30:34 2018
+++ MakefileThu Apr 26 03:58:27 2018
@@ -3,6 +3,7 @@
 COMMENT =  C++ library implementing a BitTorrent client
 
 MODPY_EGG_VERSION =1.1.6
+REVISION = 0
 DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
 
 SHARED_LIBS += torrent-rasterbar 0.0   # 9.0.0
@@ -36,7 +37,9 @@
--with-libiconv
 CONFIGURE_ENV +=   CPPFLAGS="-Wno-deprecated-declarations \
  -Wno-macro-redefined \
- -pthread"
+ -pthread" \
+   PYTHON_CXXFLAGS="${PYTHON_CXXFLAGS} -std=gnu++14"
+MAKE_ENV = CC=${CC} CXX=${CXX}
 
 .ifdef DEBUG
 CONFIGURE_ARGS +=  --enable-debug
diff -Naur patches/patch-include_libtorrent_aux__session_interface_hpp 
patches/patch-include_libtorrent_aux__session_interface_hpp
--- patches/patch-include_libtorrent_aux__session_interface_hpp Wed Dec 31 
16:00:00 1969
+++ patches/patch-include_libtorrent_aux__session_interface_hpp Thu Apr 26 
03:56:01 2018
@@ -0,0 +1,14 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- include/libtorrent/aux_/session_interface.hpp.orig
 include/libtorrent/aux_/session_interface.hpp
+@@ -52,6 +52,7 @@ POSSIBILITY OF SUCH DAMAGE.
+ 
+ #ifndef TORRENT_DISABLE_LOGGING
+ #include 
++#include  // for va_list
+ #endif
+ 
+ #ifdef TORRENT_USE_OPENSSL
+
diff -Naur patches/patch-src_disk_io_thread_cpp 
patches/patch-src_disk_io_thread_cpp
--- patches/patch-src_disk_io_thread_cppWed Dec 31 16:00:00 1969
+++ patches/patch-src_disk_io_thread_cppThu Apr 26 03:56:01 2018
@@ -0,0 +1,13 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- src/disk_io_thread.cpp.orig
 src/disk_io_thread.cpp
+@@ -62,6 +62,7 @@ POSSIBILITY OF SUCH DAMAGE.
+ #if __cplusplus >= 201103L || defined __clang__
+ 
+ #if DEBUG_DISK_THREAD
++#include  // for va_list
+ #define DLOG(...) debug_log(__VA_ARGS__)
+ #else
+ #define DLOG(...) do {} while(false)
diff -Naur patches/patch-src_kademlia_dht_tracker_cpp 
patches/patch-src_kademlia_dht_tracker_cpp
--- patches/patch-src_kademlia_dht_tracker_cpp  Wed Dec 31 16:00:00 1969
+++ patches/patch-src_kademlia_dht_tracker_cpp  Thu Apr 26 03:56:01 2018
@@ -0,0 +1,18 @@
+$OpenBSD: patch-src_kademlia_dht_tracker_cpp,v 1.1 2018/04/12 04:40:41 bentley 
Exp $
+
+https://github.com/arvidn/libtorrent/pull/2931
+
+Index: src/kademlia/dht_tracker.cpp
+--- src/kademlia/dht_tracker.cpp.orig
 src/kademlia/dht_tracker.cpp
+@@ -224,7 +224,9 @@ namespace libtorrent { namespace dht
+   void dht_tracker::get_peers(sha1_hash const& ih
+   , boost::function const&)> f)
+   {
+-

Re: [loongson fix] net/libtorrent-rasterbar -current

2018-04-26 Thread manphiz


On 4/26/18 3:52 AM, manp...@gmail.com wrote:
The attached patch fixes net/libtorrent-rasterbar -current building on 
Loongson. The patch contains two parts:


* Missing include of . This is already applied upstream and 
should ship with next point release.

(https://github.com/arvidn/libtorrent/pull/2965)

* Require "-std=c++0x" when building against boost 1.66+ due to new 
interfaces in boost::asio.




My previous patch was not relative to `pwd`. Should be fixed in new patch.
diff --git net/libtorrent-rasterbar/Makefile net/libtorrent-rasterbar/Makefile
index 594a530c97c..d19b28ba9d8 100644
--- net/libtorrent-rasterbar/Makefile
+++ net/libtorrent-rasterbar/Makefile
@@ -3,6 +3,7 @@
 COMMENT =  C++ library implementing a BitTorrent client
 
 MODPY_EGG_VERSION =1.1.7
+REVISION = 0
 DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
 
 SHARED_LIBS += torrent-rasterbar 1.0   # 9.0.0
@@ -36,7 +37,10 @@ CONFIGURE_ARGS = --enable-python-binding \
--with-libiconv
 CONFIGURE_ENV +=   CPPFLAGS="-Wno-deprecated-declarations \
  -Wno-macro-redefined \
- -pthread"
+ -pthread" \
+   PYTHON_CXXFLAGS="${PYTHON_CXXFLAGS} -std=gnu++14"
+MAKE_ENV = CC=${CC} CXX=${CXX}
+CXXFLAGS +=-std=gnu++14
 
 .ifdef DEBUG
 CONFIGURE_ARGS +=  --enable-debug
diff --git 
net/libtorrent-rasterbar/patches/patch-include_libtorrent_aux__session_interface_hpp
 
net/libtorrent-rasterbar/patches/patch-include_libtorrent_aux__session_interface_hpp
new file mode 100644
index 000..8627fddabc0
--- /dev/null
+++ 
net/libtorrent-rasterbar/patches/patch-include_libtorrent_aux__session_interface_hpp
@@ -0,0 +1,14 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- include/libtorrent/aux_/session_interface.hpp.orig
 include/libtorrent/aux_/session_interface.hpp
+@@ -52,6 +52,7 @@ POSSIBILITY OF SUCH DAMAGE.
+ 
+ #ifndef TORRENT_DISABLE_LOGGING
+ #include 
++#include  // for va_list
+ #endif
+ 
+ #ifdef TORRENT_USE_OPENSSL
+
diff --git net/libtorrent-rasterbar/patches/patch-src_disk_io_thread_cpp 
net/libtorrent-rasterbar/patches/patch-src_disk_io_thread_cpp
new file mode 100644
index 000..602071af876
--- /dev/null
+++ net/libtorrent-rasterbar/patches/patch-src_disk_io_thread_cpp
@@ -0,0 +1,13 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- src/disk_io_thread.cpp.orig
 src/disk_io_thread.cpp
+@@ -62,6 +62,7 @@ POSSIBILITY OF SUCH DAMAGE.
+ #if __cplusplus >= 201103L || defined __clang__
+ 
+ #if DEBUG_DISK_THREAD
++#include  // for va_list
+ #define DLOG(...) debug_log(__VA_ARGS__)
+ #else
+ #define DLOG(...) do {} while(false)
diff --git net/libtorrent-rasterbar/patches/patch-src_session_impl_cpp 
net/libtorrent-rasterbar/patches/patch-src_session_impl_cpp
new file mode 100644
index 000..f595740b7a1
--- /dev/null
+++ net/libtorrent-rasterbar/patches/patch-src_session_impl_cpp
@@ -0,0 +1,14 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- src/session_impl.cpp.orig
 src/session_impl.cpp
+@@ -107,6 +107,8 @@ POSSIBILITY OF SUCH DAMAGE.
+ // for logging stat layout
+ #include "libtorrent/stat.hpp"
+ 
++#include  // for va_list
++
+ // for logging the size of DHT structures
+ #ifndef TORRENT_DISABLE_DHT
+ #include

[loongson fix] net/libtorrent-rasterbar -current

2018-04-26 Thread manphiz

The attached patch fixes net/libtorrent-rasterbar -current building on 
Loongson. The patch contains two parts:


* Missing include of . This is already applied upstream and 
should ship with next point release.

(https://github.com/arvidn/libtorrent/pull/2965)

* Require "-std=c++0x" when building against boost 1.66+ due to new 
interfaces in boost::asio.


diff --git a/net/libtorrent-rasterbar/Makefile 
b/net/libtorrent-rasterbar/Makefile
index 594a530c97c..d19b28ba9d8 100644
--- a/net/libtorrent-rasterbar/Makefile
+++ b/net/libtorrent-rasterbar/Makefile
@@ -3,6 +3,7 @@
 COMMENT =  C++ library implementing a BitTorrent client
 
 MODPY_EGG_VERSION =1.1.7
+REVISION = 0
 DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
 
 SHARED_LIBS += torrent-rasterbar 1.0   # 9.0.0
@@ -36,7 +37,10 @@ CONFIGURE_ARGS = --enable-python-binding \
--with-libiconv
 CONFIGURE_ENV +=   CPPFLAGS="-Wno-deprecated-declarations \
  -Wno-macro-redefined \
- -pthread"
+ -pthread" \
+   PYTHON_CXXFLAGS="${PYTHON_CXXFLAGS} -std=gnu++14"
+MAKE_ENV = CC=${CC} CXX=${CXX}
+CXXFLAGS +=-std=gnu++14
 
 .ifdef DEBUG
 CONFIGURE_ARGS +=  --enable-debug
diff --git 
a/net/libtorrent-rasterbar/patches/patch-include_libtorrent_aux__session_interface_hpp
 
b/net/libtorrent-rasterbar/patches/patch-include_libtorrent_aux__session_interface_hpp
new file mode 100644
index 000..8627fddabc0
--- /dev/null
+++ 
b/net/libtorrent-rasterbar/patches/patch-include_libtorrent_aux__session_interface_hpp
@@ -0,0 +1,14 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- include/libtorrent/aux_/session_interface.hpp.orig
 include/libtorrent/aux_/session_interface.hpp
+@@ -52,6 +52,7 @@ POSSIBILITY OF SUCH DAMAGE.
+ 
+ #ifndef TORRENT_DISABLE_LOGGING
+ #include 
++#include  // for va_list
+ #endif
+ 
+ #ifdef TORRENT_USE_OPENSSL
+
diff --git a/net/libtorrent-rasterbar/patches/patch-src_disk_io_thread_cpp 
b/net/libtorrent-rasterbar/patches/patch-src_disk_io_thread_cpp
new file mode 100644
index 000..602071af876
--- /dev/null
+++ b/net/libtorrent-rasterbar/patches/patch-src_disk_io_thread_cpp
@@ -0,0 +1,13 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- src/disk_io_thread.cpp.orig
 src/disk_io_thread.cpp
+@@ -62,6 +62,7 @@ POSSIBILITY OF SUCH DAMAGE.
+ #if __cplusplus >= 201103L || defined __clang__
+ 
+ #if DEBUG_DISK_THREAD
++#include  // for va_list
+ #define DLOG(...) debug_log(__VA_ARGS__)
+ #else
+ #define DLOG(...) do {} while(false)
diff --git a/net/libtorrent-rasterbar/patches/patch-src_session_impl_cpp 
b/net/libtorrent-rasterbar/patches/patch-src_session_impl_cpp
new file mode 100644
index 000..f595740b7a1
--- /dev/null
+++ b/net/libtorrent-rasterbar/patches/patch-src_session_impl_cpp
@@ -0,0 +1,14 @@
+$OpenBSD$
+https://github.com/arvidn/libtorrent/pull/2965
+
+--- src/session_impl.cpp.orig
 src/session_impl.cpp
+@@ -107,6 +107,8 @@ POSSIBILITY OF SUCH DAMAGE.
+ // for logging stat layout
+ #include "libtorrent/stat.hpp"
+ 
++#include  // for va_list
++
+ // for logging the size of DHT structures
+ #ifndef TORRENT_DISABLE_DHT
+ #include

Re: Subversion build broken on -rOPENBSD_6_3

2018-04-24 Thread manphiz




On 4/23/18 10:36 PM, manp...@gmail.com wrote:

Hi Stefan,

On 4/23/18 1:13 PM, Stefan Sperling wrote:

On Mon, Apr 23, 2018 at 09:45:19PM +0200, Stefan Sperling wrote:

On Mon, Apr 23, 2018 at 12:27:18PM -0700, manp...@gmail.com wrote:
Building subversion from ports -stable fails on mips64el (Loongson) 
with
errors[2]. Full build log is also attached. It seems the same 
problem was
reported before[1] with no conclusion. I'm not familiar with swig 
and any

suggestion is appreciated.


Why are you even trying to build this?
What is wrong with 
http://ftp.openbsd.org/pub/OpenBSD/6.3/packages/mips64/subversion-1.9.7p4.tgz 
?




Stuart pointed out to me off-list that this is the wrong package
directory for Loongson, and that unfortunately there's no
subversion package built for 6.3.



Exactly :)


I just tried to build it on amd64 6.3-stable and it works for me
with: cd /usr/ports/devel/subversion && make install



It seems something weird is happening with SWIG. I'm also having similar 
problem with www/ruby-passenger (reported in a separate email) as 
reported by Sven from previous report. If someone knows SWIG it will be 
great to have their advice.


The latest subversion 1.10.0 from -current built just fine. I guess I'll 
just leave 1.9.7p4 in -stable as is.

Re: Subversion build broken on -rOPENBSD_6_3

2018-04-23 Thread manphiz


Hi Stefan,

On 4/23/18 1:13 PM, Stefan Sperling wrote:

On Mon, Apr 23, 2018 at 09:45:19PM +0200, Stefan Sperling wrote:

On Mon, Apr 23, 2018 at 12:27:18PM -0700, manp...@gmail.com wrote:

Building subversion from ports -stable fails on mips64el (Loongson) with
errors[2]. Full build log is also attached. It seems the same problem was
reported before[1] with no conclusion. I'm not familiar with swig and any
suggestion is appreciated.


Why are you even trying to build this?
What is wrong with 
http://ftp.openbsd.org/pub/OpenBSD/6.3/packages/mips64/subversion-1.9.7p4.tgz ?



Stuart pointed out to me off-list that this is the wrong package
directory for Loongson, and that unfortunately there's no
subversion package built for 6.3.



Exactly :)


I just tried to build it on amd64 6.3-stable and it works for me
with: cd /usr/ports/devel/subversion && make install



It seems something weird is happening with SWIG. I'm also having similar 
problem with www/ruby-passenger (reported in a separate email) as 
reported by Sven from previous report. If someone knows SWIG it will be 
great to have their advice.

Re: Fix libtorrent-rasterbar for gcc 4.9 on -rOPENBSD_6_3 (tested on OpenBSD/Loongson)

2018-04-23 Thread manphiz


Hi Stuart,

On 4/23/18 10:48 AM, Stuart Henderson wrote:

On 2018/04/22 15:54, manp...@gmail.com wrote:

On 4/22/18 4:39 AM, manp...@gmail.com wrote:

On 4/15/18 1:25 PM, manp...@gmail.com wrote:

The patch attached fixes building libtorrent-rasterbar on
OpenBSD/Loongson for -rOPENBSD_6_3. It added several missing
includes, added "-std=gnu++14" to CXXFLAGS as it is now default for
newer compiler and the code uses those new features, and another
patch from -current. I'm not sure whether this is the correct way to
update ports for a -stable branch so let me know.

Thanks.


It seems that there is another problem with the setup.py of python
binding that relies on existence of environment variable CXX to be
defined, otherwise it will use "cc" instead of "c++" to build the
binding, which then lead to another problem: the main library would be
built using C++14 that enabled using std::chrono, while the bindings
would not and used boost::chrono instead, and the bindings will fail to
load due to missing symbols (actually symbol mismatch). The fix is to
define CXX=c++ in Makefile.am of python binding.

The revised patch against -rOPENBSD_6_3 is attached.


And it turns out it's a bad idea to patch configure.ac and Makefile.am which
will require "autoreconf". Attaching the patch dropping those parts. 1.1.7
on -current has similar issue and I'll provide a separate patch and also try
to incorporate upstream.


No loongson here so I can't test any of this, but a few things:

- we work on -current primarily, sometimes things can be backported but if
this is broken on -current at the moment, that needs fixing first



Agreed.


- compilers should come from the environment rather than hardcoded, maybe
try something like:

MAKE_ENV =  CC="${CC}" CXX="${CXX}"
CXXFLAGS += --std=gnu++14



I'm currently working with upstream to incorporate those patches as 
well. Once the patches are incorporated I'll backport them to -current 
and then -stable.

Subversion build broken on -rOPENBSD_6_3

2018-04-23 Thread manphiz

Building subversion from ports -stable fails on mips64el (Loongson) with 
errors[2]. Full build log is also attached. It seems the same problem 
was reported before[1] with no conclusion. I'm not familiar with swig 
and any suggestion is appreciated.


[1] https://marc.info/?l=openbsd-ports&m=152280918226757&w=2

[2] Error message excerpt:
...
cd . && /usr/local/bin/python2.7 
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/build/generator/swig/header_wrappers.py 
build.conf /usr/local/bin/swig subversion/include/svn_wc.h
/usr/local/bin/swig 
-I/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion 
-I/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include 
-I/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig 

-I/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/include 

-I/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy 

-I/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy 
 -I/usr/local/include/apr-1/  -I/usr/local/include/apr-1/ 
-I/usr/local/include/db4 -I/usr/local/include -D_POSIX_THREADS 
-DAPR_POOL_DEBUG=1  -python -classic -o 
subversion/bindings/swig/python/svn_client.c 
./subversion/bindings/swig/svn_client.i
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_version.h:148: 
Warning 302: Identifier 'svn_version_t' redefined (ignored),
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_types_h.swg:47: 
Warning 302: previous definition of 'svn_version_t'.
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_props.h:504: 
Warning 305: Bad constant value (ignored).
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/include/svn_props.h:652: 
Warning 305: Bad constant value (ignored).
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_wc_h.swg:95: 
Error: Couldn't find 'proxy.py'.
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_wc_h.swg:96: 
Error: Couldn't find 'proxy.py'.
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_wc_h.swg:97: 
Error: Couldn't find 'proxy.py'.
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_wc_h.swg:98: 
Error: Couldn't find 'proxy.py'.
/usr/ports/pobj/subversion-1.9.7/subversion-1.9.7/subversion/bindings/swig/proxy/svn_wc_h.swg:99: 
Error: Couldn't find 'proxy.py'.

...


subversion-1.9.7p4.log.gz
Description: GNU Zip compressed data

Re: Fix libtorrent-rasterbar for gcc 4.9 on -rOPENBSD_6_3 (tested on OpenBSD/Loongson)

2018-04-22 Thread manphiz


On 4/22/18 4:39 AM, manp...@gmail.com wrote:

On 4/15/18 1:25 PM, manp...@gmail.com wrote:
The patch attached fixes building libtorrent-rasterbar on 
OpenBSD/Loongson for -rOPENBSD_6_3. It added several missing includes, 
added "-std=gnu++14" to CXXFLAGS as it is now default for newer 
compiler and the code uses those new features, and another patch from 
-current. I'm not sure whether this is the correct way to update ports 
for a -stable branch so let me know.


Thanks.


It seems that there is another problem with the setup.py of python 
binding that relies on existence of environment variable CXX to be 
defined, otherwise it will use "cc" instead of "c++" to build the 
binding, which then lead to another problem: the main library would be 
built using C++14 that enabled using std::chrono, while the bindings 
would not and used boost::chrono instead, and the bindings will fail to 
load due to missing symbols (actually symbol mismatch). The fix is to 
define CXX=c++ in Makefile.am of python binding.


The revised patch against -rOPENBSD_6_3 is attached.


And it turns out it's a bad idea to patch configure.ac and Makefile.am 
which will require "autoreconf". Attaching the patch dropping those 
parts. 1.1.7 on -current has similar issue and I'll provide a separate 
patch and also try to incorporate upstream.
diff -Naur ./Makefile ./Makefile
--- ./Makefile  Wed Feb  7 22:30:34 2018
+++ ./Makefile  Sat Apr 21 17:48:43 2018
@@ -3,6 +3,7 @@
 COMMENT =  C++ library implementing a BitTorrent client
 
 MODPY_EGG_VERSION =1.1.6
+REVISION = 0
 DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
 
 SHARED_LIBS += torrent-rasterbar 0.0   # 9.0.0
diff -Naur ./patches/patch-bindings_python_Makefile_in 
./patches/patch-bindings_python_Makefile_in
--- ./patches/patch-bindings_python_Makefile_in Wed Dec 31 16:00:00 1969
+++ ./patches/patch-bindings_python_Makefile_in Sun Apr 22 04:08:04 2018
@@ -0,0 +1,24 @@
+diff --git bindings/python/Makefile.in bindings/python/Makefile.in
+index 0fe5288..31191da 100644
+--- bindings/python/Makefile.in
 bindings/python/Makefile.in
+@@ -526,16 +526,16 @@ uninstall-am: uninstall-local
+ 
+ 
+ @ENABLE_PYTHON_BINDING_TRUE@all-local:
+-@ENABLE_PYTHON_BINDING_TRUE@  $(PYTHON) $(srcdir)/setup.py build
++@ENABLE_PYTHON_BINDING_TRUE@  CXX=c++ $(PYTHON) $(srcdir)/setup.py build
+ 
+ @ENABLE_PYTHON_BINDING_TRUE@install-exec-local:
+-@ENABLE_PYTHON_BINDING_TRUE@  $(PYTHON) $(srcdir)/setup.py install 
@PYTHON_INSTALL_PARAMS@
++@ENABLE_PYTHON_BINDING_TRUE@  CXX=c++ $(PYTHON) $(srcdir)/setup.py install 
@PYTHON_INSTALL_PARAMS@
+ 
+ @ENABLE_PYTHON_BINDING_TRUE@uninstall-local:
+ @ENABLE_PYTHON_BINDING_TRUE@  rm -rf 
$(DESTDIR)$(libdir)/python*/*-packages/*libtorrent*
+ 
+ @ENABLE_PYTHON_BINDING_TRUE@clean-local:
+-@ENABLE_PYTHON_BINDING_TRUE@  $(PYTHON) $(srcdir)/setup.py clean --all
++@ENABLE_PYTHON_BINDING_TRUE@  CXX=c++ $(PYTHON) $(srcdir)/setup.py clean --all
+ 
+ # Tell versions [3.59,3.63) of GNU make to not export all variables.
+ # Otherwise a system limit (for SysV at least) may be exceeded.
diff -Naur ./patches/patch-bindings_python_compile_flags_in 
./patches/patch-bindings_python_compile_flags_in
--- ./patches/patch-bindings_python_compile_flags_inWed Dec 31 16:00:00 1969
+++ ./patches/patch-bindings_python_compile_flags_inSat Apr 21 17:15:37 2018
@@ -0,0 +1,7 @@
+diff --git bindings/python/compile_flags.in bindings/python/compile_flags.in
+index d51261c..bf979b8 100644
+--- bindings/python/compile_flags.in
 bindings/python/compile_flags.in
+@@ -1 +1 @@
+--I@top_srcdir@/include @COMPILETIME_OPTIONS@ @CPPFLAGS@ @BOOST_CPPFLAGS@ 
@PYTHON_CXXFLAGS@ @OPENSSL_INCLUDES@
++-std=gnu++14 -I@top_srcdir@/include @COMPILETIME_OPTIONS@ @CPPFLAGS@ 
@BOOST_CPPFLAGS@ @PYTHON_CXXFLAGS@ @OPENSSL_INCLUDES@
diff -Naur ./patches/patch-configure ./patches/patch-configure
--- ./patches/patch-configure   Wed Dec 31 16:00:00 1969
+++ ./patches/patch-configure   Sat Apr 21 17:14:10 2018
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- configure.orig Sun Dec 31 06:21:37 2017
 configure  Sat Apr 14 17:39:19 2018
+@@ -16763,7 +16763,7 @@
+ LIBS="$PTHREAD_LIBS $LIBS"
+ CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
+ CC="$PTHREAD_CC"
+-CXXFLAGS="$CXXFLAGS -ftemplate-depth=120 -Wno-format-zero-length"
++CXXFLAGS="$CXXFLAGS -std=gnu++14 -ftemplate-depth=120 -Wno-format-zero-length"
+ 
+ $as_echo  "Checking for visibility support:"
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for 
__attribute__((visibility(\"hidden\")))" >&5
diff -Naur ./patches/patch-include_libtorrent_aux__session_interface_hpp 
./patches/patch-include_libtorrent_aux__session_interface_hpp
--- ./patches/patch-include_libtorrent_aux__session_interface_hpp   Wed Dec 
31 16:00:00 1969
+++ ./patches/patch-include_libtorrent_aux__session_interface_hpp   Sat Apr 
21 17:14:10 2018
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- include/libtorrent/aux_/session_interface.hpp.orig Mon Dec 11 14:59:32 2017
 include/l

Re: Fix libtorrent-rasterbar for gcc 4.9 on -rOPENBSD_6_3 (tested on OpenBSD/Loongson)

2018-04-22 Thread manphiz


On 4/15/18 1:25 PM, manp...@gmail.com wrote:
The patch attached fixes building libtorrent-rasterbar on 
OpenBSD/Loongson for -rOPENBSD_6_3. It added several missing includes, 
added "-std=gnu++14" to CXXFLAGS as it is now default for newer compiler 
and the code uses those new features, and another patch from -current. 
I'm not sure whether this is the correct way to update ports for a 
-stable branch so let me know.


Thanks.


It seems that there is another problem with the setup.py of python 
binding that relies on existence of environment variable CXX to be 
defined, otherwise it will use "cc" instead of "c++" to build the 
binding, which then lead to another problem: the main library would be 
built using C++14 that enabled using std::chrono, while the bindings 
would not and used boost::chrono instead, and the bindings will fail to 
load due to missing symbols (actually symbol mismatch). The fix is to 
define CXX=c++ in Makefile.am of python binding.


The revised patch against -rOPENBSD_6_3 is attached.
diff -Naur ./Makefile ./Makefile
--- ./Makefile  Wed Feb  7 22:30:34 2018
+++ ./Makefile  Sat Apr 21 17:48:43 2018
@@ -3,6 +3,7 @@
 COMMENT =  C++ library implementing a BitTorrent client
 
 MODPY_EGG_VERSION =1.1.6
+REVISION = 0
 DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
 
 SHARED_LIBS += torrent-rasterbar 0.0   # 9.0.0
diff -Naur ./patches/patch-bindings_python_Makefile_am 
./patches/patch-bindings_python_Makefile_am
--- ./patches/patch-bindings_python_Makefile_am Wed Dec 31 16:00:00 1969
+++ ./patches/patch-bindings_python_Makefile_am Sun Apr 22 04:14:36 2018
@@ -0,0 +1,23 @@
+diff --git bindings/python/Makefile.am bindings/python/Makefile.am
+index 41b9942..16d124b 100644
+--- bindings/python/Makefile.am
 bindings/python/Makefile.am
+@@ -33,15 +33,15 @@ EXTRA_DIST = \
+ if ENABLE_PYTHON_BINDING
+ 
+ all-local:
+-  $(PYTHON) $(srcdir)/setup.py build
++  CXX=c++ $(PYTHON) $(srcdir)/setup.py build
+ 
+ install-exec-local:
+-  $(PYTHON) $(srcdir)/setup.py install @PYTHON_INSTALL_PARAMS@
++  CXX=c++ $(PYTHON) $(srcdir)/setup.py install @PYTHON_INSTALL_PARAMS@
+ 
+ uninstall-local:
+   rm -rf $(DESTDIR)$(libdir)/python*/*-packages/*libtorrent*
+ 
+ clean-local:
+-  $(PYTHON) $(srcdir)/setup.py clean --all
++  CXX=c++ $(PYTHON) $(srcdir)/setup.py clean --all
+ 
+ endif
diff -Naur ./patches/patch-bindings_python_Makefile_in 
./patches/patch-bindings_python_Makefile_in
--- ./patches/patch-bindings_python_Makefile_in Wed Dec 31 16:00:00 1969
+++ ./patches/patch-bindings_python_Makefile_in Sun Apr 22 04:08:04 2018
@@ -0,0 +1,24 @@
+diff --git bindings/python/Makefile.in bindings/python/Makefile.in
+index 0fe5288..31191da 100644
+--- bindings/python/Makefile.in
 bindings/python/Makefile.in
+@@ -526,16 +526,16 @@ uninstall-am: uninstall-local
+ 
+ 
+ @ENABLE_PYTHON_BINDING_TRUE@all-local:
+-@ENABLE_PYTHON_BINDING_TRUE@  $(PYTHON) $(srcdir)/setup.py build
++@ENABLE_PYTHON_BINDING_TRUE@  CXX=c++ $(PYTHON) $(srcdir)/setup.py build
+ 
+ @ENABLE_PYTHON_BINDING_TRUE@install-exec-local:
+-@ENABLE_PYTHON_BINDING_TRUE@  $(PYTHON) $(srcdir)/setup.py install 
@PYTHON_INSTALL_PARAMS@
++@ENABLE_PYTHON_BINDING_TRUE@  CXX=c++ $(PYTHON) $(srcdir)/setup.py install 
@PYTHON_INSTALL_PARAMS@
+ 
+ @ENABLE_PYTHON_BINDING_TRUE@uninstall-local:
+ @ENABLE_PYTHON_BINDING_TRUE@  rm -rf 
$(DESTDIR)$(libdir)/python*/*-packages/*libtorrent*
+ 
+ @ENABLE_PYTHON_BINDING_TRUE@clean-local:
+-@ENABLE_PYTHON_BINDING_TRUE@  $(PYTHON) $(srcdir)/setup.py clean --all
++@ENABLE_PYTHON_BINDING_TRUE@  CXX=c++ $(PYTHON) $(srcdir)/setup.py clean --all
+ 
+ # Tell versions [3.59,3.63) of GNU make to not export all variables.
+ # Otherwise a system limit (for SysV at least) may be exceeded.
diff -Naur ./patches/patch-bindings_python_compile_flags_in 
./patches/patch-bindings_python_compile_flags_in
--- ./patches/patch-bindings_python_compile_flags_inWed Dec 31 16:00:00 1969
+++ ./patches/patch-bindings_python_compile_flags_inSat Apr 21 17:15:37 2018
@@ -0,0 +1,7 @@
+diff --git bindings/python/compile_flags.in bindings/python/compile_flags.in
+index d51261c..bf979b8 100644
+--- bindings/python/compile_flags.in
 bindings/python/compile_flags.in
+@@ -1 +1 @@
+--I@top_srcdir@/include @COMPILETIME_OPTIONS@ @CPPFLAGS@ @BOOST_CPPFLAGS@ 
@PYTHON_CXXFLAGS@ @OPENSSL_INCLUDES@
++-std=gnu++14 -I@top_srcdir@/include @COMPILETIME_OPTIONS@ @CPPFLAGS@ 
@BOOST_CPPFLAGS@ @PYTHON_CXXFLAGS@ @OPENSSL_INCLUDES@
diff -Naur ./patches/patch-configure ./patches/patch-configure
--- ./patches/patch-configure   Wed Dec 31 16:00:00 1969
+++ ./patches/patch-configure   Sat Apr 21 17:14:10 2018
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- configure.orig Sun Dec 31 06:21:37 2017
 configure  Sat Apr 14 17:39:19 2018
+@@ -16763,7 +16763,7 @@
+ LIBS="$PTHREAD_LIBS $LIBS"
+ CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
+ CC="$PTHREAD_CC"
+-CXXFLAGS="$CXXFLAGS -ftemplate-depth=120 -Wno-format-zero-lengt

Fix libtorrent-rasterbar for gcc 4.9 on -rOPENBSD_6_3 (tested on OpenBSD/Loongson)

2018-04-15 Thread manphiz

The patch attached fixes building libtorrent-rasterbar on 
OpenBSD/Loongson for -rOPENBSD_6_3. It added several missing includes, 
added "-std=gnu++14" to CXXFLAGS as it is now default for newer compiler 
and the code uses those new features, and another patch from -current. 
I'm not sure whether this is the correct way to update ports for a 
-stable branch so let me know.


Thanks.
Index: Makefile
===
RCS file: /cvs/ports/net/libtorrent-rasterbar/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile8 Feb 2018 06:30:34 -   1.1.1.1
+++ Makefile15 Apr 2018 20:19:13 -
@@ -3,6 +3,7 @@
 COMMENT =  C++ library implementing a BitTorrent client
 
 MODPY_EGG_VERSION =1.1.6
+REVISION = 1
 DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
 
 SHARED_LIBS += torrent-rasterbar 0.0   # 9.0.0
Index: patches/patch-configure
===
RCS file: patches/patch-configure
diff -N patches/patch-configure
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-configure 15 Apr 2018 20:19:13 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- configure.orig Sun Dec 31 06:21:37 2017
 configure  Sat Apr 14 17:39:19 2018
+@@ -16763,7 +16763,7 @@
+ LIBS="$PTHREAD_LIBS $LIBS"
+ CFLAGS="$PTHREAD_CFLAGS $CFLAGS"
+ CC="$PTHREAD_CC"
+-CXXFLAGS="$CXXFLAGS -ftemplate-depth=120 -Wno-format-zero-length"
++CXXFLAGS="$CXXFLAGS -std=gnu++14 -ftemplate-depth=120 -Wno-format-zero-length"
+ 
+ $as_echo  "Checking for visibility support:"
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for 
__attribute__((visibility(\"hidden\")))" >&5
Index: patches/patch-include_libtorrent_aux__session_interface_hpp
===
RCS file: patches/patch-include_libtorrent_aux__session_interface_hpp
diff -N patches/patch-include_libtorrent_aux__session_interface_hpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-include_libtorrent_aux__session_interface_hpp 15 Apr 2018 
20:19:13 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- include/libtorrent/aux_/session_interface.hpp.orig Mon Dec 11 14:59:32 2017
 include/libtorrent/aux_/session_interface.hpp  Sat Apr 14 16:36:02 2018
+@@ -33,6 +33,8 @@
+ #ifndef TORRENT_SESSION_INTERFACE_HPP_INCLUDED
+ #define TORRENT_SESSION_INTERFACE_HPP_INCLUDED
+ 
++#include  // for va_list
++
+ #include "libtorrent/config.hpp"
+ #include "libtorrent/peer_id.hpp"
+ #include "libtorrent/address.hpp"
Index: patches/patch-src_disk_io_thread_cpp
===
RCS file: patches/patch-src_disk_io_thread_cpp
diff -N patches/patch-src_disk_io_thread_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_disk_io_thread_cpp15 Apr 2018 20:19:13 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- src/disk_io_thread.cpp.origMon Dec 11 14:59:32 2017
 src/disk_io_thread.cpp Sat Apr 14 16:44:04 2018
+@@ -57,6 +57,8 @@
+ 
+ #include "libtorrent/debug.hpp"
+ 
++#include  // for va_list
++
+ #define DEBUG_DISK_THREAD 0
+ 
+ #if __cplusplus >= 201103L || defined __clang__
Index: patches/patch-src_kademlia_dht_tracker_cpp
===
RCS file: patches/patch-src_kademlia_dht_tracker_cpp
diff -N patches/patch-src_kademlia_dht_tracker_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_kademlia_dht_tracker_cpp  15 Apr 2018 20:19:13 -
@@ -0,0 +1,18 @@
+$OpenBSD: patch-src_kademlia_dht_tracker_cpp,v 1.1 2018/04/12 04:40:41 bentley 
Exp $
+
+https://github.com/arvidn/libtorrent/pull/2931
+
+Index: src/kademlia/dht_tracker.cpp
+--- src/kademlia/dht_tracker.cpp.orig
 src/kademlia/dht_tracker.cpp
+@@ -224,7 +224,9 @@ namespace libtorrent { namespace dht
+   void dht_tracker::get_peers(sha1_hash const& ih
+   , boost::function const&)> f)
+   {
+-  m_dht.get_peers(ih, f, NULL, false);
++  m_dht.get_peers(ih, f
++  , 
boost::function > const&)>()
++  , false);
+   }
+ 
+   void dht_tracker::announce(sha1_hash const& ih, int listen_port, int 
flags
Index: patches/patch-src_session_impl_cpp
===
RCS file: patches/patch-src_session_impl_cpp
diff -N patches/patch-src_session_impl_cpp
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-src_session_impl_cpp  15 Apr 2018 20:19:13 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- src/session_impl.cpp.orig  Thu Dec 28 07:54:12 2017
 src/session_impl.cpp   Sat Apr 14 16:44:23 2018
+@@ -107,6 +107,8 @@
+ // for logging stat layout
+ #include "libtorrent/stat.hpp"
+ 
++#include  // for va_list
++
+ // for logging the size of DHT structures
+ #ifndef TORRENT_DISABLE_DHT
+ #include

Re: ruby-passenger failed to build on OpenBSD/loongson

2018-04-14 Thread manphiz


Hi,

On 4/12/18 10:58 PM, manp...@gmail.com wrote:

Dear ports maintainer,

When building nginx, one of its dependencies ruby-passenger failed to 
build due to dwarf version mismatch. The most relevant line is below:


/usr/bin/ld: Dwarf Error: found dwarf version '0', this reader only 
handles version 2 information.


The detailed build log is in attachment. Let me know if more information 
is required.


Thanks.


I've further checked dwarf information for all the .o and .a files using 
readelf and all of them reported dwarf version 2. Could this be an ld issue?


The command I used for each file (e.g. 
buildout/common/libpassenger_common/LoggingKit.o, one of the files to link):


$ readelf --debug-dump=info 
buildout/common/libpassenger_common/LoggingKit.o | grep -A 2 
"Compilation Unit" | grep "Version:"

ruby-passenger failed to build on OpenBSD/loongson

2018-04-12 Thread manphiz


Dear ports maintainer,

When building nginx, one of its dependencies ruby-passenger failed to 
build due to dwarf version mismatch. The most relevant line is below:


/usr/bin/ld: Dwarf Error: found dwarf version '0', this reader only 
handles version 2 information.


The detailed build log is in attachment. Let me know if more information 
is required.


Thanks.


nginx_build_failure.log.gz
Description: GNU Zip compressed data

42 matches

Mail list logo