Re: How to usefully debug thunderbird crash?

[Karel Gardas]

On 3/16/19 5:21 PM, Peter Nicolai Mathias Hansteen wrote:

I’ve been using Thunderbird for mail on my OpenBSD laptop for a few years now, 
with the odd crash but rarely anything reproducible. Now after leaving my 
OpenBSD laptop at home while I went on a trip to the great elsewhere and read 
mail using something else, Thunderbird reliably crashes after successfully 
downloading the 4000+ messages from the server (via pop3, spop3d on OpenBSD if 
it matters), but apparently before managing to update its own local message 
store. Leading of course to another download on the next startup, and so on and 
on.

The crash *does* leave a thunderbird.core file in my home directory, and after 
starting the  thing from the shell prompt (ie thunderbird &), I got the 
following message displayed:

[Sat Mar 16 13:06:31] peter@greyhame:~$ out of memory: 0x0180 bytes 
requested

[1]+  Segmentation fault  (core dumped) thunderbird

The machine has 32G RAM, so I assume actual physical memory was not exhausted, 
but I assume  some settable limit would be relevant.

What is the more useful path forward here?


Check:
ulimit -a

and especially see login.conf(5) and /etc/login.conf

Re: lang/ghc

[Karel Gardas]

Indeed! Two questions: (1) if I'm not mistaken you bootstrap with port's 
GCC, why? Have you tested base clang? IIRC this was working last time I 
tested GHC HEAD on -current and (2) have you enabled shared libraries or 
not yet?


Thanks!
Karel


On 2/18/19 9:47 PM, Matthias Kilian wrote:
Before I get too many questions: I've an unfinished update for  > ghc-8.6.3 sitting in my tree. Missing bits: add version numbers of > 
new included libraries to the Makefile, regenerate pkg/PLIST. Maybe > 
try the test suite. Then, fix / update all the ports depending on > 
lang/ghc ;-) > > Ciao,

Re: www/iridium README about unveil

[Karel Gardas]

Just iridium user here.

On Tue, 12 Feb 2019 07:02:31 +0100
Solene Rapenne  wrote:

> So, iridium can only display paths allowed in /etc/iridium/, this

This "allowed in /etc/iridium/" is quite confusing. Shouldn't this be "allowed 
in /etc/iridium/unveil.main" unveil definition file for the main Iridium 
process" or something like that?

> includes the following paths:
> 
>   ~/Documents ~/Downloads ~/Music
>   ~/Pictures  ~/Videos/tmp
> 
> If you need to upload a file, you need to make the file available in one of
> those folders.
> 
> When iridium file browser is showing up, it may be displaying an unauthorized
> folder which will appear empty, which mean it is not possible to browse to 
> some
> other location. One can use the keyboard shortcut Ctrl+L and type a path in 
> the
> upper address bar to reach a whitelisted path.
> 
> Unveil can be disabled with the parameter --disable-unveil

", but we highly discourage this practise" -- or something like that may be 
added here IMHO.

Thanks!
Karel

Re: UPDATE: maven 3.6.0

[Karel Gardas]

On Mon, 11 Feb 2019 22:30:42 +
Stuart Henderson  wrote:

> > RCS file: /cvs/ports/devel/maven/pkg/PLIST,v
> > retrieving revision 1.10
> > diff -u -p -u -r1.10 PLIST
> > --- pkg/PLIST   23 Apr 2018 10:41:52 -  1.10
> > +++ pkg/PLIST   3 Feb 2019 20:03:16 -
> > @@ -14,103 +14,69 @@ maven/boot/
> 
> How did you generate this plist? Some directory entries are removed which
> shouldn't have been.

That was done by hand. OK, will look into how to generate it properly. Thanks!

Re: UPDATE: maven 3.6.0

[Karel Gardas]

ping. Any issues with the patch?

Thanks!
Karel

On Sun, 3 Feb 2019 21:05:48 +0100
Karel Gardas  wrote:

> 
> Hello,
> 
> patch below updates maven to 3.6.0.
> 
> Thanks,
> Karel

UPDATE: maven 3.6.0

[Karel Gardas]

Hello,

patch below updates maven to 3.6.0.

Thanks,
Karel

Index: Makefile
===
RCS file: /cvs/ports/devel/maven/Makefile,v
retrieving revision 1.30
diff -u -p -u -r1.30 Makefile
--- Makefile23 Apr 2018 10:41:52 -  1.30
+++ Makefile3 Feb 2019 20:03:16 -
@@ -2,7 +2,7 @@
 
 COMMENT=   software project management and comprehension tool
 
-V= 3.5.3
+V= 3.6.0
 DISTNAME=  apache-maven-$V
 PKGNAME=   ${DISTNAME:S/apache-//}
 CATEGORIES=devel
Index: distinfo
===
RCS file: /cvs/ports/devel/maven/distinfo,v
retrieving revision 1.9
diff -u -p -u -r1.9 distinfo
--- distinfo23 Apr 2018 10:41:52 -  1.9
+++ distinfo3 Feb 2019 20:03:16 -
@@ -1,2 +1,2 @@
-SHA256 (apache-maven-3.5.3-bin.tar.gz) = 
tSlWNz+rHdQneSZQerGJ+3l7O8UaKiZ6GTyTH/+thAg=
-SIZE (apache-maven-3.5.3-bin.tar.gz) = 8799579
+SHA256 (apache-maven-3.6.0-bin.tar.gz) = 
6a1b346af36a1f1a491c1c1a141667c5de69b42e6611d3687df26868bc0f4637
+SIZE (apache-maven-3.6.0-bin.tar.gz) = 9063587
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/maven/pkg/PLIST,v
retrieving revision 1.10
diff -u -p -u -r1.10 PLIST
--- pkg/PLIST   23 Apr 2018 10:41:52 -  1.10
+++ pkg/PLIST   3 Feb 2019 20:03:16 -
@@ -14,103 +14,69 @@ maven/boot/
 maven/boot/plexus-classworlds-2.5.2.jar
 maven/conf
 maven/lib/
+maven/lib/animal-sniffer-annotations-1.14.jar
+maven/lib/animal-sniffer-annotations.license
 maven/lib/aopalliance-1.0.jar
 maven/lib/cdi-api-1.0.jar
-maven/lib/cdi-api.license
+maven/lib/checker-compat-qual-2.0.0.jar
+maven/lib/checker-compat-qual.license
 maven/lib/commons-cli-1.4.jar
-maven/lib/commons-cli.license
 maven/lib/commons-io-2.5.jar
-maven/lib/commons-io.license
-maven/lib/commons-lang3-3.5.jar
-maven/lib/commons-lang3.license
-maven/lib/ext/
+maven/lib/commons-lang3-3.8.1.jar
+maven/lib/error_prone_annotations-2.1.3.jar
 maven/lib/ext/README.txt
-maven/lib/guava-20.0.jar
-maven/lib/guice-4.0-no_aop.jar
-maven/lib/jansi-1.17.jar
-maven/lib/jansi-native/
+maven/lib/guava-25.1-android.jar
+maven/lib/guice-4.2.1-no_aop.jar
+maven/lib/j2objc-annotations-1.1.jar
+maven/lib/jansi-1.17.1.jar
 maven/lib/jansi-native/README.txt
-maven/lib/jansi-native/freebsd32/
 maven/lib/jansi-native/freebsd32/libjansi.so
-maven/lib/jansi-native/freebsd64/
 maven/lib/jansi-native/freebsd64/libjansi.so
-maven/lib/jansi-native/linux32/
 maven/lib/jansi-native/linux32/libjansi.so
-maven/lib/jansi-native/linux64/
 maven/lib/jansi-native/linux64/libjansi.so
-maven/lib/jansi-native/osx/
 maven/lib/jansi-native/osx/libjansi.jnilib
-maven/lib/jansi-native/windows32/
 maven/lib/jansi-native/windows32/jansi.dll
-maven/lib/jansi-native/windows64/
 maven/lib/jansi-native/windows64/jansi.dll
 maven/lib/javax.inject-1.jar
 maven/lib/jcl-over-slf4j-1.7.25.jar
 maven/lib/jcl-over-slf4j.license
 maven/lib/jsr250-api-1.0.jar
 maven/lib/jsr250-api.license
-maven/lib/maven-artifact-3.5.3.jar
-maven/lib/maven-artifact.license
-maven/lib/maven-builder-support-3.5.3.jar
-maven/lib/maven-builder-support.license
-maven/lib/maven-compat-3.5.3.jar
-maven/lib/maven-compat.license
-maven/lib/maven-core-3.5.3.jar
-maven/lib/maven-core.license
-maven/lib/maven-embedder-3.5.3.jar
-maven/lib/maven-embedder.license
-maven/lib/maven-model-3.5.3.jar
-maven/lib/maven-model-builder-3.5.3.jar
-maven/lib/maven-model-builder.license
-maven/lib/maven-model.license
-maven/lib/maven-plugin-api-3.5.3.jar
-maven/lib/maven-plugin-api.license
-maven/lib/maven-repository-metadata-3.5.3.jar
-maven/lib/maven-repository-metadata.license
-maven/lib/maven-resolver-api-1.1.1.jar
-maven/lib/maven-resolver-api.license
-maven/lib/maven-resolver-connector-basic-1.1.1.jar
-maven/lib/maven-resolver-connector-basic.license
-maven/lib/maven-resolver-impl-1.1.1.jar
-maven/lib/maven-resolver-impl.license
-maven/lib/maven-resolver-provider-3.5.3.jar
-maven/lib/maven-resolver-provider.license
-maven/lib/maven-resolver-spi-1.1.1.jar
-maven/lib/maven-resolver-spi.license
-maven/lib/maven-resolver-transport-wagon-1.1.1.jar
-maven/lib/maven-resolver-transport-wagon.license
-maven/lib/maven-resolver-util-1.1.1.jar
-maven/lib/maven-resolver-util.license
-maven/lib/maven-settings-3.5.3.jar
-maven/lib/maven-settings-builder-3.5.3.jar
-maven/lib/maven-settings-builder.license
-maven/lib/maven-settings.license
+maven/lib/jsr305-3.0.2.jar
+maven/lib/maven-artifact-3.6.0.jar
+maven/lib/maven-builder-support-3.6.0.jar
+maven/lib/maven-compat-3.6.0.jar
+maven/lib/maven-core-3.6.0.jar
+maven/lib/maven-embedder-3.6.0.jar
+maven/lib/maven-model-3.6.0.jar
+maven/lib/maven-model-builder-3.6.0.jar
+maven/lib/maven-plugin-api-3.6.0.jar
+maven/lib/maven-repository-metadata-3.6.0.jar
+maven/lib/maven-resolver-api-1.3.1.jar
+maven/lib/maven-resolver-connector-basic-1.3.1.jar

Re: Eclipse/SWT requires GL/glx.h

[Karel Gardas]

Thanks! Also already found it, will use `pkg-config  osmesa` to use that 
in SWT.

pkglocatedb hint is most appreciated!

Karel

On Sun, 20 Jan 2019 20:09:16 +0100
Fabian Raetz  wrote:

> Hi
> 
> You can find the file in /usr/X11R6/include/GL/glx.h.
> In general the pkglocatedb port comes in handy if you're looking for a
> specific file.
> 
> Cheers,
> Fabian
> 
> Am So., 20. Jan. 2019 um 20:02 Uhr schrieb Karel Gardas :
> 
> >
> > Hello,
> >
> > in an attempt to bring latest Eclipse IDE to OpenBSD I've hit issue
> > where SWT (GUI library using platform native backends like gtk
> > on linux, cocoa on macos x etc.) compilation fails due to missing
> > GL/glx.h file. This file is for example in ubuntu located in
> > mesa-common-dev package. The file is included from SWT's glx.c file
> > which looks like interfaces some OpenGL primitives from C to Java land.
> >
> > My question is: is such file or Mesa available on OpenBSD?
> >
> > Using -current old 2-3 days.
> >
> > Thanks,
> > Karel
> >
> >

Eclipse/SWT requires GL/glx.h

[Karel Gardas]

Hello,

in an attempt to bring latest Eclipse IDE to OpenBSD I've hit issue
where SWT (GUI library using platform native backends like gtk
on linux, cocoa on macos x etc.) compilation fails due to missing
GL/glx.h file. This file is for example in ubuntu located in
mesa-common-dev package. The file is included from SWT's glx.c file
which looks like interfaces some OpenGL primitives from C to Java land.

My question is: is such file or Mesa available on OpenBSD?

Using -current old 2-3 days.

Thanks,
Karel

Re: please help fixing php-fpm on armv7 - egdb result

[Karel Gardas]

On Fri, 11 Jan 2019 17:02:25 -0800
 wrote:

> Thank you Jeremie for your suggestion.  I built  the gdb package and ran egdb 
> with the result below.  I hope this provides some clues.
> 
> op1bsdsnap1228# egdb /usr/local/sbin/php-fpm-7.2 /root/php-fpm-7.2.core
> GNU gdb (GDB) 7.12.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-unknown-openbsd6.4".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/local/sbin/php-fpm-7.2...(no debugging symbols 
> found)...done.
> [New process 446218]
> 
> warning: .dynamic section for "/usr/lib/libcrypto.so.45.1" is not at the 
> expected address (wrong library or version mismatch?)
> 
> warning: .dynamic section for "/usr/lib/libc.so.93.0" is not at the expected 
> address (wrong library or version mismatch?)
> Core was generated by `php-fpm-7.2'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0xdfdfdfde in ?? ()
> (gdb)

Here ^ you should type "bt" and hit Enter and this way you will see stacktrace 
of the crash. Also if you build php-fpm-7.2 with debugging enabled, it will 
help too probably since you will/should see line numbers etc.

Eclipse IDE

[Karel Gardas]

Hello,

just curious if there is anybody here working on more recent Eclipse
IDE port. If not, then any advices how to proceed with this are
appreciated. Basically I've seen that FBSD (freshports) provides more
recent port so there may be some interesting bits there too just not
sure if to use that as a starting point or try to update OBSD's old
port incrementaly...

Thanks,
Karel

Re: -current Iridium does not have $HOME write permissions for Downloads

[Karel Gardas]

On Tue, 8 Jan 2019 07:13:08 -0800
"Heppler, J. Scott"  wrote:

> I suspect browsers are not the primary means of downloading for seasoned
> OpenBSD users and this new bug may go under the radar.  Anyone else
> seeing this on iridium?  On chromium?

Tested on yesterday OpenBSD snapshot with updated iridium package and 
everything goes well. E.g. iridium is able to download and save into Downloads 
directory fine...

Re: sylpheed crashing/asserting in libX11 on poll_for_event

[Karel Gardas]

Hi Amit,

that would be great. BTW, I'm several more crashes clever and the crash always 
happen during the "Mark as read" action. The sequence of step is:

- click on mailing list folder
- select all unread emails
- right-click to invoke context menu
- select Mark -> Mark as read action (-> CRASH)

Thanks!
Karel

On Tue, 25 Sep 2018 14:16:36 -0500
Amit Kulkarni  wrote:

> Hey Karel,
> Sorry for not getting back to you on the weekend. I will try to take a
> look tonight.
> 
> Thanks
> On Tue, Sep 25, 2018 at 10:43 AM Karel Gardas  wrote:
> >
> >
> > I've switched off Autocheck new email sometime ago and the crash still 
> > happen. Was able to obtain 2 same cores/backtraces today.
> >
> > Karel
> >
> > On Thu, 20 Sep 2018 15:03:10 +0200
> > Karel Gardas  wrote:
> >
> > > On Thu, 20 Sep 2018 14:48:27 +0200
> > > Karel Gardas  wrote:
> > > >
> > > > That's so far what I have observed. As the crashes started to be more 
> > > > regural on the latest -current/-beta, I'll keep my eye on that and if 
> > > > anything more concrete surface, I'll let you know.
> > >
> > > Two more details: the interval to fetch emails is set to 10 minutes and 
> > > I'm using imap/ssl to access gmail.com.
> > >
> > > As I see it now and with what Matthieu wrote in mind, it may be actually 
> > > a race condition between me/interactive select of all messages and then 
> > > marking them as read and between fetch of new messages.
> > >
> > > Thanks!
> > > Karel
> > >
> >
> >


-- 
Karel Gardas 

Re: sylpheed crashing/asserting in libX11 on poll_for_event

[Karel Gardas]

I've switched off Autocheck new email sometime ago and the crash still happen. 
Was able to obtain 2 same cores/backtraces today.

Karel

On Thu, 20 Sep 2018 15:03:10 +0200
Karel Gardas  wrote:

> On Thu, 20 Sep 2018 14:48:27 +0200
> Karel Gardas  wrote:
> > 
> > That's so far what I have observed. As the crashes started to be more 
> > regural on the latest -current/-beta, I'll keep my eye on that and if 
> > anything more concrete surface, I'll let you know.
> 
> Two more details: the interval to fetch emails is set to 10 minutes and I'm 
> using imap/ssl to access gmail.com.
> 
> As I see it now and with what Matthieu wrote in mind, it may be actually a 
> race condition between me/interactive select of all messages and then marking 
> them as read and between fetch of new messages.
> 
> Thanks!
> Karel
> 

Re: sylpheed crashing/asserting in libX11 on poll_for_event

[Karel Gardas]

On Thu, 20 Sep 2018 14:48:27 +0200
Karel Gardas  wrote:
> 
> That's so far what I have observed. As the crashes started to be more regural 
> on the latest -current/-beta, I'll keep my eye on that and if anything more 
> concrete surface, I'll let you know.

Two more details: the interval to fetch emails is set to 10 minutes and I'm 
using imap/ssl to access gmail.com.

As I see it now and with what Matthieu wrote in mind, it may be actually a race 
condition between me/interactive select of all messages and then marking them 
as read and between fetch of new messages.

Thanks!
Karel

Re: sylpheed crashing/asserting in libX11 on poll_for_event

[Karel Gardas]

On Thu, 20 Sep 2018 07:31:10 -0500
Amit Kulkarni  wrote:

> > > recently (1 month or so) sylpheed started to assert quite regurarly in 
> > > poll_for_event call inside the libX11. The full trace looks as:
> > >
> > 
> > This assertion triggers when the application dosn't respect the rules
> > for using libX11 from multiple threads in parallel...
> > 
> > I haven't looked that sylpheed's source code though.
> 
> Karel,
> Will you please list down the steps on how somebody else can reproduce this 
> crash?

Sure, happy to help. First of all, my sylpheed on OBSD is just a MUA connected 
to gmail email/folders. I do have it set to fetch emails from time to time 
(here may be race -- or one possible case) and I'm usually working in a way to 
(i) open email folder, (ii) go thourough it read interesting and then (iii) 
select everything (iv) mark everything selected as read and (v) delete 
everything.

The crash usually happen on either (iv) or (v), mostly on (iv). I'm just not 
sure if in the same time sylpheed has not started its cycle to refresh 
folderrs/reread emails.

That's so far what I have observed. As the crashes started to be more regural 
on the latest -current/-beta, I'll keep my eye on that and if anything more 
concrete surface, I'll let you know.

Thanks!
Karel

sylpheed crashing/asserting in libX11 on poll_for_event

[Karel Gardas]

Hello,

recently (1 month or so) sylpheed started to assert quite regurarly in 
poll_for_event call inside the libX11. The full trace looks as:


Core was generated by `sylpheed'.
Program terminated with signal SIGABRT, Aborted.
#0  thrkill () at -:3
3   -: No such file or directory.
[Current thread is 1 (process 208413)]
(gdb) where
#0  thrkill () at -:3
#1  0x1f0451a5430e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x1f0451a32c62 in _libc___assert2 (file=, 
line=, func=, failedexpr=) at 
/usr/src/lib/libc/gen/assert.c:52
#3  0x1f0412c57d12 in poll_for_event () from /usr/X11R6/lib/libX11.so.16.1
#4  0x1f0412c56d44 in poll_for_response () from 
/usr/X11R6/lib/libX11.so.16.1
#5  0x1f0412c56825 in _XEventsQueued () from /usr/X11R6/lib/libX11.so.16.1
#6  0x1f0412c462d3 in XPending () from /usr/X11R6/lib/libX11.so.16.1
#7  0x1f04a0752018 in gdk_check_xpending (display=0x0) at 
gdkevents-x11.c:159
#8  gdk_event_check (source=0x1f045da2dc00) at gdkevents-x11.c:2400
#9  0x1f040e3475c0 in g_main_context_check (context=0x1f03c3d3d600, 
max_priority=2147483647, fds=, n_fds=) at 
gmain.c:3735
#10 0x1f040e347c92 in g_main_context_iterate (context=, 
block=, dispatch=, self=) at 
gmain.c:3899
#11 0x1f040e347d83 in g_main_context_iteration (context=0x1f03c3d3d600, 
may_block=1) at gmain.c:3963
#12 0x1f04042782a6 in IA__gtk_main_iteration () at gtkmain.c:1358
#13 0x1f046436c075 in imap_thread_run () from 
/usr/local/lib/libsylph-0.so.4.1
#14 0x1f046436847b in imap_set_message_flags () from 
/usr/local/lib/libsylph-0.so.4.1
#15 0x1f0464367736 in imap_msg_list_change_perm_flags () from 
/usr/local/lib/libsylph-0.so.4.1
#16 0x1f01c281fac4 in summary_mark_as_read ()
#17 0x1f049f3b9053 in g_closure_invoke (closure=0x1f045b31ef20, 
return_value=0x0, n_param_values=1, param_values=0x7f7c9d40, 
invocation_hint=) at gclosure.c:804
#18 0x1f049f3d1897 in signal_emit_unlocked_R (node=, 
detail=, instance=, emission_return=, instance_and_params=) at gsignal.c:3635
#19 0x1f049f3d26a5 in g_signal_emit_valist (instance=0x1f04863bece0, 
signal_id=, detail=0, var_args=0x7f7c9f50) at gsignal.c:3391
#20 0x1f049f3d2d8f in g_signal_emit (instance=0x0, signal_id=6, detail=0) 
at gsignal.c:3447
#21 0x1f04043d4496 in IA__gtk_widget_activate (widget=0x1f04863bece0) at 
gtkwidget.c:5041
#22 0x1f0404290a9d in IA__gtk_menu_shell_activate_item 
(menu_shell=0x1f045832a7f0, menu_item=0x1f04863bece0, 
force_deactivate=) at gtkmenushell.c:1278
#23 0x1f0404291dfe in gtk_menu_shell_button_release (widget=0x1f045832a7f0, 
event=) at gtkmenushell.c:703
#24 0x1f0404286181 in gtk_menu_button_release (widget=0x1f045832a7f0, 
event=0x1f03ddcb1c70) at gtkmenu.c:3019
#25 0x1f040427b51d in _gtk_marshal_BOOLEAN__BOXED (closure=0x1f0449c0bbe0, 
return_value=0x7f7ca220, n_param_values=, 
param_values=0x7f7ca280, invocation_hint=, 
marshal_data=)
at gtkmarshalers.c:84
#26 0x1f049f3b9053 in g_closure_invoke (closure=0x1f0449c0bbe0, 
return_value=0x7f7ca220, n_param_values=2, param_values=0x7f7ca280, 
invocation_hint=) at gclosure.c:804
#27 0x1f049f3d19f1 in signal_emit_unlocked_R (node=, 
detail=, instance=, emission_return=, instance_and_params=) at gsignal.c:3673
#28 0x1f049f3d290a in g_signal_emit_valist (instance=0x1f045832a7f0, 
signal_id=, detail=0, var_args=0x7f7ca4a0) at gsignal.c:3401
#29 0x1f049f3d2d8f in g_signal_emit (instance=0x0, signal_id=6, detail=0) 
at gsignal.c:3447
#30 0x1f04043d424d in gtk_widget_event_internal (widget=0x1f045832a7f0, 
event=0x1f03ddcb1c70) at gtkwidget.c:5010
#31 0x1f0404278bd2 in IA__gtk_propagate_event (widget=0x1f045832a7f0, 
event=0x1f03ddcb1c70) at gtkmain.c:2503
#32 0x1f040427883d in IA__gtk_main_do_event (event=) at 
gtkmain.c:1690
#33 0x1f04a07520ae in gdk_event_dispatch (source=, 
callback=, user_data=) at gdkevents-x11.c:2425
#34 0x1f040e347899 in g_main_dispatch (context=) at 
gmain.c:3176
#35 g_main_context_dispatch (context=) at gmain.c:3829
#36 0x1f040e347ca3 in g_main_context_iterate (context=, 
block=, dispatch=, self=) at 
gmain.c:3902
#37 0x1f040e34809f in g_main_loop_run (loop=0x1f04c0c6b270) at gmain.c:4098
#38 0x1f0404277fff in IA__gtk_main () at gtkmain.c:1270
#39 0x1f01c28077ec in main ()


The patch above is generated on today's snapshot obtained from spline.de.

Anybody seen this already? Is there any known workaround or even patch?

Thanks!
Karel

Re: lld amd64 build failures

[Karel Gardas]

On Mon, 7 May 2018 21:10:21 +0200
Christian Weisgerber  wrote:

> lang/ghc  configure: C compiler cannot create executables

ghc is kind of mixed beast. It detects capabilities of platform LD, but then 
links using C compiler usually. So even if I force usage of ld.lld on recent 
-current with GHC HEAD, it still uses binutils ld as this is called by cc 
itself. The common error here is a pass of --build-id=none to binutils ld as 
--build-id is detected as supported by lld, but then cc calls /usr/bin/ld which 
does not support it.
Anyway, mv ld ld.binutils; ln -s ld.ldd ld solves this issue and at least for 
Hello World example, built GHC HEAD runs fine.

fujitsu$ ../inplace/bin/ghc-stage2 -optl=-v -optl=-Wl,-v -dynamic --make 
HelloWorld.lhs  
[1 of 1] Compiling Main ( HelloWorld.lhs, HelloWorld.o )
Linking HelloWorld ...
OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0)
Target: amd64-unknown-openbsd6.3
Thread model: posix
InstalledDir: /usr/bin
 "/usr/bin/ld" -e __start --eh-frame-hdr -Bdynamic -dynamic-linker 
/usr/libexec/ld.so -o HelloWorld /usr/bin/../lib/crt0.o 
/usr/bin/../lib/crtbegin.o 
-L/usr/local/build/karel/ghc-head-obsd-fix/libraries/base/dist-install/build 
-L/usr/local/lib 
-L/usr/local/build/karel/ghc-head-obsd-fix/libraries/integer-gmp/dist-install/build
 
-L/usr/local/build/karel/ghc-head-obsd-fix/libraries/ghc-prim/dist-install/build
 -L/usr/local/build/karel/ghc-head-obsd-fix/rts/dist/build -L/usr/bin/../lib 
-L/usr/lib -z wxneeded -v -lm --gc-sections HelloWorld.o -rpath-link 
/usr/local/build/karel/ghc-head-obsd-fix/libraries/base/dist-install/build 
-rpath 
/usr/local/build/karel/ghc-head-obsd-fix/libraries/base/dist-install/build 
-rpath-link /usr/local/lib -rpath /usr/local/lib -rpath-link 
/usr/local/build/karel/ghc-head-obsd-fix/libraries/integer-gmp/dist-install/build
 -rpath 
/usr/local/build/karel/ghc-head-obsd-fix/libraries/integer-gmp/dist-install/build
 -rpath-link 
/usr/local/build/karel/ghc-head-obsd-fix/libraries/ghc-prim/dist-install/build 
-rpath 
/usr/local/build/karel/ghc-head-obsd-fix/libraries/ghc-prim/dist-install/build 
-rpath-link /usr/local/build/karel/ghc-head-obsd-fix/rts/dist/build -rpath 
/usr/local/build/karel/ghc-head-obsd-fix/rts/dist/build /tmp/ghc19401_0/ghc_6.o 
/tmp/ghc19401_0/ghc_9.o -u base_GHCziTopHandler_runIO_closure -u 
base_GHCziTopHandler_runNonIO_closure -u ghczmprim_GHCziTuple_Z0T_closure -u 
ghczmprim_GHCziTypes_True_closure -u ghczmprim_GHCziTypes_False_closure -u 
base_GHCziPack_unpackCString_closure -u 
base_GHCziWeak_runFinalizzerBatch_closure -u 
base_GHCziIOziException_stackOverflow_closure -u 
base_GHCziIOziException_heapOverflow_closure -u 
base_GHCziIOziException_allocationLimitExceeded_closure -u 
base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -u 
base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -u 
base_GHCziIOziException_cannotCompactFunction_closure -u 
base_GHCziIOziException_cannotCompactPinned_closure -u 
base_GHCziIOziException_cannotCompactMutable_closure -u 
base_ControlziExceptionziBase_nonTermination_closure -u 
base_ControlziExceptionziBase_nestedAtomically_closure -u 
base_GHCziEventziThread_blockedOnBadFD_closure -u 
base_GHCziConcziSync_runSparks_closure -u 
base_GHCziConcziIO_ensureIOManagerIsRunning_closure -u 
base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -u 
base_GHCziConcziSignal_runHandlersPtr_closure -u 
base_GHCziTopHandler_flushStdHandles_closure -u 
base_GHCziTopHandler_runMainIO_closure -u ghczmprim_GHCziTypes_Czh_con_info -u 
ghczmprim_GHCziTypes_Izh_con_info -u ghczmprim_GHCziTypes_Fzh_con_info -u 
ghczmprim_GHCziTypes_Dzh_con_info -u ghczmprim_GHCziTypes_Wzh_con_info -u 
base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u 
base_GHCziInt_I8zh_con_info -u base_GHCziInt_I16zh_con_info -u 
base_GHCziInt_I32zh_con_info -u base_GHCziInt_I64zh_con_info -u 
base_GHCziWord_W8zh_con_info -u base_GHCziWord_W16zh_con_info -u 
base_GHCziWord_W32zh_con_info -u base_GHCziWord_W64zh_con_info -u 
base_GHCziStable_StablePtr_con_info -u hs_atomic_add8 -u hs_atomic_add16 -u 
hs_atomic_add32 -u hs_atomic_add64 -u hs_atomic_sub8 -u hs_atomic_sub16 -u 
hs_atomic_sub32 -u hs_atomic_sub64 -u hs_atomic_and8 -u hs_atomic_and16 -u 
hs_atomic_and32 -u hs_atomic_and64 -u hs_atomic_nand8 -u hs_atomic_nand16 -u 
hs_atomic_nand32 -u hs_atomic_nand64 -u hs_atomic_or8 -u hs_atomic_or16 -u 
hs_atomic_or32 -u hs_atomic_or64 -u hs_atomic_xor8 -u hs_atomic_xor16 -u 
hs_atomic_xor32 -u hs_atomic_xor64 -u hs_cmpxchg8 -u hs_cmpxchg16 -u 
hs_cmpxchg32 -u hs_cmpxchg64 -u hs_atomicread8 -u hs_atomicread16 -u 
hs_atomicread32 -u hs_atomicread64 -u hs_atomicwrite8 -u hs_atomicwrite16 -u 
hs_atomicwrite32 -u hs_atomicwrite64 -lHSbase-4.12.0.0-ghc8.5.20180514 
-lHSinteger-gmp-1.0.2.0-ghc8.5.20180514 -lHSghc-prim-0.5.2.1-ghc8.5.20180514 
-lHSrts-ghc8.5.20180514 -liconv -lgmp -lm -lffi -lpthread -lcompiler_rt -lc 
-lcompiler_rt 

Re: hph build on arm, gcc 4.9

[Karel Gardas]

On Mon, 23 Apr 2018 10:35:51 -0700
 wrote:

> Picking up on your last comment, I restarted the php build on arm with the 
> intent of looking for why gcc is required.  So far I have come across one 
> package that pulls in gcc and it is specific to arm.
> 
> Cmake pulls in libuv whose Makefile has:
> 
> # for atomic builtins
> MODULES =   gcc4
> MODGCC4_ARCHS = arm

This is exactly the same situation like with freeradius3 package.

armv7: freeradius3 build.

[Karel Gardas]

Hello,

I've noticed there is a number armv7 packages specified for the 6.3
release on release web page so I assume all ports are already built.
Hovewer freeradius 3 seems to be missing from the packages, although it
is build on any other architecture I've checked (amd64/sparc64/mips64). I've
attempted to buidl myself minimalistic freeradius3 or what I understand
would be minimalistic by:

# cd /usr/ports/net/freeradius3
# export FLAVOR="no_freetds no_iodbc no_ldap no_memcached no_mysql  no_pgsql 
no_python"
# make

but this fails with a lot of unresolved symbols like:

/usr/local/ports/pobj/freeradius-server-3.0.16-no_freetds-no_iodbc-no_ldap-no_memcached-no_mysql-no_pgsql-no_python/freeradius-server-3.0.16/build/objs/src/modules/rlm_eap/radeapclient.o:
 In function `main':
src/modules/rlm_eap/radeapclient.c:(.text+0x288): undefined reference to 
`talloc_typed_strdup'
src/modules/rlm_eap/radeapclient.c:(.text+0x730): undefined reference to 
`dict_read'
src/modules/rlm_eap/radeapclient.c:(.text+0xbcc): undefined reference to 
`fr_pair_list_afrom_file'
src/modules/rlm_eap/radeapclient.c:(.text+0xc8c): undefined reference to 
`fr_debug_lvl'
src/modules/rlm_eap/radeapclient.c:(.text+0xcf0): undefined reference to 
`fr_debug_lvl'
src/modules/rlm_eap/radeapclient.c:(.text+0x1614): undefined reference to 
`fr_debug_lvl'
src/modules/rlm_eap/radeapclient.c:(.text+0x1634): undefined reference to 
`fr_debug_lvl'
src/modules/rlm_eap/radeapclient.c:(.text+0x1648): undefined reference to 
`fr_debug_lvl'
src/modules/rlm_eap/radeapclient.c:(.text+0x1690): undefined reference to 
`fr_pair_find_by_num'
src/modules/rlm_eap/radeapclient.c:(.text+0x16a8): undefined reference to 
`fr_pair_find_by_num'
src/modules/rlm_eap/radeapclient.c:(.text+0x16c4): undefined reference to 
`fr_pair_find_by_num'
src/modules/rlm_eap/radeapclient.c:(.text+0x18d8): undefined reference to 
`fr_pair_delete_by_num'
src/modules/rlm_eap/radeapclient.c:(.text+0x18ec): undefined reference to 
`fr_pair_delete_by_num'
src/modules/rlm_eap/radeapclient.c:(.text+0x1900): undefined reference to 
`fr_pair_delete_by_num'


when I tried opposite end and unset FLAVOR to build maximum build, I've been 
hit by the failure in gcc-4.9.4 build which shows as:

In file included from 
/usr/ports/pobj/gcc-4.9.4/gcc-4.9.4/gcc/c/c-objc-common.c:33:
In file included from /usr/include/c++/v1/new:70:
/usr/include/c++/v1/exception:267:5: error: no member named 'fancy_abort' in 
namespace 'std::__1'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~
/usr/include/c++/v1/__config:462:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
  ^
/usr/ports/pobj/gcc-4.9.4/gcc-4.9.4/gcc/system.h:685:13: note: 'fancy_abort' 
declared here
extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
^
1 error generated.
gmake[3]: *** [Makefile:1058: c/c-objc-common.o] Error 1
gmake[3]: Leaving directory '/usr/local/ports/pobj/gcc-4.9.4/build-arm/gcc'
gmake[2]: *** [Makefile:4217: all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/usr/local/ports/pobj/gcc-4.9.4/build-arm'
gmake[1]: *** [Makefile:17735: stage1-bubble] Error 2
gmake[1]: Leaving directory '/usr/local/ports/pobj/gcc-4.9.4/build-arm'
gmake: *** [Makefile:17872: bootstrap2] Error 2


I guess, no way to make freeradius3 on armv7, but still I'd like to ask for 
confirmation of this fact.

Thanks!
Karel

Re: Porting to ARMv8 (board, qemu, etc.)

[Karel Gardas]

On Mon, 29 Jan 2018 14:14:53 +0100
Patrick Wildt  wrote:

> I think those random segfaults might even be visible with qemu running
> on an x86 machine.  I'm not surprised.

I see a lot of random segfaults in qemu aarch64 on amd64/obsd, but then I'm 
quite curious why do you expect
the same on basically hardware based VM. I've though in this case qemu is just 
demonted to virtual disk/net
handler and CPU isns (at least user mode) are purely run on real hardware... So 
I would expect kernel crashes
in case of wrong virt-dev emulation but not user-land crashes...

Thanks!

Can't build python 3.6.4 on 6.2-current.

[Karel Gardas]

Hello,

while attempting to build lang/swi-prolog using dpb I've hit issue building 
python 3.6.4. The log
of python 3.6.4 build looks fine up to the moment of fake installation which 
fails with:

===> lang/python/3.6
===>  Faking installation for Python-3.6.4
install -d -m 755 /usr/ports/pobj/Python-3.6.4/fake-amd64
cd /usr/ports/lang/python/3.6 && umask 022 && PKGPATH=lang/python/3.6 exec  
/usr/bin/make _pre-fake-modules 
PATH='/usr/ports/pobj/Python-3.6.4/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin'
 TRUEPREFIX=/usr/local  
PREFIX=/usr/ports/pobj/Python-3.6.4/fake-amd64/usr/local 
DESTDIR=/usr/ports/pobj/Python-3.6.4/fake-amd64
Error: The source directory (/usr/ports/pobj/Python-3.6.4/Python-3.6.4) is not 
clean
Building Python out of the source tree (in 
/usr/local/ports/pobj/Python-3.6.4/Python-3.6.4) requires a clean source tree 
(/usr/ports/pobj/Python-3.6.4/Python-3.6.4)
Try to run: make -C "/usr/ports/pobj/Python-3.6.4/Python-3.6.4" clean
*** Error 1 in /usr/local/ports/pobj/Python-3.6.4/Python-3.6.4 (Makefile:467 
'check-clean-src')
*** Error 1 in /usr/ports/lang/python/3.6 
(/usr/ports/infrastructure/mk/bsd.port.mk:2837 
'/usr/ports/pobj/Python-3.6.4/fake-amd64/.fake_done')
*** Error 1 in /usr/ports/lang/python/3.6 
(/usr/ports/infrastructure/mk/bsd.port.mk:2419 'fake')
===> Exiting lang/python/3.6 with an error
*** Error 1 in /usr/local/ports 
(/usr/ports/infrastructure/mk/bsd.port.subdir.mk:147 'fake')
Error: job failed with 256 on localhost


Is it a known issue or am I doing anything stupid? Dpb was invoked as root from 
/usr/ports with:

./infrastructure/bin/dpb /home/karel/src/swi-prolog.txt

where cat /home/karel/src/swi-prolog.txt shows:

fujitsu# cat /home/karel/src/swi-prolog.txt   
lang/swi-prolog
fujitsu# 

I'm just curious since I'd like to be able to have reference ports builder here 
to detect any issues while hacking on OpenBSD header files...

6.2-current is from yesterday, ports tree is fresh from today.

Thanks!
Karel

Porting to ARMv8 (board, qemu, etc.)

[Karel Gardas]

Hello,

I'd like to help a bit with GHC work on OpenBSD and would like to give it a try
to port GHC to ARMv8. GHC is a beast so I assume I'll need machine/emulator
with 4GB RAM at least. I'm curious what you guys are using for running all those
ARMv8 packages builders and for your own porting efforts?

so far I see following options:

- qemu-system-aarch64 running on OpenBSD/amd64. I've verified qemu distributed 
with 6.2-current
  is well capable of running Ubuntu cloud image 16.04 for ARMv8. The question 
is, has anybody
  here tested that or get OpenBSD/arm64 running on Qemu? The advantage of this 
solution is flexibility
  especially in choosing the right amount of RAM although it may not be speed 
daemon of course

- firefly rk3399 4GB RAM version. Board looks nice, cortex-a72 @ 2GHz should be 
quite capable especially
  if paired with SATA drive(s) or NVMe on PCIe. The questions are:
  - is cortex-a72 run (i.e. utilized) by OpenBSD? Is SMP supported?
  - has anobody tried running it with NVMe card in PCIe slot (if so which one?) 
or with SATA/PCIe adapter
and SATA drive(s) hooked to it (preferably using firefly's ASM1061 based 
PCIe to SATA3 adapter)?
  - any distributor in EU? Or what's your recommended way to purchase this in 
EU?

- cloud/kvm solution. There are several cloud provides already 
selling/supporting Cavium ThunderX
  and for quite cheap money. Anyone has a luck with this solution? I guess 
OpenBSD would need to run on
  qemu-system-aarch64 first to support all those kvm/virtio devices needed and 
then grabed to cloud, but still
  any chance?

So I'm looking for as pain-less as possible way to get OpenBSD running on some 
4GB arm64 either hardware or software
to dig into GHC hacking.

Any help with this appreciated!

Thanks!
Karel

Re: update lang/ghc (preview)

[Karel Gardas]

On Sat, 16 Dec 2017 03:40:28 +0100
Matthias Kilian <k...@outback.escape.de> wrote:

> Hi,
> 
> On Thu, Dec 14, 2017 at 03:14:36PM +0100, Karel Gardas wrote:
> > <k...@outback.escape.de> wrote:
> > > Hi to all Haskell fans,
> > >
> > > the diff below updates ghc to 8.2.2.Builds, packages, and correctly
> > 
> > I'm trying todays's CVS and patching with:
> > 
> > cd /usr/ports/lang/ghc
> > patch < /tmp/original_msg.txt
> > 
> > where original_msg.txt is download of email and this fails misserably
> > with a lot of hunk errors and stops on:
> > 
> > |Index: patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Utils_hs
> 
> Then whatever you had in /tmp/original_msg.txt wasn't from my mail.
> 

The problem was in using gmail.com web interface. This thing throws on me patch 
with DOS line-endings and patch does not like that.
This happen also in case of your patch attachment so I investigated a bit since 
I was curious what the h*ll is going on.

Anyway, with using proper MUA, I've been able to get the patch correctly, apply 
it and build ghc-8.2.2 fine.

Fantastic work!

Thanks!
Karel

Re: update lang/ghc (preview)

[Karel Gardas]

On Wed, Dec 13, 2017 at 12:28 AM, Matthias Kilian
 wrote:
> Hi to all Haskell fans,
>
> the diff below updates ghc to 8.2.2.Builds, packages, and correctly

I'm trying todays's CVS and patching with:

cd /usr/ports/lang/ghc
patch < /tmp/original_msg.txt

where original_msg.txt is download of email and this fails misserably
with a lot of hunk errors and stops on:

|Index: patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Utils_hs
|===
|RCS file: 
/cvs/ports/lang/ghc/patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Utils_hs,v
|retrieving revision 1.3
|diff -u -p -r1.3 patch-libraries_Cabal_Cabal_Distribution_Simple_Utils_hs
|--- patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Utils_hs
 19 Sep 2015 07:42:57 -  1.3
|+++ patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Utils_hs
 2 Nov 2016 11:17:56 -
--
File to patch:


do you have any idea how to apply your changes for testing? Thanks! Karel

Re: Unbreak ghc

[Karel Gardas]

> Curious how far my current build of ghc-8.2.2 will go...

8.2 and later, including HEAD should be better and better. I've done
some work on this (mainly passing your patches to the HEAD of that
time) and also some core GHC developers (Ben Gamari IIRC) are testing
on OpenBSD (latest release) now, so I think your life as GHC
maintainer should be more easier.

Completely other matter is:
- GHC memory allocation strategy -- big mmap where it is supported
- GHC RWX memory usage, hence wxneeded
- GHC/base usage of unsafe string primitives

Thanks,
Karel

Re: Unbreak ghc

[Karel Gardas]

On Sun, Dec 10, 2017 at 9:52 PM, Matthias Kilian <k...@outback.escape.de> wrote:
> Hi Karel,
>
> On Sun, Dec 10, 2017 at 08:22:54PM +0100, Karel Gardas wrote:
>> rts/Linker.c includes elf.h for all platform except OpenBSD where it
>> includes elf_abi.h. In recent snapshots elf_abi.h got removed thanks
>> to work of Martin Pieuchot.
>
> But it's still there, even in todays snapshots:
>
> $ tar tvzf comp62.tgz ./usr/include/elf\*
> -r--r--r--  1 root bin166 Dec 10 19:09 ./usr/include/elf.h
> -r--r--r--  1 root bin   1627 Dec 10 19:09 ./usr/include/elf_abi.h
>
> And the same is true for a release(8) i just built on my build
> machine.
>
> Maybe you used a snapshot with elf_abi.h missing (intentionally or not).?

Obviously I'm stupid fool. Probably I've removed elf_abi.h myself for
some ports/tests and then completely forgotten this and then seeing
GHC failing so reported that including patch. Sorry for this noise!

Re: Unbreak ghc

[Karel Gardas]

rts/Linker.c includes elf.h for all platform except OpenBSD where it
includes elf_abi.h. In recent snapshots elf_abi.h got removed thanks
to work of Martin Pieuchot. This way, rts/Linker.c includes
non-existent .h file which fails. My "fix" for now is simple to just
s/elf_abi/elf and be done with this for now. As you may see in the
OpenBSD related define there are other things missing in OpenBSD's elf
support, but I'm plan for reviewing this in the future anyway -- hence
my minimalistic way of fixing for now.

If your plans are different, then go ahead with whatever you plan and
do not keep looking back at all.

Thanks! Karel

On Wed, Dec 6, 2017 at 11:20 PM, Matthias Kilian <k...@outback.escape.de> wrote:
> Hi Karel,
>
> On Mon, Dec 04, 2017 at 11:09:33PM +0100, Karel Gardas wrote:
>> attached patch unbreaks GHC compilation issue on snapshot. I would
>> rather keep that simple/stupid before cleaning more those bits in
>> OpenBSD #ifdef. Good for now IMHO.
>
> Well, src and the snapshot i tried yesterday contain both elf.h and
> elf_abi.h, which both do only #include .
>
> So I don't see the point to apply this one *now* to rts/Linker.c
>
> +-#  include 
> ++#  include 
>
> It may be needed in the future, but I'd like to do this for ghc-8.2
> (which *may* happen this year, if it doesn't require too many updates
> or patches for our existing hs-ports).
>
> Why/how did the build break for you?
>
> Ciao,
> Kili

Re: Unbreak ghc

[Karel Gardas]

On Tue, Dec 5, 2017 at 12:19 AM, Matthias Kilian <k...@outback.escape.de> wrote:
> Hi Karel,
>
> On Mon, Dec 04, 2017 at 11:09:33PM +0100, Karel Gardas wrote:
>> attached patch unbreaks GHC compilation issue on snapshot. I would
>> rather keep that simple/stupid before cleaning more those bits in
>> OpenBSD #ifdef. Good for now IMHO.
>
> Thanks for your patch. I'll have a look on wednesday. At the moment,
> I'm trying to build new boostrappers based on ghc-8.0 (to proceed
> to 8.2), on a not-so-recent -current.

Cool! Having 8.2 would be nice. Thanks for your work on this! Karel

Unbreak ghc

[Karel Gardas]

Hi,

attached patch unbreaks GHC compilation issue on snapshot. I would
rather keep that simple/stupid before cleaning more those bits in
OpenBSD #ifdef. Good for now IMHO.

Thanks,
Karel


ghc.patch
Description: Binary data

Re: Port bulk with

[Karel Gardas]

Hi,

I've update my elf.h transition patch and posted on tech@ here
https://marc.info/?l=openbsd-tech=150551268819592=2 -- I'm running
ports build on my testing machine, but it's not that fast and I'm
neither experience ports builder so I would welcome if anybody can
give it a try on somewhat more reference ports build setup. Please
note that after patch/build you would need to cp /usr/include/elf.h
/usr/include/elf_abi.h in order to make those ports assuming elf_abi.h
presence on OpenBSD to build correctly (E.g. ghc). The point here is
to check if content of included /usr/include/sys/exec_elf.h is correct
enough for ports to build.

This patch version already solves devel/libdwarf and devel/valgrind
issues seen by Christian.

My current dpb progress looks:
I= B=642 Q=3350 T=1942 F=0 !=100
E=mail/mozilla-thunderbird,,-main www/seamonkey,,-main
games/ioquake3:ioquake3-2017.08.03-59b1262b.tar.gz
fonts/fira-fonts:fira-fonts-20170227-a6069274.tar.gz
games/doomdata/doom1 games/doomdata/
doom2

where thunderbird and seamonkey fails strangely on python related
issue which does not seems to be related to elf.h change. See below.
This is also the reason I do not trust that much my ports build
abilities and would welcome if someone more experience with ports
building would give the patch a try.

Thanks!
Karel



>>> Running configure in www/seamonkey,,-main at 1505546419
===> www/seamonkey,,-main
===>  Configuring for seamonkey-2.48
Creating Python environment
New python executable in
/usr/local/ports/pobj/seamonkey-2.48/build-amd64/_virtualenv/bin/python2.7
Also creating executable in
/usr/local/ports/pobj/seamonkey-2.48/build-amd64/_virtualenv/bin/python
Installing setuptools, pip, wheel...done.
platform openbsd6 is not supported

Error processing command. Ignoring because optional.
(optional:setup.py:python/psutil:build_ext:--inplace)
Reexecuting in the virtualenv
Traceback (most recent call last):
  File "/usr/ports/pobj/seamonkey-2.48/seamonkey-2.48/configure.py",
line 32, in 
sys.exit(main(sys.argv))
  File "/usr/ports/pobj/seamonkey-2.48/seamonkey-2.48/configure.py",
line 24, in main
sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure'))
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/configure/__init__.py",
line 231, in run
self.include_file(path)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/configure/__init__.py",
line 222, in include_file
exec_(code, self)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/util.py",
line 59, in exec_
exec(object, globals, locals)
  File "/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/moz.configure",
line 7, in 
include('mozilla/moz.configure')
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/configure/__init__.py",
line 477, in include_impl
self.include_file(what)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/configure/__init__.py",
line 222, in include_file
exec_(code, self)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/util.py",
line 59, in exec_
exec(object, globals, locals)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/moz.configure",
line 7, in 
include('build/moz.configure/init.configure')
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/configure/__init__.py",
line 477, in include_impl
self.include_file(what)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/configure/__init__.py",
line 222, in include_file
exec_(code, self)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/util.py",
line 59, in exec_
exec(object, globals, locals)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/build/moz.configure/init.configure",
line 787, in 
include(include_project_configure)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/configure/__init__.py",
line 477, in include_impl
self.include_file(what)
  File 
"/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48/mozilla/python/mozbuild/mozbuild/configure/__init__.py",
line 209, in include_file
'of `%s`' % (path, mozpath.dirname(self._paths[0])))
mozbuild.configure.ConfigureError: Cannot include
`/usr/ports/pobj/seamonkey-2.48/seamonkey-2.48/suite/moz.configure`
because it is not in a subdirectory of
`/usr/local/ports/pobj/seamonkey-2.48/seamonkey-2.48`
*** Error 1 in /usr/ports/www/seamonkey
(/usr/ports/infrastructure/mk/bsd.port.mk:2694
'/usr/ports/pobj/seamonkey-2.48/build-amd64/.configure_done')
*** Error 1 in /usr/ports/www/seamonkey
(/usr/ports/infrastructure/mk/bsd.port.mk:2420 'configure')
===> Exiting www/seamonkey,,-main with an error
*** Error 1 

Re: Port bulk with

[Karel Gardas]

My elf.h patch solves devel/libdwarf compilation issue, but
devel/valgrind still fails due to:

m_coredump/coredump-elf.c:764:32: error: use of undeclared identifier
'NT_PRPSINFO'
   add_note(, "CORE", NT_PRPSINFO, , sizeof(prpsinfo));

the problem is NT_PRPSINFO is not standardized in elf spec so the
question is if I shall add this to sys/exec_elf.h or we can also
define it inside the coregrind/m_coredump/
coredump-elf.c which already contains definition for NT_PRXFPREG which
is from the same family of "common" elf defines for core files...

What's the preference in such a case?

On Tue, Sep 12, 2017 at 4:23 PM, Christian Weisgerber
 wrote:
> Martin Pieuchot:
>
>> > So here's a first step, introducing /usr/include/elf.h.  Could some of
>> > you run a bulk with it and report the possible breakages?
>>
>> Now that the offending function declaration has been remove from libc
>> libelf builds as before.
>>
>> Could you guys tell us if there's any other fallout from this diff?
>
> On amd64, two ports failed to build: devel/libdwarf and devel/valgrind.
>
> ===> devel/libdwarf
> print_reloc.c:150:10: error: use of undeclared identifier 'EM_PPC64'
> case EM_PPC64:
>  ^
>
> ===> devel/valgrind
> m_coredump/coredump-elf.c:105:22: error: use of undeclared identifier
> 'EM_X86_64'
>ehdr->e_machine = VG_ELF_MACHINE;
>  ^
> ./pub_core_machine.h:51:31: note: expanded from macro 'VG_ELF_MACHINE'
> #  define VG_ELF_MACHINE  EM_X86_64
>   ^
>
> --
> Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Port bulk with

[Karel Gardas]

Both those issues should be solved by my bigger elf.h patch. E.g. it
defines both EM_PPC64 and EM_X86_64. I'll merge latest git and
resubmit for review again.

On Tue, Sep 12, 2017 at 4:23 PM, Christian Weisgerber
 wrote:
> Martin Pieuchot:
>
>> > So here's a first step, introducing /usr/include/elf.h.  Could some of
>> > you run a bulk with it and report the possible breakages?
>>
>> Now that the offending function declaration has been remove from libc
>> libelf builds as before.
>>
>> Could you guys tell us if there's any other fallout from this diff?
>
> On amd64, two ports failed to build: devel/libdwarf and devel/valgrind.
>
> ===> devel/libdwarf
> print_reloc.c:150:10: error: use of undeclared identifier 'EM_PPC64'
> case EM_PPC64:
>  ^
>
> ===> devel/valgrind
> m_coredump/coredump-elf.c:105:22: error: use of undeclared identifier
> 'EM_X86_64'
>ehdr->e_machine = VG_ELF_MACHINE;
>  ^
> ./pub_core_machine.h:51:31: note: expanded from macro 'VG_ELF_MACHINE'
> #  define VG_ELF_MACHINE  EM_X86_64
>   ^
>
> --
> Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Port bulk with

[Karel Gardas]

On Thu, Aug 10, 2017 at 9:45 PM, Karel Gardas <gard...@gmail.com> wrote:
> I updated my current to today snapshot and still with original full
> version of elf.h patch libelf builds fine -- see below. By quick
> comparison of configure outputs in Christian's and mine build it looks
> like he gets:
>
> checking if cc can compile elf.h... yes
>
> while I get:
>
> checking if cc can compile elf.h... no
>
> which is probably the reason (or one of) behind the failure for you
> and not failure for me...

config.log is clear about that:

configure:1231: checking if cc can compile elf.h
configure:1248: cc -c -O2 -pipe  conftest.c 1>&5
In file included from configure:1239:
In file included from /usr/include/elf.h:31:
/usr/include/sys/exec_elf.h:53:9: error: unknown type name
'__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t  Elf32_Addr; /* Unsigned program address */
^
note: '__uint128_t' declared here
/usr/include/sys/exec_elf.h:54:9: error: unknown type name
'__uint32_t'; did you mean '__uint128_t'?
typedef __uint32_t  Elf32_Off;  /* Unsigned file offset */
^
note: '__uint128_t' declared here
/usr/include/sys/exec_elf.h:55:9: error: unknown type name
'__uint16_t'; did you mean '__uint128_t'?
typedef __uint16_t  Elf32_Half; /* Unsigned medium integer */
^
[...]

probably the culprit here is my removal of  include from
sys/exec_elf.h which is presented in full patch version while missing
from current OpenBSD.

Re: Port bulk with

[Karel Gardas]

I updated my current to today snapshot and still with original full
version of elf.h patch libelf builds fine -- see below. By quick
comparison of configure outputs in Christian's and mine build it looks
like he gets:

checking if cc can compile elf.h... yes

while I get:

checking if cc can compile elf.h... no

which is probably the reason (or one of) behind the failure for you
and not failure for me...

$ doas make
===> libelf-0.8.13p3 depends on: metaauto-* -> metaauto-1.0p1
===> libelf-0.8.13p3 depends on: autoconf-2.13 -> autoconf-2.13p4
===>  Checking files for libelf-0.8.13p3
`/usr/ports/distfiles/libelf-0.8.13.tar.gz' is up to date.
>> (SHA256) libelf-0.8.13.tar.gz: OK
===>  Extracting for libelf-0.8.13p3
===>  Patching for libelf-0.8.13p3
===>   Applying OpenBSD patch patch-aclocal_m4
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|$OpenBSD: patch-aclocal_m4,v 1.4 2012/05/19 08:24:50 sthen Exp $
|--- aclocal.m4.origFri May 23 04:17:56 2008
|+++ aclocal.m4 Fri May 18 22:53:37 2012
--
Patching file aclocal.m4 using Plan A...
Hunk #1 succeeded at 288.
done
===>  Compiler link: cc -> /usr/bin/cc
===>  Compiler link: c++ -> /usr/bin/c++
Running autoconf-2.13 in /usr/ports/pobj/libelf-0.8.13/libelf-0.8.13
Running autoheader-2.13 in /usr/ports/pobj/libelf-0.8.13/libelf-0.8.13
===>  Configuring for libelf-0.8.13p3
Using /usr/ports/pobj/libelf-0.8.13/config.site (generated)
loading site script /usr/ports/pobj/libelf-0.8.13/config.site
creating cache ./config.cache
checking whether make sets ${MAKE}... (cached) yes
checking for gcc... cc
checking whether the C compiler (cc -O2 -pipe ) works... yes
checking whether the C compiler (cc -O2 -pipe ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether cc accepts -g... (cached) yes
checking how to run the C preprocessor... cc -E
checking for a BSD compatible install...
/usr/ports/pobj/libelf-0.8.13/bin/install -c
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for ANSI C header files... (cached) yes
checking for unistd.h... (cached) yes
checking for stdint.h... (cached) yes
checking for fcntl.h... (cached) yes
checking for elf.h... yes
checking for sys/elf.h... no
checking for link.h... yes
checking for sys/link.h... no
checking if cc can compile elf.h... no
checking for ar.h... yes
checking for libelf.h... no
checking for nlist.h... (cached) yes
checking for gelf.h... no
checking whether to install ,  and ... no
checking for working const... (cached) yes
checking for off_t... (cached) yes
checking for size_t... (cached) yes
checking size of short... (cached) 2
checking size of int... 4
checking size of long... 8
checking size of long long... (cached) 8
checking size of __int64... 0
checking for 64-bit integer... long
checking for 32-bit integer... int
checking for 16-bit integer... short
checking for unistd.h... (cached) yes
checking for getpagesize... (cached) yes
checking for working mmap... (cached) yes
checking for ftruncate... (cached) yes
checking for memcmp... (cached) yes
checking for memcpy... (cached) yes
checking for memmove... (cached) yes
checking for memset... (cached) yes
checking whether overlapping arrays are copied correctly... yes
checking the coffee machine... empty - operator may not work as expected
checking whether 64-bit ELF support is sufficient... yes
checking whether to include 64-bit support... yes
checking whether versioning support is sufficient... yes
checking whether to include versioning support... yes
checking whether NLS is requested... no
checking for gettext in -lintl... no
checking host system type... x86_64-unknown-openbsd6.1
checking whether to build a shared library... yes
checking whether GNU naming conventions are requested... no
checking for ld... /usr/bin/ld
updating cache ./config.cache
creating ./config.status
creating Makefile
creating lib/Makefile
creating po/Makefile
creating libelf.pc
creating config.h
creating lib/sys_elf.h
===>  Building for libelf-0.8.13p3
making all in lib
if test -n "-fPIC -DPIC"; then  cc -c -DHAVE_CONFIG_H -I.. -I. -I.
-O2 -pipe  -fPIC -DPIC begin.c && mv -f begin.o begin.os;  else true;
fi
begin.c:110:20: warning: comparison of unsigned expression < 0 is
always false [-Wtautological-compare]
if (arf->e_off < 0 || arf->e_off > arf->e_size) {
~~ ^ ~
begin.c:142:14: warning: comparison of unsigned expression < 0 is
always false [-Wtautological-compare]
if (tmp < 0 || tmp >= arf->e_strlen) {
~~~ ^ ~
2 warnings generated.
cc -c -DHAVE_CONFIG_H -I.. -I. -I.  -O2 -pipe  begin.c
begin.c:110:20: warning: comparison of unsigned expression < 0 is
always false [-Wtautological-compare]
if (arf->e_off < 0 || arf->e_off > arf->e_size) {
~~ ^ ~
begin.c:142:14: warning: comparison of unsigned expression < 0 is
always false [-Wtautological-compare]
if (tmp < 0 || tmp >= 

Re: [new] devel/gas

[Karel Gardas]

On Sun, Jul 16, 2017 at 11:50 AM, Stuart Henderson  wrote:
> On 2017/07/15 16:37, Pascal Stumpf wrote:
>> This is a port of the latest version of GAS from GNU binutils, at the
>> moment for the sole purpose of providing an assembler for the upcoming
>> GCC 7 port on Aarch64.
>>
>> ok?
>
> Is this needed when we have gas in arm-none-eabi-binutils? (kettenis has
> an update pending if this just needs a newer version).

I think so, since arm-none-eabi is probably just for AArch32 and also
specifically bare metal development, while what Pascal Stumpf provides
is gas for aarch64-openbsd platform. IIRC binutils are always compiled
for specific ABI and you can't simply retarget based on some command
line options (except in very specific cases on specific variant of one
platform).

Re: ghc.port.mk (was: Ports with hardcoded "gcc", "g++")

[Karel Gardas]

On Thu, Mar 2, 2017 at 9:23 PM, Matthias Kilian  wrote:
> Also, I've no idea wether --with-clang=${CC} will work after the
> switch to clang. On the other hand, the diff is just a workaround,

> +MODGHC_SETUP_CONF_ARGS +=  --with-gcc=${CC} --with-clang=${CC}


Hi Kili,

I'm curious why this is there at all, I mean --with-clang=${CC} -- if
I understand policy, then i386/amd64 are not going to be migrated to
clang anytime soon and clang is default only for arm64 (new port which
is not supported by in tree gcc) where ghc does not exist yet. So my
curiosity and question why to bother with it at all?

Thanks,
Karel

Re: My first porting attempt: part 3

[Karel Gardas]

Passing -llibobs.so.0 to linker means that linker will try to link
liblibobps.so.0.so IMHO. Please give a try to -lobs

On Mon, Jan 9, 2017 at 3:08 AM, Jordon  wrote:
> Part 1: Learning that trying to build an un-ported project outside of the 
> ports make system is a waste of time.  I started reading the porters handbook 
> and was blown away at how nice the ports build system is.  After a few 
> attempts, I was getting the prerequisites installed and starting the build of 
> the target project!
>
> Part 2: Leaning that OpenBSD does not have a wrapper for sys info.h.  In 
> digging into this, I found that it is only used to get the amount of physical 
> RAM to dump to a log.  That’s it.  I just commented it out for now with an 
> intent to come back later and figure out the OpenBSD way to do this.
>
> Part 3: After applying a couple other patches (OpenBSD does not have 
> gzclose_w() so use gzclose() instead, and a struct that had elements for 
> Windows OR linux/FreeBSD so I added Openbsd to the ifdef list), I came across 
> an error that has me puzzled.  I also noticed a few things that raised a few 
> questions.
>
> When my project is built, each file has a counter in front of it (such as 
> [137/242]).  Is this something from the make build system or is it something 
> from the project i am building?
>
> Also, when I got the error, I noticed that if I immediately did a ‘make 
> build’ again, it would build a few more (as in, in the [x/y] counter, the y 
> would be a bit smaller).  Doing this over and over would slowly decrement the 
> number of remaining files to a point at which it stopped decrementing.  This 
> makes the build seem… nondeterministic?  Is this just a function of a 
> parallel build system that stops whenever it sees an error?
>
> And for the main build issue I am seeing… Here is a dump from the output:
>
> 141/242] : && /usr/ports/pobj/obs-studio-17.0.0/bin/cc  -fPIC -Wall -Wextra 
> -Wno-unused-function -Werror-implicit-function-declaration 
> -Wno-missing-braces -Wno-missing-field-initializers -O2 -pipe -std=gnu99 
> -fno-strict-aliasing -DNDEBUG   -shared -o 
> plugins/rtmp-services/rtmp-services.so 
> plugins/rtmp-services/CMakeFiles/rtmp-services.dir/rtmp-common.c.o 
> plugins/rtmp-services/CMakeFiles/rtmp-services.dir/rtmp-custom.c.o 
> plugins/rtmp-services/CMakeFiles/rtmp-services.dir/rtmp-services-main.c.o 
> -L/usr/ports/pobj/obs-studio-17.0.0/build-amd64/libobs  
> -L/usr/local/bin/../lib 
> -Wl,-rpath,/usr/ports/pobj/obs-studio-17.0.0/build-amd64/libobs: 
> deps/file-updater/libfile-updater.a deps/jansson/lib/libjansson.a 
> -llibobs.so.0 -pthread -lcurl -Wl,-rpath-link,/usr/X11R6/lib && cd 
> /usr/ports/pobj/obs-studio-17.0.0/build-amd64/plugins/rtmp-services && 
> /usr/local/bin/cmake -E copy 
> /usr/ports/pobj/obs-studio-17.0.0/build-amd64/plugins/rtmp-services/rtmp-services.so
>  
> /usr/ports/pobj/obs-studio-17.0.0/build-amd64/rundir/Release/obs-plugins/64bit/rtmp-services.so
>  && cd /usr/ports/pobj/obs-studio-17.0.0/build-amd64/plugins/rtmp-services && 
> /usr/local/bin/cmake -E copy_directory 
> /usr/ports/pobj/obs-studio-17.0.0/obs-studio-17.0.0/plugins/rtmp-services/data
>  
> /usr/ports/pobj/obs-studio-17.0.0/build-amd64/rundir/Release/data/obs-plugins/rtmp-services
> FAILED: plugins/rtmp-services/rtmp-services.so
> : && /usr/ports/pobj/obs-studio-17.0.0/bin/cc  -fPIC -Wall -Wextra 
> -Wno-unused-function -Werror-implicit-function-declaration 
> -Wno-missing-braces -Wno-missing-field-initializers -O2 -pipe -std=gnu99 
> -fno-strict-aliasing -DNDEBUG   -shared -o 
> plugins/rtmp-services/rtmp-services.so 
> plugins/rtmp-services/CMakeFiles/rtmp-services.dir/rtmp-common.c.o 
> plugins/rtmp-services/CMakeFiles/rtmp-services.dir/rtmp-custom.c.o 
> plugins/rtmp-services/CMakeFiles/rtmp-services.dir/rtmp-services-main.c.o 
> -L/usr/ports/pobj/obs-studio-17.0.0/build-amd64/libobs  
> -L/usr/local/bin/../lib 
> -Wl,-rpath,/usr/ports/pobj/obs-studio-17.0.0/build-amd64/libobs: 
> deps/file-updater/libfile-updater.a deps/jansson/lib/libjansson.a 
> -llibobs.so.0 -pthread -lcurl -Wl,-rpath-link,/usr/X11R6/lib && cd 
> /usr/ports/pobj/obs-studio-17.0.0/build-amd64/plugins/rtmp-services && 
> /usr/local/bin/cmake -E copy 
> /usr/ports/pobj/obs-studio-17.0.0/build-amd64/plugins/rtmp-services/rtmp-services.so
>  
> /usr/ports/pobj/obs-studio-17.0.0/build-amd64/rundir/Release/obs-plugins/64bit/rtmp-services.so
>  && cd /usr/ports/pobj/obs-studio-17.0.0/build-amd64/plugins/rtmp-services && 
> /usr/local/bin/cmake -E copy_directory 
> /usr/ports/pobj/obs-studio-17.0.0/obs-studio-17.0.0/plugins/rtmp-services/data
>  
> /usr/ports/pobj/obs-studio-17.0.0/build-amd64/rundir/Release/data/obs-plugins/rtmp-services
> /usr/bin/ld: cannot find -llibobs.so.0
> collect2: error: ld returned 1 exit status
> ninja: build stopped: subcommand failed.
>
> I think the ultimate error is "/usr/bin/ld: cannot find -llibobs.so.0”.
> However, the same command has 
> 

Re: gcc4.9 and _Unwind_Resume segfaults

[Karel Gardas]

On Wed, Dec 21, 2016 at 11:24 PM, Paul Irofti  wrote:
>> the port (if everything there is C++-based, tweaking CONFIGURE_ENV
>
> Teach me how :)
>
> It doesn't work with this
>
> CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include -I${X11BASE}/include \
> -I${LOCALBASE}/include/ereadline" \
> LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib -lestdc++" \
> LRELEASE="${MODQT_LRELEASE}" \
> F77=${FC}

Shouldn't c++ app be linked with using eg++ which should put -lestdc++
implicitly there without a need to do that on the command-line?

Re: powerpc bulk build report

[Karel Gardas]

Proposed fix for LLVM build failure described here:
https://marc.info/?l=openbsd-ports=147959032027364=2 -- don't have
ppc here so I can't even test that so this is more for someone with
the powerpc/openbsd platform and interest in LLVM...

On Sun, Dec 4, 2016 at 1:01 AM,   wrote:
> bulk build on macppc-1.ports.openbsd.org
> started on  Mon Nov 21 15:33:07 MST 2016
> finished at Sat Dec 3 17:00:57 MST 2016
> lasted 12D18h27m
> done with kern.version=OpenBSD 6.0-current (GENERIC.MP) #0: Thu Nov 17 
> 20:48:33 MST 2016
>
> built packages:7566
> Nov 21:600
> Nov 22:316
> Nov 23:695
> Nov 24:412
> Nov 25:389
> Nov 26:317
> Nov 27:310
> Nov 28:387
> Nov 29:317
> Nov 30:467
> Dec 1:398
> Dec 2:458
> Dec 3:2499
>
>
>
> build failures: 9
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/audio/moc.log
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/devel/llvm.log
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/devel/reposurgeon.log
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/emulators/snes9x.log
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/graphics/tesseract/tessdata,-afr.log
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/lang/guile2.log
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/lang/node.log
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/math/py-bottleneck,python3.log
> http://build-failures.rhaalovely.net//powerpc/2016-11-21/www/pear.log
>
> recurrent failures
>  failures/audio/moc.log
>  failures/devel/llvm.log
>  failures/devel/reposurgeon.log
>  failures/graphics/tesseract/tessdata,-afr.log
>  failures/lang/guile2.log
>  failures/lang/node.log
>  failures/www/pear.log
> new failures
> +++ ls-failures Sat Dec  3 17:01:22 2016
> +failures/emulators/snes9x.log
> +failures/math/py-bottleneck,python3.log
> resolved failures
> --- ../old/powerpc/last//ls-failuresSat Nov 19 13:19:21 2016
> -failures/databases/openldap23.log
> -failures/editors/emacs21.log
> -failures/news/slrn.log
> -failures/security/py-cryptography.log
> Base libs:
> curses.14.0 edit.5.2 event.4.1 expat.11.0 form.6.0 formw.6.0 fuse.1.1
> iberty.12.0 menu.6.0 menuw.6.0 ncurses.14.0 ncursesw.14.0 objc.6.0
> ossaudio.4.0 panel.6.0 panelw.6.0 perl.17.1 readline.4.0 rpcsvc.2.0
> skey.6.0 radius.1.0 sndio.6.1 stdc++.57.0 termcap.14.0 .14.0 z.5.0
> usbhid.7.0 util.12.1 pthread.23.0 c.89.2 c.89.2.a kvm.16.2 m.10.0
> crypto.40.0 pcap.8.2 ssl.41.0 tls.13.0
>
> X libs:
> EGL.1.0 FS.10.0 GLESv1_CM.1.0 GLU.9.0 GLw.6.0 ICE.10.0 SM.9.0
> X11-xcb.2.0 X11.16.1 XRes.5.0 Xau.10.0 Xaw.15.0 Xaw7.15.0 Xcomposite.4.0
> Xcursor.5.0 Xdamage.4.0 Xdmcp.11.0 Xext.13.0 Xfixes.6.0 Xfontcache.5.0
> Xi.12.1 Xinerama.6.0 Xmu.11.0 Xmuu.6.0 Xpm.9.0 Xrender.6.0 Xss.6.0
> Xt.11.0 Xtst.11.0 Xv.6.0 XvMC.6.0 XvMCW.2.0 Xxf86dga.6.0 dmx.2.0
> Xxf86misc.6.0 Xxf86vm.6.0 fontenc.4.0 epoxy.2.0 gbm.0.0 pciaccess.2.0
> pixman-1.32.6 pthread-stubs.2.0 txc_dxtn.0.0 xcb-composite.1.0
> xcb-damage.1.0 xcb-dpms.1.0 xcb-dri2.1.1 xcb-dri3.0.0 xcb-ewmh.2.0
> xcb-cursor.0.0 xcb-icccm.4.0 xcb-image.2.0 xcb-res.1.1 xcb-keysyms.3.0
> xkbui.5.0 xcb-shm.1.1 xcb-xevie.1.0 xcb-xf86dri.2.0 xcb-util.0.0
> xcb-xinerama.1.0 xcb-xtest.1.0 xcb-xvmc.1.0 xkbfile.6.0 Xrandr.7.1
> XvMCr600.1.0 xcb-render-util.2.0 drm_amdgpu.1.1 drm_nouveau.3.0
> drm_radeon.4.0 GL.17.0 GLESv2.1.1 OSMesa.10.0 Xfont.13.0 Xft.10.0
> glapi.0.2 fontconfig.11.0 xcb-glx.1.1 xcb-randr.2.2 xcb-present.0.1
> xcb-record.1.1 xcb-render.1.1 xcb-screensaver.1.1 xcb-shape.1.1
> xcb-sync.1.2 xcb-xfixes.1.2 xcb-xkb.0.1 xcb-xprint.3.0 xcb-xv.1.1
> xcb.4.0 drm.7.2 freetype.27.0 xcb-xrm.0.0
>

Re: powerpc bulk build report

[Karel Gardas]

llvm failure seems to be related to atomic functions being located in
libatomic on powerpc. LDFLAGS=-latomic should perhaps help here. I
don't have this platform myself so can someone please test? Thanks!

On Sat, Nov 19, 2016 at 9:19 PM,   wrote:
> http://build-failures.rhaalovely.net//powerpc/2016-11-07/devel/llvm.log

Re: Eclipse not working

[Karel Gardas]

This is an old beast, I would certainly try with older JVM, 1.7 or
even 1.6, something known at the time of 3.2.x release.

On Thu, Nov 17, 2016 at 8:06 AM, Fernando Cruz  wrote:
> Hi list,
>
> I install the eclipse-sdk-3.2.2p24 package, but when I trying to run
> give me the following error at
>
> !SESSION 2016-11-17 00:51:16.868 
> ---
> eclipse.buildId=M20070212-1330
> java.version=1.8.0_72
> java.vendor=Oracle Corporation
> BootLoader constants: OS=openbsd, ARCH=x86_64, WS=gtk, NL=en_US
> Command-line arguments:  -os openbsd -ws gtk -arch x86_64
>
> !ENTRY org.eclipse.equinox.common 4 0 2016-11-17 00:51:17.352
> !MESSAGE FrameworkEvent.ERROR
> !STACK 0
> org.osgi.framework.BundleException: The bundle could not be resolved.
> Reason: Missing Constraint: Bundle-RequiredExecutionEnvironment:
> CDC-1.0/Foundation-1.0,J2SE-1.3
> at 
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:294)
> at 
> org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:329)
> at 
> org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1046)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:573)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:495)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:275)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:455)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:189)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:291)
>
> !ENTRY org.eclipse.update.configurator 4 0 2016-11-17 00:51:17.356
> !MESSAGE FrameworkEvent.ERROR
> !STACK 0
> org.osgi.framework.BundleException: The bundle could not be resolved.
> Reason: Missing Constraint: Bundle-RequiredExecutionEnvironment:
> J2SE-1.4,CDC-1.0/Foundation-1.0,J2SE-1.3
> at 
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:294)
> at 
> org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:329)
> at 
> org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1046)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:573)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:495)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:275)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:455)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:189)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:291)
>
> !ENTRY org.eclipse.core.runtime 4 0 2016-11-17 00:51:17.357
> !MESSAGE FrameworkEvent.ERROR
> !STACK 0
> org.osgi.framework.BundleException: The bundle could not be resolved.
> Reason: Missing Constraint: Bundle-RequiredExecutionEnvironment:
> CDC-1.0/Foundation-1.0,J2SE-1.3
> at 
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:294)
> at 
> org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:329)
> at 
> org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1046)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:573)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:495)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:275)
> at 
> org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:455)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:189)
> at 
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:291)
>
> !ENTRY org.eclipse.osgi 4 0 2016-11-17 00:51:17.363
> !MESSAGE Bundle
> initial@reference:file:plugins/org.eclipse.equinox.common_3.2.0.v20060603.jar/
> was not resolved.
>
> !ENTRY org.eclipse.osgi 4 0 2016-11-17 00:51:17.363
> !MESSAGE Bundle
> initial@reference:file:plugins/org.eclipse.update.configurator_3.2.2.R32x_v20070111.jar/
> was not resolved.
>
> !ENTRY org.eclipse.osgi 4 0 2016-11-17 00:51:17.363
> !MESSAGE Bundle
> initial@reference:file:plugins/org.eclipse.core.runtime_3.2.0.v20060603.jar/
> was not resolved.
>
> !ENTRY org.eclipse.osgi 4 0 2016-11-17 00:51:17.372
> 

Re: meta/haskell-platform -- full or minimal?

[Karel Gardas]

On Sun, Nov 6, 2016 at 12:51 AM, Matthias Kilian  wrote:
> Hi,
>
> it looks like the concept of a haskell platform has been stripped
> down do a "minimal" and a "full" flavor:
>
> https://www.haskell.org/platform/contents.html
>
> I prefer the "minimal" version, because it's less work for me (less
> constraints on library versions, maybe even less hs-ports).

+1. IMHO your time is better spent on improving GHC on OpenBSD. There
is few interesting issues from which proper W^X support is probably
one of the most interesting/important -- not only to OpenBSD community
but also to general GHC community IMHO.

Thanks for your hard work on GHC over the years!
Karel

Re: remove devel/eclipse ?

[Karel Gardas]

On Sun, Nov 6, 2016 at 12:40 AM, Matthias Kilian  wrote:
> And there are some alternatives (netbeans, intellij), but I don't
> know how good or bad they are compared to eclipse. I think they
> both have features like showing call-graphs, doing several kinds
> of mechanical refactoring etc.

Eclipse is quite unique for its MOF/EMF support IMHO. Well ironically
NetBeans was the first with MOF, but then due to management issues
probably Eclipse/EMF took the first position on this. Anyway, if
nobody is able to update Eclipse to more recent nothing will probably
happen, future of Eclipse is probably fully web-based anyway as shown
by Che: http://www.eclipse.org/che/ -- and this should be probably
less work to get working on OpenBSD anyway...

> So: *shrug* I probably wouldn't miss it much.

Indeed, 3.2.x is really old...

Karel

Re: update lang/ghc

[Karel Gardas]

On Sat, Nov 5, 2016 at 6:11 PM, Stuart Henderson <s...@spacehopper.org> wrote:
> On 2016/11/05 14:00, Karel Gardas wrote:
>> and if I'm on the same like you, then its clear that I got garbled
>> patch from gmail.com...
>
> gmail is useless for patches, you can fetch it raw from marc.info.
>

Thanks for confirmation.

BTW, after moving /usr/ports to wxallowed mount location I've been
able to build ghc-8.0.1 package well.

Re: update lang/ghc

[Karel Gardas]

Thanks to Daniel who provided me with ungarbled version of the patch
(instead of gmail.com's garbled version) I've been able to test and
found that it fails with:

===>   Ignoring patchfile patch-utils_ghc-pkg_Main_hs.orig
cd /usr/ports/pobj/ghc-8.0.1/ghc-7.10.3.20161101 &&
LD_LIBRARY_PATH=/usr/ports/pobj/ghc-8.0.1/ghc-7.10.3.20161101-shlibs-amd64
 ./configure --prefix=/usr/ports/pobj/ghc-8.0.1/bootstrap &&
LD_LIBRARY_PATH=/usr/ports/pobj/ghc-8.0.1/ghc-7.10.3.20161101-shlibs-amd64
 gmake install
checking for path to top of build tree...
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist[2]:
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: Permission denied
configure: error: cannot determine current directory
*** Error 1 in . (Makefile:143 'post-patch')
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2608
'/usr/ports/pobj/ghc-8.0.1/.patch_done')
*** Error 1 in /usr/ports/lang/ghc
(/usr/ports/infrastructure/mk/bsd.port.mk:2389 'all')


the problem here is probably location of
utils/ghc-pwd/dist-install/build/tmp/ghc-pwd on non-wxalloed mout. --
at least I guess.

# pwd
/usr/ports/lang/ghc

# mount
/dev/sd1a on / type ffs (local)
/dev/sd1d on /usr/local type ffs (local, nodev, wxallowed)


On Fri, Nov 4, 2016 at 11:27 PM, Matthias Kilian <k...@outback.escape.de> wrote:
> On Fri, Nov 04, 2016 at 10:48:11PM +0100, Karel Gardas wrote:
>> Simple patch < your message (after stripping headers) failed on me
>> with a lot of rejected hunks and files. This is current CVS of ports.
>> Probably doing something wrong.
>
> The diff I sent was against the latest current lang/ghc, with
>
> Makefile,v 1.143 (that was the latest commit dealing with wxneeded).
>
>> Anyway, rejected files are:
>> $ find . -name '*.rej'
>> ./patches/patch-configure.rej
>> ./patches/patch-ghc_mk.rej
>
> [...]
>
> Strange.  Was your tree clean, or did you already have some other
> diff applied?
>
> In any case, try cvs -qR up -dPAC to override any changes, then try to
> reapply my diff.
>
>> As haskell platform is on 8.0.1 version I would expect this is built
>> on top of GHC 8.0.1 too so at least some parts built into the platform
>> should be ready and compatible with GHC 8.0.1. At least that would be
>> my expectation on this...
>
> Well, haskell platform 8.0.1 in the "minimal" flavor basically is
> ghc with the libraries bundled with it, some additional tools
> (cabal-install, stack), but much less additional libraries as former
> versions of haskell platform.
>
> I'll work on the necessary updates for meta/haskell-platform and
> all the hs-ports during the next days (already have fixed (in my
> tree) a few dozens of ports which only require a bump and a new
> package-key).
>
> Ciao,
> Kili

Re: update lang/ghc

[Karel Gardas]

On Sat, Nov 5, 2016 at 1:34 PM, Daniel Jakots  wrote:
>> The question is: is my patch command line OK?
>
> It works fine for me. I took advantage of this situation to have a
> reason to test asciinema:
> https://asciinema.org/a/1lxc91o7jnqo7btsvwip7f8d4 :)

Wonderful! By any chance, could you be so kind and test your tree with
following MD5 output *before* applying patches?

$ find . -type f|xargs md5
MD5 (./CVS/Repository) = 5b953ce6e2413984a2858a9b182d2fc6
MD5 (./CVS/Entries) = 22863466de14495278861daf151067b5
MD5 (./CVS/Root) = 5ffd2a192aa48720652a8fddc66b5331
MD5 (./files/CVS/Repository) = 303c644e219f5ef8d76e8ad5275b9ebb
MD5 (./files/CVS/Entries) = ac5c00f02c373ccdad077d83f49c1f4a
MD5 (./files/CVS/Root) = 5ffd2a192aa48720652a8fddc66b5331
MD5 (./files/fixup-hs-plist) = 29cc0136a6646c3466611a4fff23bb38
MD5 (./files/Process.hsc) = dcd0c0271d8ab5a4c1b6f154503df5cb
MD5 (./patches/CVS/Repository) = 4dc776ab05380bbbc9dbfda191f16728
MD5 (./patches/CVS/Entries) = 38228750ebcaf322d31a8575ebefea5a
MD5 (./patches/CVS/Root) = 5ffd2a192aa48720652a8fddc66b5331
MD5 (./patches/patch-libffi_ghc_mk) = 8e5b7883d2cc2932a2cb5d2085582953
MD5 (./patches/patch-configure) = 284a9711f0cdecd54bdf20b8ce178263
MD5 (./patches/patch-ghc_mk) = 705fbc3a4a03281be3c98d1e9ab6348a
MD5 (./patches/patch-testsuite_mk_test_mk) = f34b020518340491c5623a0c0c1a82dc
MD5 (./patches/patch-mk_config_mk_in) = d43d5764499647890a1517b7e58e880a
MD5 (./patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Program_Strip_hs)
= 0e732c83ecd832e1c84a7a05eceb5218
MD5 (./patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Utils_hs)
= 0a4e49a084d142913670abbdfc25cc7b
MD5 (./patches/patch-libraries_base_GHC_IO_Encoding_hs) =
d538672915a377c3df2d8037f71b600a
MD5 (./patches/patch-libraries_base_System_IO_hs) =
d0d4bb031a8d132cd893033391999b99
MD5 (./patches/patch-libraries_base_cbits_PrelIOUtils_c) =
18952b6513bcc52bf00223aec68b7007
MD5 (./patches/patch-libraries_process_include_runProcess_h) =
2c86ed557be1af0b816ba1b9a50d70ea
MD5 (./patches/patch-mk_install_mk_in) = 7376309782760ad599683fd9a1344d75
MD5 (./patches/patch-rts_Linker_c) = d39933bd9266adef58ad251f9d3840c8
MD5 (./patches/patch-testsuite_tests_cabal_ghcpkg01_stdout) =
45c681419f4110a2a5d84d935bee0bcd
MD5 (./patches/patch-testsuite_driver_testlib_py) =
2a1a73d9b1073579b0e708bda98f70f0
MD5 (./patches/patch-libraries_unix_unix_cabal) =
1f85add1d7e482b15f637f4d5b0e9c0a
MD5 (./patches/patch-testsuite_tests_codeGen_should_run_all_T) =
c1c18e2ea8df75036f9a7c82460fdd28
MD5 (./patches/patch-utils_ghc-pkg_Main_hs) = d3ea66cea9cc4ddd86b36a464616a026
MD5 (./pkg/CVS/Repository) = cdd407a36b60072353bd1681efc5bbe9
MD5 (./pkg/CVS/Entries) = f92116db3af096dfa1f3a1c8263669d9
MD5 (./pkg/CVS/Root) = 5ffd2a192aa48720652a8fddc66b5331
MD5 (./pkg/PLIST) = b4ecdaef3827a2f01ec268944c15ae83
MD5 (./pkg/DESCR) = a73a599ae1e32cd83413385c06363153
MD5 (./Makefile) = 4176fdf75166b4b0de76875d4d36461b
MD5 (./distinfo) = 7228935732572443fe4ef8b8d1399a59
MD5 (./ghc.port.mk) = faf2987a313ee1316f24602126587a69


My patch is:

$ patch --version
Patch version 2.0-12u8-OpenBSD

running on few days old current snapshot.

and if I'm on the same like you, then its clear that I got garbled
patch from gmail.com...

Thanks,
Karel

Re: update lang/ghc

[Karel Gardas]

On Fri, Nov 4, 2016 at 11:27 PM, Matthias Kilian <k...@outback.escape.de> wrote:
> On Fri, Nov 04, 2016 at 10:48:11PM +0100, Karel Gardas wrote:
>> Simple patch < your message (after stripping headers) failed on me
>> with a lot of rejected hunks and files. This is current CVS of ports.
>> Probably doing something wrong.
>
> The diff I sent was against the latest current lang/ghc, with
>
> Makefile,v 1.143 (that was the latest commit dealing with wxneeded).
>
>> Anyway, rejected files are:
>> $ find . -name '*.rej'
>> ./patches/patch-configure.rej
>> ./patches/patch-ghc_mk.rej
>
> [...]
>
> Strange.  Was your tree clean, or did you already have some other
> diff applied?
>
> In any case, try cvs -qR up -dPAC to override any changes, then try to
> reapply my diff.

It still does not work for me. Look my tree should be clean:

$ pwd
/usr/ports/lang/ghc
$ cvs -q up -Pd
$


it's also on Makefile 1.143:

$ cat CVS/Entries
D/patches
D/pkg
D/files
/Makefile/1.143/Sat Nov  5 12:16:03 2016//
/distinfo/1.47/Sat Nov  5 12:16:03 2016//
/ghc.port.mk/1.38/Sat Nov  5 12:16:03 2016//
$ cat CVS/Root
anon...@ftp.hostserver.de:/cvs
$

and I saved whole your email to /home/karel/src/original_msg.txt from
which I tripped headers and your text to have:

$ head /home/karel/src/original_msg.txt
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.143
diff -u -p -r1.143 Makefile
--- Makefile1 Nov 2016 18:14:05 -   1.143
+++ Makefile3 Nov 2016 14:27:06 -
@@ -12,12 +12,11 @@ COMMENT =   compiler for the functional l
 NO_CCACHE =Yes

$


So everything on my end so far should be clean, isn't it? Now, I try
to apply with:

$ pwd
/usr/ports/lang/ghc
$ patch < /home/karel/src/original_msg.txt
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: Makefile
|===
|RCS file: /cvs/ports/lang/ghc/Makefile,v
|retrieving revision 1.143
|diff -u -p -r1.143 Makefile
|--- Makefile   1 Nov 2016 18:14:05 -   1.143
|+++ Makefile   3 Nov 2016 14:27:06 -
--
Patching file Makefile using Plan A...
Hunk #1 failed at 12.
Hunk #2 failed at 30.
Hunk #3 failed at 48.
Hunk #4 failed at 58.
Hunk #5 failed at 120.
Hunk #6 failed at 191.
Hunk #7 failed at 216.
7 out of 7 hunks failed--saving rejects to Makefile.rej

etc. a lot of hunk failures and a lot of rejected files.

The question is: is my patch command line OK?

Thanks,
Karel

Re: update lang/ghc

[Karel Gardas]

Simple patch < your message (after stripping headers) failed on me
with a lot of rejected hunks and files. This is current CVS of ports.
Probably doing something wrong.

Anyway, rejected files are:
$ find . -name '*.rej'
./patches/patch-configure.rej
./patches/patch-ghc_mk.rej
./patches/patch-libffi_ghc_mk.rej
./patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Program_Strip_hs.rej
./patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Utils_hs.rej
./patches/patch-libraries_unix_unix_cabal.rej
./patches/patch-mk_config_mk_in.rej
./patches/patch-mk_install_mk_in.rej
./patches/patch-rts_Linker_c.rej
./patches/patch-testsuite_driver_testlib_py.rej
./patches/patch-testsuite_mk_test_mk.rej
./patches/patch-testsuite_tests_cabal_ghcpkg01_stdout.rej
./patches/patch-utils_ghc-pkg_Main_hs.rej
./pkg/PLIST.rej
./Makefile.rej
./distinfo.rej
./ghc.port.mk.rej

As haskell platform is on 8.0.1 version I would expect this is built
on top of GHC 8.0.1 too so at least some parts built into the platform
should be ready and compatible with GHC 8.0.1. At least that would be
my expectation on this...

Thanks,
Karel

On Thu, Nov 3, 2016 at 6:34 PM, Matthias Kilian  wrote:
> Hi,
>
> Just in case, eomeone wants to play with ghc-8.0.1. Of course,
> pretty everything in the tree using ghc is broken after this update
> (as always().
>

Re: GHC in snapshots with non-existent ld.

[Karel Gardas]

On Tue, Nov 1, 2016 at 5:12 PM, Matthias Kilian  wrote:
> -# XXX: wxneeded is a hack. Fix rts/Linker.c, mmapForLinker() and
> -#  loadObj_() instead.
> -USE_WXNEEDED = Yes
> +# We can't use the wrapper script, because it then gets hardcoded into
> +# the packaged ghc. So we explicitely use -Wl,-z,wxneeded (see
> +# CONFIGURE_ENV below)
> +# USE_WXNEEDED =   Yes
>
>  WANTLIB += c iconv m ncursesw pthread util
>
> @@ -106,12 +107,14 @@ CFLAGS += -fno-pie
>  CONFIGURE_STYLE =  gnu
>  CONFIGURE_ARGS +=  --with-iconv-includes=${LOCALBASE}/include \
> --with-iconv-libraries=${LOCALBASE}/lib

Have you tried to use USE_WXNEEDED = Yes and add
CONFIGURE_ARGS += --with-ld=/usr/bin/ld

?

Anyway, thanks for fixing this,
Karel

Re: WIP: GCC 6.2.0

[Karel Gardas]

On Wed, Sep 7, 2016 at 5:21 AM, Dongsheng Song  wrote:
>
> Your patch block llvm 3.8.1, I'm not care about gcc 4.9.4, but llvm 3.8.1
> depends gcc 4.

Pascal already imported LLVM 3.8.1 into the base so I guess the plan
is to use it at least on some architectures so highly probably you
will not need ports' LLVM anymore.

Re: darcs w^x trouble

[Karel Gardas]

I'm not sure if USE_WXNEEDED is also applicable to Haskell-based
ports. Anyway, this is more generally GHC's issue than darcs one, as
the issue arise from the GHC's runtime library probably. I would
recommend to read "Haskell wxneeded" thread on this mailing list for
more information about the issue.

On Thu, Sep 1, 2016 at 8:36 AM, Francisco de Borja Lopez Rio
 wrote:
> Hi everybody.
>
> Installed a fresh snapshot:
>
> kern.version=OpenBSD 6.0-current (GENERIC) #2210: Mon Aug 22 09:14:34 MDT 2016
>
> Installed darcs from packages:
>
> pkg_add -i darcs
>
> Every time I try to run "darcs record" (to record some changes in a local
> repo):
>
> darcs: internal error: setExecutable: failed to protect 0x0x2242c5000
>
> (GHC version 7.10.3 for x86_64_unknown_openbsd)
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> Abort trap (core dumped)
>
> And in the logs I can see:
>
> darcs(11893): mprotect W^X violation
>
> Some other commands seem to work just fine (darcs init/add/clone/pull...)
>
> This is a testing env, just a single / partition, marked with wxallowed:
>
> /dev/wd0a on / type ffs (local, wxallowed)
>
> Afterwards, I added "USE_WXNEEDED = yes" to /usr/ports/devel/darcs/Makefile
> and I built darcs from ports. Same result.
>
> There is no MAINTAINER set for this port, anybody that can help a bit with
> this?
>
> Regards.
>
> --
>
> "Do nothing which is of no use." - Miyamoto Musashi
> -
> Francisco de Borja Lopez Rio (bo...@codigo23.net)
> Soluciones Informaticas Codigo23 S.L.U.
> http://www.codigo23.net
>

Re: Haskell wxneeded

[Karel Gardas]

On Sat, Aug 13, 2016 at 10:47 PM, Matthias Kilian
<k...@outback.escape.de> wrote:
> Hi Karel,
>
> On Sat, Aug 13, 2016 at 06:56:39PM +0200, Karel Gardas wrote:
>> > $ ./inplace/bin/ghc-stage2 --interactive
>> > GHCi, version 8.1.20160812: http://www.haskell.org/ghc/  :? for help
>> > Prelude> 1+1
>> > 2
>> > Prelude> :q
>> > Leaving GHCi.
>> > $
>> >
>> > I'll try to propagate those fixes to GHC HEAD...
>>
>> FYI: The fixes are here:
>>
>> https://phabricator.haskell.org/D2453
>> https://phabricator.haskell.org/D2454
>
> The wxneeded "fix" is really just a workaround.

It is indeed and it's clearly mentioned isn't it? But anyway it makes
things running much better here so it's improvement.

> Right now I'm building
> and then testing a ghc-7.10.3 that
>
> - doas *not* link with -z wxneeded,
>
> - uses mmap with PROT_READ | PROT_WRITE in rts/Linker.c
>
> - uses mprotect with PROT_READ | PROT_EXEC right after loading and
>   resolving an object in Linker.c (i.e., just plain W^X)
>
> Results should be available tomorrow.

Good I've been also looking into this, but now I'm investigating full
testsuite results. So far majority of failures are in external
interpreter. Anyway, I'm looking forward to see your patch(es),
although Linker.c is quite moving target I hope I'll be able to
forward-port your changes to HEAD and if working well this will be
indeed proper fix for the issue and not just mine stopgap solution.

Cheers,
Karel

Re: Haskell wxneeded

[Karel Gardas]

> With two small fixes GHC HEAD's GHCi runs with enforced wxneeded on
> wxallowed fs:
>
> $ ./inplace/bin/ghc-stage2 --interactive
> GHCi, version 8.1.20160812: http://www.haskell.org/ghc/  :? for help
> Prelude> 1+1
> 2
> Prelude> :q
> Leaving GHCi.
> $
>
> I'll try to propagate those fixes to GHC HEAD...

FYI: The fixes are here:

https://phabricator.haskell.org/D2453
https://phabricator.haskell.org/D2454

if you do have any objections feel free to comment on phabricator...

Re: Haskell wxneeded

[Karel Gardas]

On Sat, Aug 13, 2016 at 7:47 AM, Karel Gardas <gard...@gmail.com> wrote:
>>> Perhaps this is just intended behavior somehow as kernel complains on
>>> console with:
>>>
>>> /home/karel/src/ghc-head-openbsd-wxneeded/inplace/lib/bin/ghc-stage2(94953):
>>> W^X binary outside wxallowed mountpoint
>>>
>>> and obviously my current is w/o any wxallowed fs...
>>
>> Your port build directory and /usr/local need wxallowed, failures are 
>> expected
>> otherwise. (At present, there are some failures anyway even with this).
>
> Thanks for clarification, so I'll need to create some wxallowed space
> on my -current setup for hacking on GHC.

With two small fixes GHC HEAD's GHCi runs with enforced wxneeded on
wxallowed fs:

$ ./inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20160812: http://www.haskell.org/ghc/  :? for help
Prelude> 1+1
2
Prelude> :q
Leaving GHCi.
$

I'll try to propagate those fixes to GHC HEAD...

Re: Haskell wxneeded

[Karel Gardas]

>> Perhaps this is just intended behavior somehow as kernel complains on
>> console with:
>>
>> /home/karel/src/ghc-head-openbsd-wxneeded/inplace/lib/bin/ghc-stage2(94953):
>> W^X binary outside wxallowed mountpoint
>>
>> and obviously my current is w/o any wxallowed fs...
>
> Your port build directory and /usr/local need wxallowed, failures are expected
> otherwise. (At present, there are some failures anyway even with this).

Thanks for clarification, so I'll need to create some wxallowed space
on my -current setup for hacking on GHC.

Re: Haskell wxneeded

[Karel Gardas]

On Sat, Aug 13, 2016 at 12:56 AM, Karel Gardas <gard...@gmail.com> wrote:
[...]
> $ ./ghc/stage2/build/tmp/ghc-stage2
> ./ghc/stage2/build/tmp/ghc-stage2[1]: syntax error: `)' unexpected
> $ file ./ghc/stage2/build/tmp/ghc-sa   tage2
> ./ghc/stage2/build/tmp/ghc-stage2: ELF 64-bit LSB shared object,
> x86-64, version 1
>
>
> Have anybody here seen this already? The system is:
>

Perhaps this is just intended behavior somehow as kernel complains on
console with:

/home/karel/src/ghc-head-openbsd-wxneeded/inplace/lib/bin/ghc-stage2(94953):
W^X binary outside wxallowed mountpoint

and obviously my current is w/o any wxallowed fs...

Karel

Re: Haskell wxneeded

[Karel Gardas]

> @Karel Gardas and anyone else who is playing with the newest upstream
> ghc (8.x): If you have some time, could you please try to build
> some hs-programs or libraries for which naddy@ reported w^x violations
> recently with ghc-8 (and probably cabal-install, because I don't
> think this will work with the hs-libraries we currently have in the
> ports tree)? I'd owe you unlimited amounts of beer for such a test,
> of course ;-)

:-) Beer is nothing for me, but anyway test done. First of all what
Martijn is seeing here is not ghc failure perse, but ghci failure. I
smell TH usage here probably. Anyway, GHC head is still buildable by
GHC 7.10.3, the obvious problem is that GHCi fails:

$ ./inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20160812: http://www.haskell.org/ghc/  :? for help
Abort trap (core dumped)

if I try to build it with -Wl,-zwxneeded, then I get strange binary:

$ readelf -l ./ghc/stage2/build/tmp/ghc-stage2

Elf file type is DYN (Shared object file)
Entry point 0x440
There are 11 program headers, starting at offset 64

Program Headers:
  Type   Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
  PHDR   0x0040 0x0040 0x0040
 0x0348 0x0348  R E8
  INTERP 0x000c325e 0x001c325e 0x001c325e
 0x0013 0x0013  R  1
  [Requesting program interpreter: /usr/libexec/ld.so]
  LOAD   0x 0x 0x
 0x000c325e 0x000c325e  R E10
  LOAD   0x000c325e 0x001c325e 0x001c325e
 0x0003e0ae 0x0003e0ae  R  10
  LOAD   0x00102180 0x00302180 0x00302180
 0x00036998 0x000369e0  RW 10
  DYNAMIC0x00132bf0 0x00332bf0 0x00332bf0
 0x0360 0x0360  RW 8
  NOTE   0x000c3274 0x001c3274 0x001c3274
 0x0018 0x0018  R  4
  GNU_EH_FRAME   0x0010114c 0x0020114c 0x0020114c
 0x005c 0x005c  R  4
  GNU_STACK  0x 0x 0x
 0x 0x  RWE8
  OPENBSD_WXNEED 0x 0x 0x
 0x 0xE8
  GNU_RELRO  0x00102180 0x00302180 0x00302180
 0x00032e80 0x00032e80  R  1

 Section to Segment mapping:
  Segment Sections...
   00
   01 .interp
   02 .init .plt .text .fini
   03 .interp .note.openbsd.ident .hash .dynsym .dynstr .rela.dyn
.rela.plt .rodata .eh_frame_hdr .eh_frame
   04 .jcr .data.rel.ro .dynamic .ctors .dtors .got .data .bss
   05 .dynamic
   06 .note.openbsd.ident
   07 .eh_frame_hdr
   08
   09
   10 .jcr .data.rel.ro .dynamic .ctors .dtors .got
$ ./ghc/stage2/build/tmp/ghc-stage2
./ghc/stage2/build/tmp/ghc-stage2[1]: syntax error: `)' unexpected
$ file ./ghc/stage2/build/tmp/ghc-sa   tage2
./ghc/stage2/build/tmp/ghc-stage2: ELF 64-bit LSB shared object,
x86-64, version 1


Have anybody here seen this already? The system is:

OpenBSD 6.0-current (GENERIC.MP) #0: Fri Aug 12 22:41:37 CEST 2016

Cheers,
Karel

Re: NEW: cvs2gitdump

[Karel Gardas]

Great addition, especially because with vanilla cvs2gitdump from
github.com man can't easily find out rcsparse which is its dependency.
Thanks! Karel

On Sun, Jul 31, 2016 at 11:50 PM, Stuart Henderson  wrote:
> ok to import?
>
> "A small python script which imports a cvs tree into a git or svn repository.
> It has a small footprint, is fast, and supports incremental import, but does
> not support branches."
>
> This is the one I was using on my mirror before the SSD died, it's not
> perfect but for me it's been working better than the other options
> for an incremental conversion.
>

Re: Elasticsearch Java memory errors

[Karel Gardas]

See /etc/login.conf for limits. That your machine does have 4GB of RAM
does not mean anything.

On Thu, Jul 14, 2016 at 12:37 AM, David Alten  wrote:
> Hello,
>
> On a new setup, 5,9, i386, I'm getting Java memory errors when starting
> elasticsearch:
>
> $ doas /etc/rc.d/elasticsearch -d start
> doing _rc_parse_conf
> doing _rc_quirks
> elasticsearch_flags empty, using default >-d
> -Des.default.path.conf=/etc/elasticsearch -p
> /var/run/elasticsearch/elasticsearch.pid<
> doing _rc_read_runfile
> doing rc_check
> elasticsearch
> doing rc_pre
> doing rc_start
> No home directory /nonexistent!
> Logging in with home = "/".
> doing _rc_wait start
> doing rc_check
> doing _rc_write_runfile
> (ok)
> $ Error occurred during initialization of VM
> Could not reserve enough space for 1048576KB object heap
>
> I can get it working by decreasing the memory usage here:
>
> /etc/elasticsearch/elasticsearch.in.sh:
> if [ "x$ES_MAX_MEM" = "x" ]; then
> ES_MAX_MEM=768m
> #ES_MAX_MEM=1g
>
> Given that my test machine has 4GB of free memory and nothing else is
> running on the box, why am I seeing the error?
>
> $ pkg_info | grep jdk
> jdk-1.7.0.80p0v0Java2(TM) SE Dev Kit v1.7.0.80
> jdk-1.8.0.72v0  OpenJDK Software Development Kit v1.8.0.72
> $ pkg_info | grep elas
> elasticsearch-2.1.1p0 distributed RESTful search and analytics
> $ /usr/local/jdk-1.8.0/bin/java -version
> openjdk version "1.8.0_72"
> OpenJDK Runtime Environment (build 1.8.0_72-b15)
> OpenJDK Server VM (build 25.72-b15, mixed mode)
>
> 26883 C0- I   0:16.05 /usr/local/jdk-1.8.0/bin/java -Xms256m -Xmx768m
> -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSIni
>
> Thanks for any pointers,
> David

mc crashes on snapshot (utf8 related?).

[Karel Gardas]

Hello,

on fairly recent snapshot I've seen quite some crashes in mc while
searching filesystem for specific file containing something. The crash
stack trace looks:

(gdb) where
#0  0x0eea51f4fcf0 in g_utf8_get_char_validated () from
/usr/local/lib/libglib-2.0.so.4200.3
#1  0x0ee7946acef9 in mcedit_arg_free () from /usr/local/bin/mc
#2  0x0ee7946c2edc in file_progress_real_query_replace () from
/usr/local/bin/mc
#3  0x0ee7946c30ba in file_progress_real_query_replace () from
/usr/local/bin/mc
#4  0x0ee794639df9 in dlg_default_callback () from /usr/local/bin/mc
#5  0x0ee7946c40fb in file_progress_real_query_replace () from
/usr/local/bin/mc
#6  0x0ee79466a24a in load_prompt () from /usr/local/bin/mc
#7  0x0ee79466aae1 in load_prompt () from /usr/local/bin/mc
#8  0x0ee794639b2a in dlg_default_callback () from /usr/local/bin/mc
#9  0x0ee794639e36 in dlg_default_callback () from /usr/local/bin/mc
#10 0x0ee7946697f6 in load_prompt () from /usr/local/bin/mc
#11 0x0ee794628fc5 in ?? () from /usr/local/bin/mc
#12 0x0ee7946287b2 in ?? () from /usr/local/bin/mc
#13 0x in ?? ()


is this a know issue?

Thanks,
Karel

Re: alpha bulk build report

[Karel Gardas]

build failure of PostgreSQL seems to be related to missing spinlocks
support for Alpha. Log even suggest to use --disable-spinlocks
configure option.

On Thu, May 26, 2016 at 1:13 PM,   wrote:
> bulk build on alpha-1.ports.openbsd.org
> started on  Sat May 14 02:47:41 MDT 2016
> finished at Thu May 26 05:13:08 MDT 2016
> lasted 12D19h25m
> done with kern.version=OpenBSD 6.0-beta (GENERIC.MP) #420: Fri May 13 
> 13:09:28 MDT 2016
>
> built packagesls: /usr/ports/packages/alpha/all: No such file or directory
>
> mv: /usr/ports/packages/alpha: No such file or directory
>
> build failures: 35
> http://build-failures.rhaalovely.net//alpha/2016-05-14/databases/postgresql.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/devel/ti-msp430gcc.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/angband,no_x11.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/brumbrumrally.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/connect4.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/dopewars,no_x11.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/dungeon-crawl.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/falconseye.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/icebreaker.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/moon-buggy.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/moria.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/nethack,no_x11.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/omega.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/slash,no_x11.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/slash-em,no_x11.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/wanderer.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/xinvaders.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/xkobo,harder.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/games/zangband,no_x11.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/graphics/freeimage.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/japanese/canna.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/lang/gcc/4.6.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/lang/gcc/4.9.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/lang/moarvm.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/mail/sendmail,-libmilter.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/multimedia/gstreamer1/plugins-bad.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/multimedia/gstreamer1/plugins-good.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/net/openvpn_bsdauth.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/net/rtorrent.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/net/ucspi-tcp.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/productivity/wyrd.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/sysutils/gkrellm/gkrellm,-client.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/x11/spice-gtk.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/x11/wmii.log
> http://build-failures.rhaalovely.net//alpha/2016-05-14/x11/wxSVG.log
>
> recurrent failures
>  failures/devel/ti-msp430gcc.log
>  failures/graphics/freeimage.log
>  failures/lang/gcc/4.9.log
>  failures/lang/moarvm.log
>  failures/net/rtorrent.log
>  failures/productivity/wyrd.log
> new failures
> +++ ls-failures Thu May 26 05:13:21 2016
> +failures/databases/postgresql.log
> +failures/games/angband,no_x11.log
> +failures/games/brumbrumrally.log
> +failures/games/connect4.log
> +failures/games/dopewars,no_x11.log
> +failures/games/dungeon-crawl.log
> +failures/games/falconseye.log
> +failures/games/icebreaker.log
> +failures/games/moon-buggy.log
> +failures/games/moria.log
> +failures/games/nethack,no_x11.log
> +failures/games/omega.log
> +failures/games/slash,no_x11.log
> +failures/games/slash-em,no_x11.log
> +failures/games/wanderer.log
> +failures/games/xinvaders.log
> +failures/games/xkobo,harder.log
> +failures/games/zangband,no_x11.log
> +failures/japanese/canna.log
> +failures/lang/gcc/4.6.log
> +failures/mail/sendmail,-libmilter.log
> +failures/multimedia/gstreamer1/plugins-bad.log
> +failures/multimedia/gstreamer1/plugins-good.log
> +failures/net/openvpn_bsdauth.log
> +failures/net/ucspi-tcp.log
> +failures/sysutils/gkrellm/gkrellm,-client.log
> +failures/x11/spice-gtk.log
> +failures/x11/wmii.log
> +failures/x11/wxSVG.log
> resolved failures
> --- ../old/alpha/last//ls-failures  Wed May 11 08:40:09 2016
> -failures/math/p5-Math-Pari.log
> -failures/net/icinga/core2,-main.log
> Base libs:
> curses.14.0 edit.5.2 event.4.1 expat.11.0 form.6.0 formw.6.0 fuse.1.1
> iberty.12.0 kvm.16.1 menu.6.0 menuw.6.0 ncurses.14.0 ncursesw.14.0
> 

Re: lang/hugs (was: 'avoid W|X mappings in libffi' - MARC)

[Karel Gardas]

On Tue, May 24, 2016 at 8:57 PM, Matthias Kilian  wrote:
> IIRC, I once wrote that the ports tree isn't a software museum, so
> instead of trying to fix it, i'd just cimpletely remove it from the
> tree, and maybe other ancient haskell implementations (yes, I mean
> you, nhc98!).

Agree, better concentrate on GHC these days and not waste energy on
museum stuff which may be run on museum OpenBSD anyway...

Re: avoid W|X mappings in libffi

[Karel Gardas]

Hello,

in whole thread I've not seen a note about GHC (Haskell compiler).
IIRC although GHC support building with its own intree libffi, on
OpenBSD it uses ports libffi. This is IIRC done by current 7.10.x in
the tree and is done surely by just released GHC 8.0.1 which is not
yet in ports but which already accumulated some ports patches into GHC
source tree.

On Sun, May 22, 2016 at 11:30 PM, Sebastian Reitenbach
 wrote:
>
> On Sunday, May 22, 2016 23:08 CEST, "Sebastian Reitenbach" 
>  wrote:
>
>>
>> On Sunday, May 22, 2016 14:36 CEST, Stuart Henderson  
>> wrote:
>>
>> > Build is about halfway, here are some more processes that are run
>> > during a ports build that trigger the warnings:
>> >
>> > java(15505): mprotect: mandatory W^Xdevel/jdk & bootstrap
>> > xpcshell18306): mmap: mandatory W^X devel/xulrunner/24
>> > xulrunner(15827): mmap: mandatory W^X   devel/xulrunner/24
>> > gforth*: mmap: mandatory W^Xlang/gforth
>> > mono-boehm: mmap: mandatory W^X lang/mono
>> > obxj(76370): mprotect: mandatory W^Xlang/obc
>> > run.x86-openbsd(19339): mmap: mandatory W^X lang/smlnj
>> > mksnapshot: mmap: mandatory W^X www/chromium, iridium (v8)
>> >
>> > (obviously as this is build time, these are only from programs
>> > that are run, either in pobj or installed, during build.)
>> >
>> > My libffi diff causes x11/gnustep/base to fail:
>> >
>> > checking FFI library usage... configure: error: The ffi library (libffi) 
>> > does not appear to be working.  Perhaps it's missing or you need a more 
>> > recent version.  Version 3.0.9 or later should work, and you can find a 
>> > link to it n the list of packages for download at 
>> > http://www.gnustep.org/resources/sources.html
>> >
>> > configure:24337: checking FFI library usage
>> > configure:24370: clang -o conftest -O2 -pipe  -I/usr/local/include 
>> > -I/usr/local/include -I/usr/local/include -I/usr/
>> > local/include -fobjc-runtime=gnustep-1.7 -fgnu-runtime -x objective-c 
>> > -I/usr/local/include  -L/usr/local/lib -L/usr/
>> > local/lib -L/usr/local/lib -L/usr/local/lib conftest.c -L/usr/local/lib 
>> > -pthread -lffi  -lpthread -lz >&5
>> > configure:24374: $? = 0
>> > configure:24380: ./conftest
>> > Segmentation fault (core dumped)
>> >
>> > The test program it's trying to run is config/config.ffi.c in
>> > gnustep/base's tree. I'm unlikely to be able to figure this out,
>> > can someone help please?
>> >
>>
>> I hope I can get around to have a look at it tomorrow.
>
> I couldn't resist, and just tried the conftest program under gdb with your 
> libffi patch:
>
> (gdb) r
> Starting program: 
> /home/ports/pobj/amd64/gnustep-base-1.24.9/gnustep-base-1.24.9/config/conftest
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x06a09691e010 in ?? ()
> (gdb) bt
> #0  0x06a09691e010 in ?? ()
> #1  0x069e48000d92 in main () at conftest.c:65
> (gdb) frame 1
> #1  0x069e48000d92 in main () at conftest.c:65
> 65((void(*)(cls_struct_combined)) (code))(g_dbl);
> (gdb) list
> 60  != FFI_OK) abort();
> 61
> 62if (ffi_prep_closure_loc(pcl, , cls_struct_combined_gn, NULL, 
> code)
> 63  != FFI_OK) abort();
> 64
> 65((void(*)(cls_struct_combined)) (code))(g_dbl);
> 66exit(0);
> 67  }
>
> It fails at the very end of the main() function, but I have absolutely
> no clue what's going wrong here.
> It seems to setup a closure, and then trying to call it, and that
> breaks
>
> Sebastian.
>
>

Re: GCC, OpenMP, -march=

[Karel Gardas]

have you tried to bootstrap your own gcc with recent binutils? i.e.
--with-as=... On the other hand you may also
give a try to LLVM/clang from ports and see if they support your
required features...

On Sat, Mar 26, 2016 at 5:25 PM, Hannes Hauswedell
 wrote:
> Hi folks,
>
> I develop software for work that uses some advanced cpu features and
> parallelism. While I fully understand that high-performance is not a focus
> for OpenBSD, I would still like to be able to test basic stuff on my Laptop
> (which happens to run OpenBSD). So, before I get my hands dirty on this, I'd
> like to ask if there are structural issues and/or policies preventing those
> features from working, or whether just no-one was interested up until now (I
> have done some basic searching but didn't come up with too much).
>
> The features in question are:
>
> 1) OpenMP with the GCC-port. It is disabled by default. Is there a reason
> for this? Are there any known "blockers"? Should I be able to make it work,
> would patches be accepted?
>
> 2) CPU-features like POPCNT, AVX are apparently not supported right now (or
> at least not with gcc). Also if you build software with the gcc-4.9-port and
> specify -march=native gcc wil produce code that actually uses instructions
> that are not supported, and then fail with messages like this:
>
> /tmp//ccF2Aqg7.s: Assembler messages:
> /tmp//ccF2Aqg7.s:1668791: Error: no such instruction: `popcntl
> -4(%rbp),%eax'
> /tmp//ccF2Aqg7.s:1669741: Error: no such instruction: `popcntq
> -8(%rbp),%rax'
>
> -> Are there plans to support more modern CPU-extensions and is there a list
> somewhere of which extensions are supported and which ones aren't? I guess
> they could be useful for other low-level stuff like encryption, as well..
> --> If not, should the gcc-port be adapted to not offer those extensions
> that aren't supported?
>
> Thanks and best regards,
> Hannes
>

Re: devel/mico failing due to failed assertion

[Karel Gardas]

Guys,

I've installed 5.8 chroot on 5.9-beta as of January 2016. I've removed
/etc/resolve.conf after installing few packages and give MICO build a
try. I've duplicated issue of assert in address.cc:555 since hostname
is not resolvable. I've been able to solve this assert by putting:

-ORBIIOPAddr inet:127.0.0.1:0 -ORBNoResolve

into some file and then:

export MICORC=

E.g.
$ echo "-ORBIIOPAddr inet:127.0.0.1:0 -ORBNoResolve" > /tmp/mico-build.rc
$ export MICORC=/tmp/mico-build.rc

this instructs MICO to load configuration options for its
initialization from the file, so basically -ORBIIOPAddr
inet:127.0.0.1:0 -ORBNoResolve are used for all IDL compiler
invocations. Those two options means: bind to 127.0.0.1, system
selected port and do not attempt to resolve name for this address to
get some meaningful name.

I think this should be enough even for Marc's builder but if you put
even more limits on your builders like for example can't create tcp
socket, then I should be able to instruct MICO to use unix pipes
instead -- hopefully those will be allowed at the end. :-)

Please let me know if this solves the issue for you. Thanks! Karel

On Fri, Mar 11, 2016 at 12:26 PM, Stuart Henderson <s...@spacehopper.org> wrote:
> On 2016/03/11 11:22, Karel Gardas wrote:
>> On Thu, Mar 10, 2016 at 10:28 PM, Marc Espie <es...@nerim.net> wrote:
>> >> Indeed, it is, but I guess this was done for a good reason in the past
>> >> and I would rather keep it this way. What I can certainly do for
>> >> 2.3.14 release is to add some clear error message pointing to the
>> >> incorrect network configuration.
>> >
>> > It's not an incorrect network configuration, actually.   It's just no 
>> > resolving
>> > some things on localhost.
>> >
>> > mico is the only port that wants this. Everything else works peachy.
>> >
>> > I've got a very paranoid setup on my build machines.
>> > I just have:
>> > block out quick proto {tcp,udp} from self user pbuild0
>> >
>> > oh, and the build is chroot'd to a place that only knows about localhost.
>> >
>> > No other port in the trees ever tries to resolve `hostname` during build.
>>
>> is it a big problem to set hostname to localhost  in such chroot and
>> have localhost resolvable to 127.0.0.1 and 127.0.0.1 back to
>> localhost?
>>
>> Just asking. The possibility is that -ORBNoResolve works in such case
>> and if so we may add it into IDL compiler main.cc as a parameter
>> specifically for OpenBSD. If this works well I may even relax this
>> condition for IDL compiler on all platforms or specifically test if
>> the issue is present and then switch NoResolve on...
>
> I think we could reasonably expect "localhost" to be resolvable
> forwards and backwards, but the hostname is system-wide and returned
> by a system call, you can't have a different one inside chroot.
>

Re: devel/mico failing due to failed assertion

[Karel Gardas]

On Thu, Mar 10, 2016 at 10:28 PM, Marc Espie  wrote:
>> Indeed, it is, but I guess this was done for a good reason in the past
>> and I would rather keep it this way. What I can certainly do for
>> 2.3.14 release is to add some clear error message pointing to the
>> incorrect network configuration.
>
> It's not an incorrect network configuration, actually.   It's just no 
> resolving
> some things on localhost.
>
> mico is the only port that wants this. Everything else works peachy.
>
> I've got a very paranoid setup on my build machines.
> I just have:
> block out quick proto {tcp,udp} from self user pbuild0
>
> oh, and the build is chroot'd to a place that only knows about localhost.
>
> No other port in the trees ever tries to resolve `hostname` during build.

is it a big problem to set hostname to localhost  in such chroot and
have localhost resolvable to 127.0.0.1 and 127.0.0.1 back to
localhost?

Just asking. The possibility is that -ORBNoResolve works in such case
and if so we may add it into IDL compiler main.cc as a parameter
specifically for OpenBSD. If this works well I may even relax this
condition for IDL compiler on all platforms or specifically test if
the issue is present and then switch NoResolve on...

Re: devel/mico failing due to failed assertion

[Karel Gardas]

On Thu, Mar 10, 2016 at 7:37 PM, Michael McConville <mm...@mykolab.com> wrote:
> Karel Gardas wrote:
>> This is a sign of not so correct network configuration. MICO is really
>> picky about it so it should be able to resolve your host name/IP
>> address. What's failing precisely in the assert above is that it's not
>> able to get IP for your hostname. Can you confirm that this is the
>> case?
>
> Confirmed. I hadn't considered that my hostname could affect a package
> build.  :-)
>
> I don't know anything about Mico, so I'll stay out of the patching
> process.

The problem is simple: one part of build process is building
CORBA/MICO services. For this you need IDL compiler which translates
service interfaces (IDL) into target language (C++). The IDL compiler
itself is CORBA/MICO application (to be able to upload IDL files into
the interface repository which is also CORBA application). So IDL
compiler initializes CORBA/MICO and for this unfortunately (on MICO
side) you need to have correct hostname/ip setup.

Workaround for this may be to use -ORBNoResolve on IDL compiler
command-line. I have not tested this since all my hosts are OK from
this issue, but perhaps you can on your build host?

Re: devel/mico failing due to failed assertion

[Karel Gardas]

On Thu, Mar 10, 2016 at 3:13 PM, Marc Espie <es...@nerim.net> wrote:
> On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote:
>> This is a sign of not so correct network configuration. MICO is really
>> picky about it so it should be able to resolve your host name/IP
>> address. What's failing precisely in the assert above is that it's not
>> able to get IP for your hostname. Can you confirm that this is the
>> case?
>
> Nope. This is the only port in the tree that doesn't like it when you cut
> network access during build (which proper build machines have started doing
> for a while now).

This would be strange since I commonly build MICO w/o any internet connection.

> I've looked a bit further, and that stupid test is so deep embedded within
> the mico code itself that it will be a pain to fix.

Indeed, it is, but I guess this was done for a good reason in the past
and I would rather keep it this way. What I can certainly do for
2.3.14 release is to add some clear error message pointing to the
incorrect network configuration.

Re: devel/mico failing due to failed assertion

[Karel Gardas]

This is a sign of not so correct network configuration. MICO is really
picky about it so it should be able to resolve your host name/IP
address. What's failing precisely in the assert above is that it's not
able to get IP for your hostname. Can you confirm that this is the
case?

On Thu, Mar 10, 2016 at 11:05 AM, Michael McConville  wrote:
> It's been failing reliably on my machine since I started bulk building a
> couple months ago.
>
>
 Building on localhost under devel/mico
>  BDEPENDS = [devel/gmake]
>  DIST = [devel/mico:mico-2.3.13.tar.gz]
>  FULLPKGNAME = mico-2.3.13p0
> (Junk lock failure for localhost at 1455583281)
> Received IO
> (Junk lock obtained for localhost at 1455583287)
> Woken up devel/mico
> Woken up devel/mico
> Woken up devel/mico
> Short-cut: depends already handled by devel/avr/gcc
 Running show-prepare-results in devel/mico at 1455583287
> ===> devel/mico
> ===> mico-2.3.13p0 depends on: gmake-* -> gmake-4.1p0
> ===>  Verifying specs:  c m ncurses readline stdc++ crypto ssl ICE SM X11 Xt 
> pthread
> ===>  found c.84.2 m.9.0 ncurses.14.0 readline.4.0 stdc++.57.0 crypto.37.0 
> ssl.38.0 ICE.10.0 SM.9.0 X11.16.1 Xt.11.0 pthread.20.1
> gmake-4.1p0
> (Junk lock released for localhost at 1455583288)
> distfiles size=3269814
 Running patch in devel/mico at 1455583288
> ===> devel/mico
> ===>  Checking files for mico-2.3.13p0
> `/mnt/big/ports/distfiles/mico-2.3.13.tar.gz' is up to date.
> ===>  Extracting for mico-2.3.13p0
> ===>  Patching for mico-2.3.13p0
 Running configure in devel/mico at 1455583290
> ===> devel/mico
> ===>  Configuring for mico-2.3.13p0
> Using /home/dpb-wrk/mico-2.3.13/config.site (generated)
> loading site script /home/dpb-wrk/mico-2.3.13/config.site
> creating cache ./config.cache
> checking for extra include and lib directories...
> checking host system type... x86_64-unknown-openbsd5.9
> checking target system type... x86_64-unknown-openbsd5.9
> checking build system type... x86_64-unknown-openbsd5.9
> checking for gcc... cc
> checking whether the C compiler (cc -O2 -pipe ) works... yes
> checking whether the C compiler (cc -O2 -pipe ) is a cross-compiler... no
> checking whether we are using GNU C... (cached) yes
> checking whether cc accepts -g... (cached) yes
> checking how to run the C preprocessor... cc -E
> checking for c++... c++
> checking whether the C++ compiler (c++ -O2 -pipe ) works... yes
> checking whether the C++ compiler (c++ -O2 -pipe ) is a cross-compiler... no
> checking whether we are using GNU C++... yes
> checking whether c++ accepts -g... (cached) yes
> checking how to run the C++ preprocessor... c++ -E
> checking for POSIXized ISC... no
> checking OS Type... unix
> checking for open in -lpthread... yes
> checking for pthread.h... (cached) yes
> checking for sched.h... yes
> checking for semaphore.h... (cached) yes
> checking for bison... yacc
> checking for flex... (cached) flex
> checking for yywrap in -lfl... (cached) yes
> checking for ar... ar rc
> checking for ranlib... ranlib
> checking whether gmake sets ${MAKE}... yes
> checking for tclsh... tclsh
> checking for javac... no
> checking for JavaCUP... no
> configure: warning: you have not installed JDK 1.1 and JavaCUP. java parts 
> disabled.
> checking for esnacc/c++/asn-incl.h... no
> checking for open in -lc++asn1... no
> checking for esnacc... no
> checking for smp/AttributeCertificateDefinitions.h... no
> checking for open in -lcmlasn... no
> checking for open in -lm... (cached) yes
> checking for open in -lnsl... no
> checking for X... (cached) libraries /usr/X11R6/lib, headers 
> /usr/X11R6/include
> checking for dnet_ntoa in -ldnet... no
> checking for dnet_ntoa in -ldnet_stub... no
> checking for gethostbyname... (cached) yes
> checking for connect... (cached) yes
> checking for remove... (cached) yes
> checking for shmat... (cached) yes
> checking for IceConnectionNumber in -lICE... (cached) yes
> checking for open in -lsocket... no
> checking for open in -lbsd... no
> checking for open in -lelf... no
> checking for open in -ldl... no
> checking for open in -ldld... no
> checking for open in -lld... no
> checking for open in -lcrypto... yes
> checking for open in -lssl... yes
> checking for open in -lncurses... yes
> checking for readline in -lreadline... yes
> checking for ANSI C header files... (cached) yes
> checking for fcntl.h... (cached) yes
> checking for unistd.h... (cached) yes
> checking for sys/select.h... (cached) yes
> checking for strings.h... (cached) yes
> checking for float.h... (cached) yes
> checking for ieeefp.h... yes
> checking for sys/un.h... (cached) yes
> checking for netinet/in.h... (cached) yes
> checking for arpa/inet.h... (cached) yes
> checking for netdb.h... (cached) yes
> checking for dlfcn.h... (cached) yes
> checking for dl.h... no
> checking for netinet/tcp.h... (cached) yes
> checking for stdlib.h... (cached) yes
> checking for sys/time.h... (cached) yes
> checking for 

Re: alpha-1.ports.openbsd.org bulk build report

[Karel Gardas]

> It has been fixed upstream:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140

looks like in 5.1.1 which is GPL3 so probably not usable to be merge
into the OpenBSD's GPL2 4.2.1? But well, I'm not the lawyer here i
just see two different licenses so it raises red flag here...

Re: www/xombrero Segmentation fault (core dumped) on macppc -current from Feb 8.

[Karel Gardas]

> would blow the same. No informations are needed, just someone brave (or
> foolish?) enough to pick up the ball and fix webkit on powerpc. I lost
> too many hours on this in the past and gave up.

I'm curious if the same happen on sparc64? i.e. maybe endianess issue
or if not, then directly ppc? If so, then if compiling xombrero with
new gcc/binutils helps or not?

Re: www/xombrero Segmentation fault (core dumped) on macppc -current from Feb 8.

[Karel Gardas]

gdb `which xombrero` 

and enter `bt' and hit enter -- this will bring you the stack trace of
the place where it crashed. If you compile xombrero with debugging
enabled (-g gcc option) you will even see lines of code...

Is this your new G5? If so, congratulations!

On Tue, Feb 9, 2016 at 11:43 PM, Christoph R. Murauer  wrote:
> Hello !
>
> I installed xombrero using pkg_add and, tried to launch it. The results are 
> different but ends mostly like
>
> $xombrero
> xombrero: config_parse: cannot open /home/crm/.xombrero.conf: No such file or 
> directory
> xombrero: runtime file doesn't exist, creating it
> xombrero: start of day file doesn't exist, creating it
> xombrero: favorites file doesn't exist, creating it
> xombrero: quickmarks file doesn't exist, creating it
>
> (xombrero:7639): Gtk-WARNING **: Theme parsing error: xombrero.css:28:11: Not 
> using units is deprecated. Assuming 'px'.
>
> (xombrero:7639): Gtk-WARNING **: Theme parsing error: xombrero.css:29:10: Not 
> using units is deprecated. Assuming 'px'.
> Segmentation fault (core dumped)
>
> At some tries I get a window where xombrero tries to load the default 
> startpage - which doesn't exists. It ends always in a Segmentation fault 
> specially if I try to upen a url.
>
> Which other informations are needed, that someone could look at it ?

Re: jdk 1.8 compilation

[Karel Gardas]

I would think that increasing your account limits should be enough to
get rid of OOM exception. I would also think that JDK compilation may
be quite memory hog so please be generous with giving enough.

On Sun, Feb 7, 2016 at 9:47 AM, Yozo TODA  wrote:
> I tried to compile jdk 1.8 (on amd64) but fails with exception 
> "OutOfMemoryError",
> which indicates more memory is required.
>
> I suppose I need to enlarge datasize for the account (configured in 
> /etc/login.conf),

Re: Haskell on PowerPC (Was: Questions about PowerMac G5 (fan control, haskell) ?)

[Karel Gardas]

Try to use cross-compilation. I think GHC HEAD should be quite OK on
this. GHC also provides functional PowerPC backend which was even
enhanced to support 64bit so I think there is really high chance you
will be able to succeed. The tricky part is in configuration where you
will need to experiment a little bit probably and if the platform is
not supported directly you will need to modify aclocal.m4 file to add
its handling. Then `perl boot' to bootstrap configure. For configure
you will need to use --target=powerpc-openbsd probably (don't know
exact platform name). Verify configure output, see settings file
generated. If this is sane just `gmake'. Also if you vi
mk/flavours/quick-cross.mk -- and comment out Stage1Only and cp
mk/build.mk.sample mk/build.mk and vi mk/build.mk and set flavour to
quick cross -- then I guess also stage2 compiler should be compiled.
So try also preferred --prefix= for compilation, `gmake install'
on your host. Move installed tree to your powerpc and there ghc should
be functional. If not verify that you get ghc-stage2 binary by
installation process. If not, just move ghc-satge2 to your target.
Simply speaking: ghc-stage1 is host-based corss-compiler for your
target while ghc-stage2 is cross-compiled ghc ready to be run on your
target. You can find both in inplace/bin/ in the build tree. All libs
(nearly) are build with ghc-stage1 so they should be target ready.
It's possible that ghc-stage2 will not be fully functional and some
parts missing -- template haskell (TH)? If so, then you can attempt
new bootstrap directly on target using this compiler to get full ghc.

On Mon, Feb 1, 2016 at 12:14 AM, Christoph R. Murauer  wrote:
>> On Sun, Jan 31, 2016 at 11:38:48PM +0100, Matthias Kilian wrote:
>>> > > Any chances (have no machine to try it) to build the community /
>>> older
>>> > > version of ghc ?
>>
>> [...]
>>
>>> 2.Try to get a ghc-6.6.1 .hc file bundle for ppc from somewhere at
>>>   *.haskell.org (and add it to the fetch() function of the
>>>   ghc-bootstrap.sh)
>>
>> Oops! I just noticed that the .hc file bundles I used for ghc-6.6.1
>> were already os-dependent. So there are only the options to start
>> over from ghc-3.02 or to use cross-compilation.
>>
>> Ciao,
>>   Kili
>>
>>
>
> Thanks for your answer and the detailed explanation. I will try it
> when the planned hardware arrives.
>
>
>

Re: Haskell on PowerPC (Was: Questions about PowerMac G5 (fan control, haskell) ?)

[Karel Gardas]

On Mon, Feb 1, 2016 at 4:22 PM, Christoph R. Murauer  wrote:
> Thanks for your detailed answer. If the machine arrives, I will give
> it a try at the weekend.
>
> I also think, that cross compiling is the best solution. I will use a
> snapshot for it. Depending on how many macppc users are interested,
> there is also a 32 bit version (for the supported G3 and G4 CPU's)
> needed.

I've thought even on G5 OpenBSD is still 32bit, isn't it?

> It would be nice, if we could get a official ghc / haskell-platform
> for macppc.

Depends on available hardware/testers etc. I'm afraid target group is
so small that haskell-platfrom community will not do this, so this is
more for OpenBSD ports team...

Re: pledge(2) binding for Haskell

[Karel Gardas]

Hello,

I've thought it would be nice if Haskell type checker would work into
our strength. Attached patch defines algebraic data type Promise and
use this for calling pledge sys call. The patch also provides two
version of Promise to string conversion function. One is explicit and
another is using show capability and just fixes prot_exec case.

Any comments highly appreciated.

Thanks,
Karel

Index: Process.hsc
===
RCS file: /cvs/ports/lang/ghc/files/Process.hsc,v
retrieving revision 1.1
diff -u -p -u -r1.1 Process.hsc
--- Process.hsc 20 Jan 2016 16:02:06 -  1.1
+++ Process.hsc 23 Jan 2016 13:15:42 -
@@ -1,14 +1,77 @@
 {-# LANGUAGE Safe #-}

-module System.OpenBSD.Process ( pledge ) where
+module System.OpenBSD.Process ( pledge, Promise(..) ) where

 import Foreign
 import Foreign.C
 import System.Posix.Internals ( withFilePath )
+import Data.Char

-pledge :: String -> Maybe [FilePath] -> IO ()
+data Promise = Stdio
+ | RPath
+ | WPath
+ | CPath
+ | DPath
+ | TmpPath
+ | Inet
+ | FAttr
+ | FLock
+ | Unix
+ | Dns
+ | GetPW
+ | SendFD
+ | RecvFD
+ | IOCtl
+ | Tty
+ | Proc
+ | Exec
+ | ProtExec
+ | SetTime
+ | Ps
+ | VMInfo
+ | Id
+ | Pf
+   deriving (Show)
+{-
+promise2String :: Promise -> String
+promise2String p = case p of
+  Stdio-> "stdio"
+  RPath-> "rpath"
+  WPath-> "wpath"
+  CPath-> "cpath"
+  DPath-> "dpath"
+  TmpPath  -> "tmppath"
+  Inet -> "inet"
+  FAttr-> "fattr"
+  FLock-> "flock"
+  Unix -> "unix"
+  Dns  -> "dns"
+  GetPW-> "getpw"
+  SendFD   -> "sendfd"
+  RecvFD   -> "recvfd"
+  IOCtl-> "ioctl"
+  Tty  -> "tty"
+  Proc -> "proc"
+  Exec -> "exec"
+  ProtExec -> "prot_exec"
+  SetTime  -> "settime"
+  Ps   -> "ps"
+  VMInfo   -> "vminfo"
+  Id   -> "id"
+  Pf   -> "pf"
+-}

-pledge promises paths =
+promise2String :: Promise -> String
+promise2String p = case p of
+  ProtExec -> "prot_exec"
+  _-> map toLower (show p)
+
+pledge :: [Promise] -> Maybe [FilePath] -> IO ()
+pledge promises = cpledge (unwords $ map promise2String promises)
+
+cpledge :: String -> Maybe [FilePath] -> IO ()
+
+cpledge promises paths =
   withCString promises $ \cproms ->
   withPaths2Array0 paths $ \paths_arr ->
   throwErrnoIfMinus1_ "pledge" (c_pledge cproms paths_arr)

On Wed, Jan 20, 2016 at 5:38 AM, Matthias Kilian  wrote:
> On Tue, Jan 19, 2016 at 08:43:17PM +0100, Matthias Kilian wrote:
>> > Below is a hopefully correct and more complete diff. Again without
>> > bump because I'll also merge -main and -doc.
>>
>> Famous last words. I missed the plist changes. Will send a new diff
>> later (at the moment i'm rebuilding ghc).
>
> Here it is. Works fine for me, so I'm going to commit this in a few
> hours.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ghc/Makefile,v
> retrieving revision 1.131
> diff -u -p -r1.131 Makefile
> --- Makefile28 Dec 2015 19:18:52 -  1.131
> +++ Makefile20 Jan 2016 04:24:09 -
> @@ -157,6 +157,11 @@ PORTHOME = ${WRKDIR}
>
>  TEST_DEPENDS = print/ghostscript/gnu
>
> +post-extract:
> +   cd ${WRKSRC}/libraries/unix && \
> +   mkdir -p System/OpenBSD && \
> +   install -m 644 ${FILESDIR}/Process.hsc System/OpenBSD
> +
>  post-patch:
>  # - Install a precompiled binary.
> cd ${WRKDIR}/ghc-${BIN_VER} && \
> Index: files/Process.hsc
> ===
> RCS file: files/Process.hsc
> diff -N files/Process.hsc
> --- /dev/null   1 Jan 1970 00:00:00 -
> +++ files/Process.hsc   20 Jan 2016 04:24:09 -
> @@ -0,0 +1,26 @@
> +{-# LANGUAGE Safe #-}
> +
> +module System.OpenBSD.Process ( pledge ) where
> +
> +import Foreign
> +import Foreign.C
> +import System.Posix.Internals ( withFilePath )
> +
> +pledge :: String -> Maybe [FilePath] -> IO ()
> +
> +pledge promises paths =
> +  withCString promises $ \cproms ->
> +  withPaths2Array0 paths $ \paths_arr ->
> +  throwErrnoIfMinus1_ "pledge" (c_pledge cproms paths_arr)
> +
> +withPaths2Array0 :: Maybe [FilePath] -> (Ptr (Ptr CChar) -> IO a) -> IO a
> +
> +withPaths2Array0 Nothing f = f nullPtr
> +
> +withPaths2Array0 (Just paths) f =
> +  withMany withFilePath paths $ \cstrs ->
> +  withArray0 nullPtr cstrs $ \paths_arr ->
> +  f paths_arr
> +
> +foreign import ccall unsafe "unistd.h pledge"
> +  c_pledge :: CString -> Ptr CString -> IO CInt
> Index: patches/patch-libraries_unix_unix_cabal
> ===
> RCS file: patches/patch-libraries_unix_unix_cabal
> 

Re: GHC 8.0.1 RC1

[Karel Gardas]

On Sat, Jan 23, 2016 at 11:03 PM, Matthias Kilian
 wrote:
> Awesome. This works without any patches?

Yes, no additional patches necessary! Well, I've basically took your
accumulated patches and pushed them upstream with just my little-bit
to enable shared libs and PIE. No big deal, but I've thought this is
right way to go with this...
One day, if you feel free GHC-hacking time you may start with strlcpy
& co. conversion of GHC rts. :-)

> I hope the final release will contain the files generated by alex
> and happy (for obvious reasons).

Unfortunately I don't see this happening any time soon...In fact it'll
become even more complicated with shake build system I'm afraid in the
future.

> Anyway, thanks for your work on upstream ghc.

Yep, but you did 95% of the work anyway, so kudos to you!

Cheers,
Karel

Re: pledge(2) binding for Haskell

[Karel Gardas]

Hi Kili,

On Sat, Jan 23, 2016 at 10:54 PM, Matthias Kilian
 wrote:

> Well, it's of course more elegant, but it would also mean that
> everytime a new pledge promise will be introduced or an existing
> one removed, this type has to be changed. I don't know how stable
> the set of promises of pledge(2) are, but it feels like a change
> like this should be deferred until after 5.9.

I tend to agree, but on the other hand. Hmm, I guess you did this as
you've been motivated to pledge some of haskell-based binaries you
maintain packages for? If so, then with your approach if some promise
is removed and you use it in package binary, then you will not find
this by building the package but only by running it (EINVAL return
value from pledge). On the other hand if you do this more
type-constrained way (like I non-perfectly try), then you will find
this kind of issues just by compiling the package -- so wil it save
your time or not? :-)

Anyway, sure, I've thought about writing hs-pledge myself, but just
after 5.9 to see how the interface evolve so you are really quick on
this, kudos to you!

> ps: at least the "audio" "drm" and "vmm" promises are missing in
> your diff, so now we know how old your installation is ;-)

*red face here* :-) -- hmm, I'm too lazy to do cvs -> git/fossil sync
here that often, I keep whole tree in git (and one branch in fossil)
since I still work on SR-RAID1C and both are more convenient for me
than plain anon-CVS. Still learning how to do this properly...

Thanks,
Karel

GHC 8.0.1 RC1

[Karel Gardas]

Hello,

GHC 8.0.1 RC1 is announced here:
https://mail.haskell.org/pipermail/ghc-devs/2016-January/010966.html

what may be interesting for OpenBSD/GHC users is that this release/rc1
supports shared libraries and position independent executables. To
build you need to have ghc, alex, happy, libffi, libiconv, gmp and
gmake installed from ports, configure with:

./configure --with-gmp-includes=/usr/local/include/
--with-gmp-libraries=/usr/local/lib
--with-iconv-includes=/usr/local/include/
--with-iconv-libraries=/usr/local/lib --with-system-libffi
--with-ffi-includes=/usr/local/include/
--with-ffi-libraries=/usr/local/lib

and build with gmake.

GHC binary distribution built by me is available here:
https://app.box.com/s/95lpdhoc5h0zs0mx3chlacdl3hskzkqi and SHA256SUM
file here: https://app.box.com/s/0t3kutu8i3xhhs1vh97x6vcmjdnvlm78 --
this is GHC binary distribution, not OpenBSD package. You need to
unpack and configure and then just gmake install it. I've build on
fairly recent 5.9-beta/current.

Cheers,
Karel

Re: Firefox performance regressions

[Karel Gardas]

If this is about malloc and it's locking, have anybody tried to use
some custom more C++ friendly malloc lib like google's tcmalloc?
Another possibility is to gdb attach to firefox and than attempt to
track down where those excessive locks happen or hack ltrace to
print/save full stack trace if this is possible. Seeing the
responsible code may help or not here. And constructing similar
testcase which would duplicate the same behaviour would be probably
something what rthread library authors would most welcome...

On Wed, Jan 6, 2016 at 12:06 PM, Martin Pieuchot  wrote:
> On 06/01/16(Wed) 11:19, Landry Breuil wrote:
>> [...]
>> i've had multiple ppl coming to me privately about this - Yes,
>> performance with firefox has been steadily degrading in the past
>> releases, since around 39 or so - i'm aware of this, but nobody is
>> actually working on it - i won't/can't since this is way out my skills
>> and i have no time nor motivation for that.
>>
>> Debugging this requires profiling / running the browser within ktrace
>> and figuring out why apparently it does way much more syscalls than
>> before, which might be a clue, or not. Of course since you cant really
>> use traditional tools like gdb, your toolbox is empty. Or that could be
>> graphical stack regressions. Or so many other things. The builtin
>> profiler needs specific code to work on OpenBSD.
>>
>> Anybody is welcome to look into it - or 5.9 will ship with firefox 43
>> as is.
>
> I started looking at this but didn't go far.  It seems that the problem
> is related to/exposed by the use of pthread_mutex_lock(3) & friends. I
> tried to analyze ltrace(1) outputs, but I got lost in Firefox's sources.
> I really don't know where to look at.
>
> Here's what I wrote two months ago:
>
> On 18/11/15(Wed) 20:44 +0100, Martin Pieuchot wrote:
>> The actual firefox port (not the -esr one) might be exposing a bug in
>> librthread resulting in a storm of sched_yield(2) calls when multiples
>> threads are trying to access the same lock, see _spinlock().
>>
>> I generated two ltrace(1) dumps for librthread hackers to have a look
>> at.  They are both generate with a hacked version of ltrace(1) with:
>>
>>   $ ltrace -p $pid -t cu -u libpthread ; sleep 2; ktrace -C
>>
>> After having started firefox with:
>>
>>   $ LD_TRACE_PLT="" LD_TRACE_PLTSPEC="libpthread" DISPLAY=:0 firefox
>>
>>
>> The dumps are generate while firefox is sitting in its own custom home
>> page.
>>
>>
>> kump-esr.txt  a dump of the firefox-esr which work "not so bad"
>>
>> kdump-nightly.txt a dump of firefox's trunk which expose the problem
>>
>>
>> $ grep sched_yield kdump-esr.txt |wc -l
>>4
>> $ grep sched_yield kdump-nightly.txt  |wc -l
>> 89418
>>
>>
>> The sequence below is an extract of what you can find there, when you
>> have multiple threads fighting for the malloc lock...  this goes on
>> forever and gets even worse when thread 1019109 returns from thrsleep...
>>
>> Apparently they are all waiting for thread 1010468 to release the malloc
>> lock or...  is it bad doctor?
>>
>>
>>  13288/1032189 firefox-bin RET   sched_yield 0
>>  13288/1010095 firefox-bin USER  .plt symbol: 7 bytes"__errno"
>>  13288/1032189 firefox-bin USER  .plt symbol: 12 bytes"_atomic_lock"
>>  13288/1010095 firefox-bin USER  .plt symbol: 19 bytes
>> "_thread_malloc_lock"
>>  13288/1032189 firefox-bin CALL  sched_yield()
>>  13288/1027370 firefox-bin USER  .plt symbol: 11 bytes"_spinunlock"
>>  13288/1010095 firefox-bin USER  .plt symbol: 9 bytes"_spinlock"
>>  13288/1027370 firefox-bin USER  .plt symbol: 7 bytes"__errno"
>>  13288/1010095 firefox-bin USER  .plt symbol: 12 bytes"_atomic_lock"
>>  13288/1010095 firefox-bin CALL  sched_yield()
>>  13288/1027370 firefox-bin USER  .plt symbol: 19 bytes
>> "_thread_malloc_lock"
>>  13288/1010095 firefox-bin RET   sched_yield 0
>>  13288/1027370 firefox-bin USER  .plt symbol: 9 bytes"_spinlock"
>>  13288/1010095 firefox-bin USER  .plt symbol: 12 bytes"_atomic_lock"
>>  13288/1027370 firefox-bin USER  .plt symbol: 12 bytes"_atomic_lock"
>>  13288/1010095 firefox-bin CALL  sched_yield()
>>  13288/1027370 firefox-bin CALL  sched_yield()
>>  13288/1032189 firefox-bin RET   sched_yield 0
>>  13288/1032189 firefox-bin USER  .plt symbol: 12 bytes"_atomic_lock"
>>  13288/1032189 firefox-bin CALL  sched_yield()
>>  13288/1027370 firefox-bin RET   sched_yield 0
>>  13288/1027370 firefox-bin USER  .plt symbol: 12 bytes"_atomic_lock"
>>  13288/1027370 firefox-bin CALL  sched_yield()
>>  13288/1032189 firefox-bin RET   sched_yield 0
>>  13288/1032189 firefox-bin USER  .plt symbol: 12 bytes"_atomic_lock"
>>  13288/1032189 firefox-bin CALL  sched_yield()
>>  13288/1027370 firefox-bin RET   sched_yield 0
>>  13288/1010095 firefox-bin RET   sched_yield 0
>>  13288/1027370 firefox-bin USER  .plt symbol: 12 bytes

Re: Eclipse on OpenBSD 5.7 java.lang.UnsatisfiedLinkError

[Karel Gardas]

Now the question is if this jar is proper bundle and if so if it's
mentioned somewhere in Eclipse OSGi configuration. Do you have
configuration/config.ini file? Is there a bundle list inside it or is
there kind of simple configuration use? i.e. have a look into
osgi.bundles= line.
If simple cofiguration is used, then take it's name and see
bundles.info inside configuration/ --
verify that org.eclipse.swt.gtk.openbsd is mentioned there in some
form.

I'm sorry but I can't verify myself as I don't have Eclipse running on
OBSD yet and on Linux I do have 4.5. release which may be quite
different from 3.x on OBSD...

On Mon, Sep 14, 2015 at 8:56 PM, Jack J. Woehr  wrote:
> Built eclipse today /usr/ports/devel/eclipse
>
> When I try to run it, it throws and error dialog referring me to
> ~/worspace/.metadata/.log where I find
> (among other things):
>
> !ENTRY org.eclipse.osgi 4 0 2015-09-14 12:37:49.832
> !MESSAGE Application error
> !STACK 1
> java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3236 in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)
> at java.lang.Runtime.loadLibrary0(Runtime.java:849)
> at java.lang.System.loadLibrary(System.java:1088)
> at org.eclipse.swt.internal.Library.loadLibrary(Library.java:123)
> at org.eclipse.swt.internal.gtk.OS.(OS.java:22)
> at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
> at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54)
> at org.eclipse.swt.widgets.Display.(Display.java:126)
> at
> org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:436)
> at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
> at
> org.eclipse.ui.internal.ide.IDEApplication.createDisplay(IDEApplication.java:122)
> at
> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:75)
> at
> org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)
>
> I do find in
> /usr/local/eclipse/plugins/org.eclipse.swt.gtk.openbsd.x86_3.2.2.v3236.jar
> the following entry:
>
> 354196  Defl:N82743  77% 09-14-2015 11:30 0c58e901
> libswt-pi-gtk-3236.so.4.0
>
> The Dell Latitude D830 laptop I am running this on only as 1G of memory,
> could it be unable to load the library
> for lack of memory?
>
> $ java -version
> openjdk version "1.7.0_71"
> OpenJDK Runtime Environment (build 1.7.0_71-b14)
> OpenJDK Client VM (build 24.71-b01, mixed mode)
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. - Carl
> Sagan
>

Re: Eclipse on OpenBSD 5.7 java.lang.UnsatisfiedLinkError

[Karel Gardas]

On Mon, Sep 14, 2015 at 8:56 PM, Jack J. Woehr  wrote:
> java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3236 in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)

[...]

> I do find in
> /usr/local/eclipse/plugins/org.eclipse.swt.gtk.openbsd.x86_3.2.2.v3236.jar
> the following entry:
>
> 354196  Defl:N82743  77% 09-14-2015 11:30 0c58e901
> libswt-pi-gtk-3236.so.4.0
>
> The Dell Latitude D830 laptop I am running this on only as 1G of memory,
> could it be unable to load the library
> for lack of memory?

I don't think so. UnsatisfiedLinkError is usually a sign of not being
able to find the library, nothing more.

Re: lang/ghc update preview

[Karel Gardas]

Hi,

seeing this, I'd like to note that I've got some of your patches to
GHC HEAD which will become 7.12 once released probably so this may
easy your job a little bit. I've also done some testing and switched
on dynamic libraries and full PIE stuff. Got some optimistic results
(means majority of tests pass), but so far the biggest obstacle on the
way is how port's libffi is linked. Unfortunately my email[1] about it
is kind of ignored. Perhaps you may say your word about it so I'll
know what's the preferred way here? Thanks! Karel

[1]: http://marc.info/?l=openbsd-portsm=143590886630557w=2

On Sun, Aug 16, 2015 at 11:11 PM, Matthias Kilian
k...@outback.escape.de wrote:
 Hi,

 this is a quick and dirty update of ghc to version 7.10.2, meant
 for people who want to play with it.

 I've not built anything else in the ports tree with it yet, because
 hs-libraries are now stored in a completely different way, (look
 at that *_SIG blurb  in the Makefile and in PLIST-main).

 Ciao,
 Kili

On Sun, Aug 16, 2015 at 11:11 PM, Matthias Kilian
k...@outback.escape.de wrote:
 Hi,

 this is a quick and dirty update of ghc to version 7.10.2, meant
 for people who want to play with it.

 I've not built anything else in the ports tree with it yet, because
 hs-libraries are now stored in a completely different way, (look
 at that *_SIG blurb  in the Makefile and in PLIST-main).

 Ciao,
 Kili

 Index: Makefile
 ===
 RCS file: /cvs/ports/lang/ghc/Makefile,v
 retrieving revision 1.118
 diff -u -p -r1.118 Makefile
 --- Makefile25 Jun 2015 11:40:08 -  1.118
 +++ Makefile9 Aug 2015 22:28:44 -
 @@ -11,14 +11,12 @@ COMMENT-doc =   documentation for GHC

  DISTNAME = ghc-${MODGHC_VER}
  PKGNAME-main = ghc-${MODGHC_VER}
 -REVISION-main =2
  PKGNAME-doc =  ghc-doc-${MODGHC_VER}
 -REVISION-doc = 0
  CATEGORIES =   lang devel
  HOMEPAGE = https://www.haskell.org/ghc/

  # Version of the precompiled binaries
 -BIN_VER =  7.8.3.20150623
 +BIN_VER =  7.8.4.20150803

  # Pull in lang/ghc to get MODGHC_VER and ONLY_FOR_ARCHS, which is maintained
  # in ghc.port.mk. lang/python needed for regression tests.
 @@ -62,6 +60,78 @@ BINDISTFILE-$m = ghc-${BIN_VER}-$m-unkno
  SUPDISTFILES +=${BINDISTFILE-$m}
  .endfor

 +# Newest madness from the haskell world: packages are now stored in a
 +# directory named after the package 'key', which is made out of an
 +# abbreviation of the package name and the package 'signature'.
 +CABAL_SIG =96aI7pZyaxU3dsgngOxbdK
 +ARRAY_SIG =E0sTtauuKsGDLZoT7lTbgZ
 +BASE_SIG = GDytRqRVSUX7zckgKqJjgw
 +BINARY_SIG =   IvYoLp9H6Xy3zEH13MmZwd
 +BIN_PACKAGE_DB_SIG =   HeqFuAPxbeUAPK6hSBHejU
 +BYTESTRING_SIG =   6elQVSg5cWdFrvRnfxTUrH
 +CONTAINERS_SIG =   LKCPrTJwOTOLk4OU37YmeN
 +DEEPSEQ_SIG =  LbCWUlehDDeLxurARKDH5o
 +DIRECTORY_SIG =KowvXytSqazBcvN7MGpFtg
 +FILEPATH_SIG = KsGE6pHE5eZHSN90ZVax6A
 +GHC_SIG =  JzwEp1oQ8kA7NFNTGk1ho5
 +GHC_PRIM_SIG = 8TmvWUcS1U1IKHT0levwg3
 +HASKELINE_SIG =1dVCRhdIH7hAQWJrKwByYv
 +HOOPL_SIG =DoMsb793VEWGUzPylcUNJi
 +HPC_SIG =  EoBo26ZW1TCDX9aShnDKTF
 +INTEGER_GMP_SIG =  2aU3IZNMF9a7mQ0OzsZ0dS
 +PRETTY_SIG =   7UQTOB05U7lIYPkFOVraeR
 +PROCESS_SIG =  FLTz0SLwyG6LJUpZ52HjkU
 +TEMPLATE_HASKELL_SIG = 1ejK907jvoTHoZ6iZtHeyN
 +TERMINFO_SIG = KvtqTNXWuWjKicEYaZ7qsx
 +TIME_SIG = AXTdBF9VRQoBOqJT6qtmVH
 +TRANSFORMERS_SIG = 3eG64VdP2vzGjP6wJiCp5X
 +UNIX_SIG = A3WgcI5QiHK4PDo4jSYdwQ
 +XHTML_SIG =FxPylgBilld3tRCpn3X21N
 +
 +SUBST_VARS +=  CABAL_SIG ARRAY_SIG BASE_SIG BINARY_SIG \
 +   BIN_PACKAGE_DB_SIG BYTESTRING_SIG \
 +   CONTAINERS_SIG DEEPSEQ_SIG DIRECTORY_SIG \
 +   FILEPATH_SIG GHC_SIG GHC_PRIM_SIG \
 +   HASKELINE_SIG HOOPL_SIG HPC_SIG \
 +   INTEGER_GMP_SIG PRETTY_SIG PROCESS_SIG \
 +   TEMPLATE_HASKELL_SIG TERMINFO_SIG TIME_SIG \
 +   TRANSFORMERS_SIG UNIX_SIG XHTML_SIG
 +
 +# At this point, we can as well factor out package version numbers to
 +# get smaller PLIST diffs for future updates.
 +# But don't include GHC_VER (already covered by MODGHC_VER) nor
 +# BIN_PACKAGE_DB_VER (always 0.0.0.0).
 +CABAL_VER =1.22.4.0
 +ARRAY_VER =0.5.1.0
 +BASE_VER = 4.8.1.0
 +BINARY_VER =   0.7.5.0
 +BYTESTRING_VER =   0.10.6.0
 +CONTAINERS_VER =   0.5.6.2
 +DEEPSEQ_VER =  1.4.1.1
 +DIRECTORY_VER =1.2.2.0
 +FILEPATH_VER = 1.4.0.0
 +GHC_PRIM_VER = 0.4.0.0
 +HASKELINE_VER =0.7.2.1
 +HOOPL_VER =3.10.0.2
 +HPC_VER =

Re: devel/boost fails to build on sparc64

[Karel Gardas]

Shouldn't also kind of
https://github.com/boostorg/build/commit/ec60c37295146bb80aa44a92cf416027b75b5ff7
goes in?

On Tue, Jul 28, 2015 at 4:42 PM, Jérémie Courrèges-Anglas
j...@wxcvbn.org wrote:
 Stuart Henderson s...@spacehopper.org writes:

 It's just complaining about -mcpu=c3 (which we don't want anyway) so this 
 should be easy enough to fix..

 Indeed.  Markus, does boost successfuly package with the following
 patch?

 cc'ing Brad.

 Index: patches/patch-tools_build_src_tools_gcc_jam
 ===
 RCS file: /cvs/ports/devel/boost/patches/patch-tools_build_src_tools_gcc_jam,v
 retrieving revision 1.2
 diff -u -p -r1.2 patch-tools_build_src_tools_gcc_jam
 --- patches/patch-tools_build_src_tools_gcc_jam 10 Jul 2015 08:13:46 -
   1.2
 +++ patches/patch-tools_build_src_tools_gcc_jam 28 Jul 2015 14:37:02 -
 @@ -1,6 +1,6 @@
  $OpenBSD: patch-tools_build_src_tools_gcc_jam,v 1.2 2015/07/10 08:13:46 
 jasper Exp $
  --- tools/build/src/tools/gcc.jam.orig Sat Apr  4 19:25:07 2015
 -+++ tools/build/src/tools/gcc.jam  Fri Jul 10 10:13:10 2015
  tools/build/src/tools/gcc.jam  Tue Jul 28 16:36:55 2015
  @@ -337,7 +337,7 @@ class gcc-pch-generator : pch-generator
   # Return result of base class and pch-file property as
   # usage-requirements.
 @@ -68,3 +68,127 @@ $OpenBSD: patch-tools_build_src_tools_gc
   }

   rule setup-threading ( targets * : sources * : properties * )
 +@@ -1068,123 +1067,3 @@ local rule cpu-flags ( toolset variable : 
 architecture
 + }
 +
 +
 +-# Set architecture/instruction-set options.
 +-#
 +-# x86 and compatible
 +-# The 'native' option appeared in gcc 4.2 so we cannot safely use it as 
 default.
 +-# Use i686 instead for 32-bit.
 +-toolset.flags gcc OPTIONS 
 architecturex86/address-model32/instruction-set : -march=i686 ;
 +-cpu-flags gcc OPTIONS : x86 : native : -march=native ;
 +-cpu-flags gcc OPTIONS : x86 : i486 : -march=i486 ;
 +-cpu-flags gcc OPTIONS : x86 : i586 : -march=i586 ;
 +-cpu-flags gcc OPTIONS : x86 : i686 : -march=i686 ;
 +-cpu-flags gcc OPTIONS : x86 : pentium : -march=pentium ;
 +-cpu-flags gcc OPTIONS : x86 : pentium-mmx : -march=pentium-mmx ;
 +-cpu-flags gcc OPTIONS : x86 : pentiumpro : -march=pentiumpro ;
 +-cpu-flags gcc OPTIONS : x86 : pentium2 : -march=pentium2 ;
 +-cpu-flags gcc OPTIONS : x86 : pentium3 : -march=pentium3 ;
 +-cpu-flags gcc OPTIONS : x86 : pentium3m : -march=pentium3m ;
 +-cpu-flags gcc OPTIONS : x86 : pentium-m : -march=pentium-m ;
 +-cpu-flags gcc OPTIONS : x86 : pentium4 : -march=pentium4 ;
 +-cpu-flags gcc OPTIONS : x86 : pentium4m : -march=pentium4m ;
 +-cpu-flags gcc OPTIONS : x86 : prescott : -march=prescott ;
 +-cpu-flags gcc OPTIONS : x86 : nocona : -march=nocona ;
 +-cpu-flags gcc OPTIONS : x86 : core2 : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : conroe : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : conroe-xe : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : conroe-l : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : allendale : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : wolfdale : -march=core2 -msse4.1 ;
 +-cpu-flags gcc OPTIONS : x86 : merom : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : merom-xe : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : kentsfield : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : kentsfield-xe : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : yorksfield : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : penryn : -march=core2 ;
 +-cpu-flags gcc OPTIONS : x86 : corei7 : -march=corei7 ;
 +-cpu-flags gcc OPTIONS : x86 : nehalem : -march=corei7 ;
 +-cpu-flags gcc OPTIONS : x86 : corei7-avx : -march=corei7-avx ;
 +-cpu-flags gcc OPTIONS : x86 : sandy-bridge : -march=corei7-avx ;
 +-cpu-flags gcc OPTIONS : x86 : core-avx-i : -march=core-avx-i ;
 +-cpu-flags gcc OPTIONS : x86 : ivy-bridge : -march=core-avx-i ;
 +-cpu-flags gcc OPTIONS : x86 : haswell : -march=core-avx-i -mavx2 -mfma 
 -mbmi -mbmi2 -mlzcnt ;
 +-cpu-flags gcc OPTIONS : x86 : k6 : -march=k6 ;
 +-cpu-flags gcc OPTIONS : x86 : k6-2 : -march=k6-2 ;
 +-cpu-flags gcc OPTIONS : x86 : k6-3 : -march=k6-3 ;
 +-cpu-flags gcc OPTIONS : x86 : athlon : -march=athlon ;
 +-cpu-flags gcc OPTIONS : x86 : athlon-tbird : -march=athlon-tbird ;
 +-cpu-flags gcc OPTIONS : x86 : athlon-4 : -march=athlon-4 ;
 +-cpu-flags gcc OPTIONS : x86 : athlon-xp : -march=athlon-xp ;
 +-cpu-flags gcc OPTIONS : x86 : athlon-mp : -march=athlon-mp ;
 +-##
 +-cpu-flags gcc OPTIONS : x86 : k8 : -march=k8 ;
 +-cpu-flags gcc OPTIONS : x86 : opteron : -march=opteron ;
 +-cpu-flags gcc OPTIONS : x86 : athlon64 : -march=athlon64 ;
 +-cpu-flags gcc OPTIONS : x86 : athlon-fx : -march=athlon-fx ;
 +-cpu-flags gcc OPTIONS : x86 : k8-sse3 : -march=k8-sse3 ;
 +-cpu-flags gcc OPTIONS : x86 : opteron-sse3 : -march=opteron-sse3 ;
 +-cpu-flags gcc OPTIONS : x86 : athlon64-sse3 : -march=athlon64-sse3 ;
 +-cpu-flags gcc OPTIONS : x86 : amdfam10 : -march=amdfam10 ;
 +-cpu-flags gcc OPTIONS : x86 : 

Re: devel/boost fails to build on sparc64

[Karel Gardas]

Oh, I've thought Jérémie's diff just added those cpu specific flags.
Reading more carefully it looks like it adds removal of those flags
into the OpenBSD's patch file. Sorry guys for noise.

On Tue, Jul 28, 2015 at 6:27 PM, Stuart Henderson s...@spacehopper.org wrote:
 On 2015/07/28 18:10, Karel Gardas wrote:
 Shouldn't also kind of
 https://github.com/boostorg/build/commit/ec60c37295146bb80aa44a92cf416027b75b5ff7
 goes in?

 No, because we don't want to use the CPU-specific flags at all, Jérémie's diff
 removes these completely.

[PATCH] libffi -- link with pthread

[Karel Gardas]

Hello,

ports' libffi depends on libpthread but is not linked against it. That
means that any program depending on libffi also needs to link with
libpthread explicitly. It also makes some troubles in autoconf's
configure systems testing for libffi usability where on OpenBSD we get
unresolved pthread symbols and hence test fails although libffi is
available:

 /usr/local/lib/libffi.so.1.1: undefined reference to `pthread_mutex_unlock'
 /usr/local/lib/libffi.so.1.1: undefined reference to `pthread_mutex_lock'
 /usr/local/lib/libffi.so.1.1: undefined reference to `pthread_mutex_init'


This may be solved easily by linking libffi against libpthread.
Attached patch does this.

Thanks for review,

Karel


libffi.patch
Description: Binary data

POSIX threading and GCC 3.4/4.0/4.1 in ports.

[Karel Gardas]

Hello,

I'm curious what's the reason behind not building threads enabled GCCs in 
ports by default. Makefiles just contain:


# if you wish to try your luck
#CONFIGURE_ARGS+= --enable-threads=posix

I'm also curious why OpenBSD's core compiler is not thread enabled by 
default, but that's probably better for misc mailing list.


Thanks,
Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com