something got wrong with 32bit ld between 1500002 and 1500003

[Dima Panov]

Moin-moin!

After upgrade to recent -current (153) I've got a ld error for 32bit an 
aarch64 machine:(

ELF binary type "9" not known.
eval: /libexec/ld-elf32.so.1: Exec format error

Snapshot from 2023-10-13 was fine, no errors

15.0-CURRENT #0 main-6f38d2e7b0: Thu Nov 16 03:29:03 MSK 2023 is still broken


--
Sincerely,
Dima (flu...@freebsd.org, https://t.me/FluffyBSD)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8

[Dima Panov]

Moin-moin!


Some additional info.

With just-cooked -current (FreeBSD 14.0-CURRENT #1 883a49e5a: Tue Apr 25 
13:43:56 MSK 2023  arm64 1400088)
all stable releases of GCC are unable to build with same error (gcc10, gcc11, 
gcc12) :(

But! gcc*-devel ports builds fine, and finally I can build ann gcc-depended 
stuff on my box.
Tested gcc11-devel, gcc12-devel, gcc13-devel



On 14.04.2023 00:42, Dima Panov wrote:

Moin-moin!

Somethings changed in main branch between Mar, 28 and Apr, 8 which causes 
permanent build error for lang/gcc1[012] on aarch64 (exactly VMWare container 
on M1Pro mac)

during RTL pass: sched1
gimple-match.cc: In function 'bool gimple_nop_atomic_bit_test_and_p(tree, 
tree_node**, tree_node* (*)(tree))':
gimple-match.cc:39215:1: internal compiler error: Segmentation fault
39215 | }
   | ^
mmap: Invalid argument
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
gmake[4]: *** [Makefile:1145: gimple-match.o] Error 1
gmake[4]: *** Waiting for unfinished jobs
rm gcc.pod gfortran.pod




--
Sincerely,
Dima (flu...@freebsd.org, https://t.me/FluffyBSD)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team


OpenPGP_signature
Description: OpenPGP digital signature

Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8

[Dima Panov]

Moin-moin!

On 14.04.2023 01:13, Dimitry Andric wrote:

On 13 Apr 2023, at 23:42, Dima Panov  wrote:

Somethings changed in main branch between Mar, 28 and Apr, 8 which causes 
permanent build error for lang/gcc1[012] on aarch64 (exactly VMWare container 
on M1Pro mac)

during RTL pass: sched1
gimple-match.cc: In function 'bool gimple_nop_atomic_bit_test_and_p(tree, 
tree_node**, tree_node* (*)(tree))':
gimple-match.cc:39215:1: internal compiler error: Segmentation fault
39215 | }
  | ^
mmap: Invalid argument
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
gmake[4]: *** [Makefile:1145: gimple-match.o] Error 1
gmake[4]: *** Waiting for unfinished jobs
rm gcc.pod gfortran.pod


Are you running this build on zfs? There are apparently a bunch of
filesystem corruption problems which have surfaced due to recent openzfs
imports.




Yup, pure zfs install.
Discussion refers to block_cloning but it disabled on my pool

DATA  feature@block_cloning  disabled   local



--
Sincerely,
Dima (flu...@freebsd.org, https://t.me/FluffyBSD)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team


OpenPGP_signature
Description: OpenPGP digital signature

aarch64: lang/gcc1* build regression between Mar-28 and Apr-8

[Dima Panov]

Moin-moin!

Somethings changed in main branch between Mar, 28 and Apr, 8 which causes 
permanent build error for lang/gcc1[012] on aarch64 (exactly VMWare container 
on M1Pro mac)

during RTL pass: sched1
gimple-match.cc: In function 'bool gimple_nop_atomic_bit_test_and_p(tree, 
tree_node**, tree_node* (*)(tree))':
gimple-match.cc:39215:1: internal compiler error: Segmentation fault
39215 | }
  | ^
mmap: Invalid argument
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
See  for instructions.
gmake[4]: *** [Makefile:1145: gimple-match.o] Error 1
gmake[4]: *** Waiting for unfinished jobs
rm gcc.pod gfortran.pod


--
Sincerely,
Dima (flu...@freebsd.org, https://t.me/FluffyBSD)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bulld failure of editors/libreoffoce only on main (aka -current)

[Dima Panov]

Moin!

On 23.05.2022 19:03, Dimitry Andric wrote:

On 23 May 2022, at 17:53, Tomoaki AOKI  wrote:

After some discussion with Mark Millard on Bug 263976 and some tests,
I've changed the subject of it to "editors/libreoffice: Fails to build
if LLVM_DEFAULT=90 (default) and LTO=on (non-default)".

With LTO option enabled, port default devel/llvm* (now it's 90
according to Mk/bsd.default-versions.mk) is forcibly used, thus causing
this problem.


llvm90 is too old to support LTO as intended :(

My own build farm for libreoffice and company have LTO disabled at all, 
so any good suggestions how to deal with LTO with minimal issues will be 
appreciated.



Maybe it's time to bump the LLVM_DEFAULT version to 13 or 14 now?
Although this would probably require an ex-run first. Brooks, do you
think bumping to devel/llvm14 is too ambitious?


My recent -current jail is also have LLVM_DEFAULT=14 and not hit any 
serious issue yet:)



tcberner was initiated exp-run to make llvm13 as default some time ago

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263456



--
Sincerely,
Dima (flu...@freebsd.org,https://t.me/dima_panov)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team



OpenPGP_0xFB8BA09DD5398F29_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bulld failure of editors/libreoffoce only on main (aka -current)

[Dima Panov]

Moin!

As maintainer of libreoffice I have my 2¢ to say.

It builds fine on a recent -current with clang14,
https://build.dimapanov.com/poudriere//data/140amd64-dimaports/2022-05-21_19h50m37s/logs/libreoffice-7.3.3.2_1.log

However, all my own builds run without LTO enabled, it might matters

On 22.05.2022 02:29, Tomoaki AOKI wrote:

Hi.
(CC'ing dim@ as dim@ would be the best person if it's base llvm
problem.)

I've filed Bug 263976 [1] as Ports & Packages / Individual Port(s)
last week.

But I'm still confusing whether...
   *it is because of intentional change(s) on base llvm/clang
that editors/libreoffice team should chase,

   *or problem on base llvm/clang14 accidentally introduced.

There were no feedback at all until now.
Any ideas?

The failure mode is

   error: no viable conversion from 'StrictNumeric' to 'float'

The workaround without editing port Makefile is to set
   DEFAULT_VERSIONS+= llvm=13
for editors/libreoffice on /etc/make.conf with conditinal.

Please visit the mentioned PR for more detail.


[1]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263976

Regards.


--
Sincerely,
Dima (flu...@freebsd.org,https://t.me/dima_panov)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team



OpenPGP_0xFB8BA09DD5398F29_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: POLLHUP detected on devd socket

[Dima Panov]

Moin!

I saw a such issue on amd64, both 13.0-RELEASE and -CURRENT.
Both hosts have zfsd enabled, and after devd die by signal 15 all other daemons 
such as sshd, crond, syslogd (almost all runned daemons) stopeed by signal 15 
too. At least, as it shows by system logs.

Will try to play with zfsd disabled, as suggested.

--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)

> On Sunday, Jan 23, 2022 at 12:03 PM, tech-lists  (mailto:tech-li...@zyxst.net)> wrote:
> On Sun, Jan 23, 2022 at 04:10:40PM +1030, Daniel O'Connor wrote:
>
> > Is it reproducible? ie can you trigger it post boot?
> >
> > It is very strange that devd dying would kill anything else running -
> > I have stopped and started it a lot while testing devd scripts and
> > I haven't seen anything else break.
> >
> > One idea would be to hack up devd's rc.d script and run it under
> > ktrace and try and get some clues.
>
> I can try that, thanks for the suggestion.
>
> Right now I'm thinking it's tied to zfsd, since disabling that
> service I've not seen the issue.
> --
> J.


signature.asc
Description: PGP signature

Re: problem building virtualbox-ose-kmod

[Dima Panov]

Moin!

Stefan, please add check for __FreeBSD_version and fill PR or commit it 
directly with ports-secteam approval.

--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)

> On Tuesday, Jan 26, 2021 at 8:37 PM, Stefan Esser  (mailto:s...@freebsd.org)> wrote:
> Am 26.01.21 um 07:34 schrieb monochrome:
> > having this issue building virtualbox-ose-kmod, its been like this for a
> > while but I deinstalled and forgot, for quite a while now, maybe over a
> > month. now that I've moved from 13-current to stable/13 I thought I
> > would try to put it back, but it still wont build. I haven't seen anyone
> > else with this problem, did I miss a memo?
>
> I have sent a patch to vbox@on 2020-01-16, but only received an
> automatic reply that it had to be accepted by the moderator of the
> list (and never got any further reply or reaction on it).
>
> The signature of vm_map_protect() has changed, but the port has not
> been updated.
>
> Here is the patch in case the attachment gets stripped (but probably
> with messed-up white-space):
>
> Index: files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
> ===
> --- files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
> (revision 561738)
> +++ files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
> (working copy)
> @@ -421,7 +421,8 @@
> @@ -826,6 +885,7 @@ DECLHIDDEN(int) rtR0MemObjNativeProtect(PRTR0MEMOBJINT
> ProtectionFlags |= VM_PROT_EXECUTE;
>
> - int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
> ProtectionFlags, FALSE);
> +- int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
> ProtectionFlags, FALSE);
> ++ int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
> ProtectionFlags, 0, VM_MAP_PROTECT_SET_PROT);
> + IPRT_FREEBSD_RESTORE_EFL_AC();
> if (krc == KERN_SUCCESS)
> return VINF_SUCCESS;
>
> Seems that __FreeBSD_version has been bumped to 1300135 less than
> 2 hours before 0659df6faddfb27ba54a2cae2a12552cf4f823a0 and thus
> the patch could be made to depend on that __FreeBSD_version value,
> but I did not bother to add the condition since all my systems have
> been updated to newer versions.
>
> Regards, STefan
>
> > --- memobj-r0drv-freebsd.o ---
> > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80:
> > error: too few arguments to function call, expected 6, have 5
> > int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
> > ProtectionFlags, FALSE);
> > ~~ ^
> > /usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here
> > int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
> > ^
> > 1 error generated.
> > *** [memobj-r0drv-freebsd.o] Error code 1


signature.asc
Description: PGP signature

Re: build error at rpc code

[Dima Panov]

24.08.2012 19:12, Dimitry Andric пишет:

On 2012-08-24 05:55, Dima Panov wrote:

Does anybody get same error at buildworld with recent -current?

...

In file included from /usr/src/lib/libc/../../include/rpc/rpc.h:76:
/usr/src/lib/libc/../../include/rpc/rpcb_clnt.h:69:8: error: unknown
type name 'rpcblist'
extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);


You are most likely setting CPP as follows:

  CPP=clang -E

Don't do that, use the following instead:

  CPP=clang-cpp

If there is no clang-cpp symlink in /usr/bin yet, just make it manually
for now.  It will also be created by installworld.


Oh, indeed. Thanks for advice.
However, why such different results in preprocessor invocation style?

--
Dima Panov (flu...@freebsd.org)
(KDE, Office)@FreeBSD team

Facebook: http://www.facebook.com/fluffy.khv
IRC: fluffy@EFNet, fluffykhv@FreeNode
twitter: fluffy_khv | skype: dima.panov

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

build error at rpc code

[Dima Panov]

Hello!


Does anybody get same error at buildworld with recent -current?

clang  -Os -fno-strict-aliasing -pipe -Qunused-arguments -march=core2 
-I/usr/src/lib/libc/include -I
/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS 
-D__DBINTERFACE_PRIVATE -I/usr/src/
lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc 
-I/usr/src/lib/libc/resolv -D_ACL_P
RIVATE -DPOSIX_MISTAKE 
-I/usr/src/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION 
-I/usr
/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime 
-I/usr/src/lib/libc/locale -D
BROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP 
-DNS_CACHING -DSYMBOL_VERSIONING -st
d=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -Wno-uni
nitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-tautological-compare -Wno-unu
sed-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion 
-Wno-switch -Wno-switch-enu

m -c /usr/src/lib/libc/gen/getgrent.c -o getgrent.o
In file included from /usr/src/lib/libc/gen/getgrent.c:39:
In file included from /usr/src/lib/libc/../../include/rpc/rpc.h:76:
/usr/src/lib/libc/../../include/rpc/rpcb_clnt.h:69:8: error: unknown 
type name 'rpcblist'

extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
1 error generated.
*** [getgrent.o] Error code 1

Stop in /usr/src/lib/libc.
*** [lib/libc__L] Error code 1



10.0-115-CURRENT /usr/bin/clang #0 r238449M: Sat Jul 14 23:34:39 
VLAT 2012

CLANG_IS_CC


Full buildlog at http://fluffy.homeunix.net/~fluffy/files/screenlog.0

--
Dima Panov (flu...@freebsd.org)
(KDE, Office)@FreeBSD team

Facebook: http://www.facebook.com/fluffy.khv
IRC: fluffy@EFNet, fluffykhv@FreeNode
twitter: fluffy_khv | skype: dima.panov

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: please (re) test if_ath in -HEAD

[Dima Panov]

hello!

FreeBSD 9.0-900033-CURRENT #0 r219338M: Mon Mar  7 11:31:40 VLAT 2011
All fine with AR9285, WPA2 is used
stable 36/48/54Mbps with my AP

07.03.2011, 06:14, Adrian Chadd adrian.ch...@gmail.com:
 On 7 March 2011 03:21, Ian FREISLICH i...@clue.co.za; wrote:

  Adrian Chadd wrote:
  I'd like to establish at least a range of subversion revisions so we can
  start binary searching which one(s) caused instabilities.
  Is this all the source?

  Old:
  $FreeBSD: src/sys/dev/ath/if_ath.c,v 1.300 2011/02/21 19:22:45 adrian Exp $
  New:
  $FreeBSD: src/sys/dev/ath/if_ath.c,v 1.302 2011/03/02 17:19:54 adrian Exp $

 Ok, so between r219318 (today) and r218779 (2011-02-18).

 Would you please first test r218779 and verify that performance is (back to)
 fine?


-- 
Dima Panov (flu...@freebsd.org)
KDE@FreeBSD team

Facebook: http://www.facebook.com/?id=10181104157
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Request: AR9285 EEPROM dumps (was Re: More if_ath churn coming your way!)

[Dima Panov]

Hello!

23.01.2011, 09:47, Adrian Chadd adrian.ch...@gmail.com:
 Hi all,

 I've just committed a new tool in src/tools/tools/ath/ called ath_prom_dump .

 It dumps the contents of the atheros EEPROM into a text file for later 
 analysis.

 I don't have any AR9285's handy; if you have an AR9285, would you
 please send me a hexdump of the EEPROM along with the contents of
 pciconf and  dmesg | grep ath (so I can get the MAC/PHY version
 numbers?)

You meant ath_prom_read? 

[root@Beastie] ~# ath_prom_read -h
ath_prom_read: illegal option -- h
ath_prom_read [-i ifname] -d dumpfile
[root@Beastie] ~# ath_prom_read -d ar9285
ath_prom_read: ath0: Invalid argument
[root@Beastie] ~#

FreeBSD 9.0-900030-CURRENT #0 r217695M: Sat Jan 22 13:57:57 VLAT 2011

-- 
Dima Panov (flu...@freebsd.org)
KDE@FreeBSD team

Facebook: http://www.facebook.com/?id=10181104157
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: More if_ath churn coming your way!

[Dima Panov]

hello!

22.01.2011, 22:19, Adrian Chadd adrian.ch...@gmail.com:
 So it's all completely stable for you too right now?


Yes, almost 7 hours with new kernel and no errors. 
Stable as all previous revisions.

Wait a 802.11n support to utilize it with my home and office hotspots :) 

 adrian

 2011/1/22 Dima Panov flu...@fluffy.khv.ru;:

  Hello!

  22.01.2011, 13:56, Adrian Chadd adrian.ch...@gmail.com;:
  On 20 January 2011 13:51, Adrian Chadd adrian.ch...@gmail.com;; wrote:
   Hi everyone,

   I'm in the process of merging in the non-intrusive changes to the
   if_ath code into -HEAD.
  Ok, so I lied - the ANI changes were slightly intrusive. But all in
  all the code was just shuffled around a bit.

  Someone's reported that the AR9285 was once stable but now isn't. I'd
  really appreciate it if others who are using AR9280/AR9285 chipsets
  would test this out and get back to me.
  FreeBSD 9.0-900030-CURRENT #0 r217695M: Sat Jan 22 13:57:57 VLAT 2011
  ath0: Atheros 9285 mem 0xf000-0xf000 irq 19 at device 0.0 on pci9
  ath0: AR9285 mac 192.2 RF5133 phy 14.0

  Signal strength is fine, no packets loss.
  ath 9285 was stable for me last months.
  Acer Ferrari One 200 laptop with half-sized atheros wifi card.
  I'd like to make sure I fix all regressions before I start bringing
  over more code from ath9k in preparation for enabling the basic
  802.11n support for testing.

-- 
Dima Panov (flu...@freebsd.org)
KDE@FreeBSD team

Facebook: http://www.facebook.com/?id=10181104157
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: More if_ath churn coming your way!

[Dima Panov]

Hello!

22.01.2011, 13:56, Adrian Chadd adrian.ch...@gmail.com:
 On 20 January 2011 13:51, Adrian Chadd adrian.ch...@gmail.com; wrote:

  Hi everyone,

  I'm in the process of merging in the non-intrusive changes to the
  if_ath code into -HEAD.

 Ok, so I lied - the ANI changes were slightly intrusive. But all in
 all the code was just shuffled around a bit.

 Someone's reported that the AR9285 was once stable but now isn't. I'd
 really appreciate it if others who are using AR9280/AR9285 chipsets
 would test this out and get back to me.

FreeBSD 9.0-900030-CURRENT #0 r217695M: Sat Jan 22 13:57:57 VLAT 2011
ath0: Atheros 9285 mem 0xf000-0xf000 irq 19 at device 0.0 on pci9
ath0: AR9285 mac 192.2 RF5133 phy 14.0

Signal strength is fine, no packets loss.
ath 9285 was stable for me last months.
Acer Ferrari One 200 laptop with half-sized atheros wifi card.

 I'd like to make sure I fix all regressions before I start bringing
 over more code from ath9k in preparation for enabling the basic
 802.11n support for testing.

-- 
Dima Panov (flu...@freebsd.org)
KDE@FreeBSD team

Facebook: http://www.facebook.com/?id=10181104157
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Having a problem with security/libassuan-1 when compiling gnupg.

[Dima Panov]

On Friday 18 June 2010 18:46:49 Jan Henrik Sylvester wrote:
 On 01/-10/-28163 20:59, Doug Barton wrote:
  3. kdepim4 My understanding is that the version currently under
  development has support for libassuan 2.0.0, and will be released in
  August. The kde@ folks have indicated that if there is a need to update
  it sooner they can most likely do that based on patches that are
  currently available.
 
 [...]
 
I am unsure what happens when some ports want v1 and others want v2.
This may not be an issue if the updated ports can be deal with either
API, but I have no idea whether that is the case.
 
  The current situation is that having both versions installed is
  incompatible. My preference would be that the maintainers of the
  affected ports upgrade to depend on assuan 2.0.0 and then we can remove
  libassuan-1. If it becomes necessary to support having both versions
  installed then Plan C at this point would be to modify libassuan-1 to
  support this.
 
 I thought Plan C was a requirement -- and from your first mails, I 
 thought this was planned.
 
 deskutils/kdepim4 LIB_DEPENDS on libassuan-1 and gpgme. security/gpgme 
 RUN_DEPENDS on gpg2. security/gnupg LIB_DEPENDS on assuan.0.
 
 Hence, building deskutils/kdepim4, I need security/libassuan-1 and 
 security/libassuan installed that list each other in CONFLICTS.
 
 I have not actually tried to build deskutils/kdepim4 after the gnupg 
 update, but is it not currently broken?
 
 If that is correct, either kde@ has to patch deskutils/kdepim4 (which 
 they do not plan from the discussion at that list) or you have to patch 
 security/libassuan-1 (which you do not plan from your statement above). 
 Will we have a deskutils/kdepim4 with 8.1-RELEASE?
 

kde4 not hardy require libassuan-1. if it absend, kleopatra will use own 
internal
functions ans loss a minimum functionality
kde4.5 will have full support for libassuan2


-- 
Dima Red Fox Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018
Khabarovsk, Russia  | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29
k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995
Twitter: fluffy_khv | Skype: dima.panov | Jabber.[org|ru]/GTalk/QIP: fluffy.khv
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT]: ClangBSD is selfhosting, we need testers now - STATUS UPDATE

[Dima Panov]

On Thursday 06 May 2010 04:13:57 Roman Divacky wrote:
 fwiw, it looks like it may make sense to have 2nd round of runtime testing
 :)
 
 these things were fixed in clangbsd that were reported as problems:
 
 1) static binaries (eg. make) crash
 
 2) kernel sound module miscompilation
 
 3) bootloader problem which prevented clangbsd from booting
 
 4) fix building when CC/CXX were set to cc/c++
 
 5) kernel printf modifiers semantic checking was implemented
 
 6) i386 default cpu setting fix
 
 I know about these problems that are still not fixed
 
 1) i386 is being miscompiled so clang built clang crashes
 
   this is being worked on, we have a test case and I believe
   Dmitry Andric (big kudos to him!) is about to submit a bug
   report to llvm
 
 2) mergemaster problems - I have a fix but have not commited it yet
 
 3) ruby crashes
 
 so, if you have one of the problems I listed as being fixed I'd like you
 to update clangbsd sources and rebuild the world to make sure that the
 problem you had was indeed fixed. If it wasn't, please report back to me.
 New testers are welcome too of course :)
 
 I am all ears about new problems as well. Please restrict your testing
 to amd64 as i386 is broken. You are free to test on ARM too as I am
 quite sure it works reasonably well there but noone tested it.
 
 thank you!
 
 Roman Divacky
 

Building in chroot (based on previous svn tree from CFT was firstly announced)

=== usr.bin/clang/lib/libllvmpowerpccodegen (all)
clang++ -O2 -pipe -
I/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/include
 -
I/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/tools/clang/include
 
-
I/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/lib/Target/PowerPC
 
-I. -I/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../include 
-DLLVM_ON_UNIX -
DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-rtti -
DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -
I/usr/obj/usr/src/tmp/legacy/usr/include -c 
/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/lib/Target/PowerPC/PPCBranchSelector.cpp
clang++ -O2 -pipe -
I/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/include
 -
I/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/tools/clang/include
 
-
I/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/lib/Target/PowerPC
 
-I. -I/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../include 
-DLLVM_ON_UNIX -
DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-rtti -
DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -
I/usr/obj/usr/src/tmp/legacy/usr/include -c 
/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/lib/Target/PowerPC/PPCCodeEmitter.cpp
In file included from 
/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../../../contrib/llvm/lib/Target/PowerPC/PPCCodeEmitter.cpp:252:
In file included from 
/usr/src/usr.bin/clang/lib/libllvmpowerpccodegen/../../include/PPCGenCodeEmitter.inc:2:
./PPCGenCodeEmitter.inc.h:1560:5: error: use of undeclared identifier 
'llvm_report_error'
llvm_report_error(Msg.str());
^
1 diagnostic generated. 


*** Error code 1

Stop in /usr/src/usr.bin/clang/lib/libllvmpowerpccodegen.
*** Error code 1


$[/a/FreeBSD/src-clang]
Updated to revision 207691.

-- 
Dima Red Fox Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018
Khabarovsk, Russia  | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29
k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995
Twitter.com:fluffy_khv | Skype: dima.panov | Jabber.org/GTalk/QIP.ru:fluffy.khv
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)

[Dima Panov]

On Thursday 29 April 2010 02:40:24 Dima Panov wrote:
 On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote:
  According to Dima Panov:
   while building lang/ruby18:
  Which options to you use?
  
  _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1
  WITHOUT_ONIGURUMA=true
  WITH_RDOC=true
  WITHOUT_DEBUG=true
  
  I notice your ruby is compiling w/o any -On, try with -O at least?
 
 same here. also on 1.8.7.249 snapshot.
 
 ar rcu libruby18-static.a array.o  bignum.o  class.o  compar.o  dir.o 
 dln.o  enum.o enumerator.o  error.o  eval.o  file.o  gc.o  hash.o  inits.o
  io.o  marshal.o  math.o numeric.o  object.o  pack.o  parse.o  process.o 
 prec.o  random.o  range.o  re.o  regex.o ruby.o  signal.o  sprintf.o  st.o
  string.o  struct.o  time.o  util.o  variable.o version.o   dmyext.o
 clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89  -fPIC   
 -DRUBY_EXPORT -I. -I. -I/usr/include-c main.c
 clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89  -fPIC   
 -DRUBY_EXPORT -L. -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic 
 -pthread main.o  libruby18-static.a - lrt -lcrypt -lm -L/usr/lib 
 -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
 ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment ruby
 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9]
 
 *** Signal 6
 
 Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249.
 *** Error code 1
 
 
 _OPTIONS_READ=ruby-1.8.7.249,1
 WITHOUT_ONIGURUMA=true
 WITH_RDOC=true
 WITHOUT_DEBUG=true
 
   clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC-DRUBY_EXPORT -I.
   -I. -I/usr/include -c main.c
   clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC-DRUBY_EXPORT -L.
   - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o
   libruby18-static.a -lrt -lcrypt -lm -L/usr/lib
   -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
   ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError)
   
   from ./mkconfig.rb:11:in `require'
   from ./mkconfig.rb:11
   
   *** Error code 1
  
  Interesting, using a fairly recent clang snapshot from trunk, I get a
  sig11
  
  :(
 
 Ruby is bad?

clangbsd errors in my blog:

http://dimapanov.wordpress.com/2010/04/29/clangbsd/

at this moment unbuildable some critical ports:

devel/binutils
devel/icu[4]
devel/pcre
lang/ruby1[89]

-- 
Dima Red Fox Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018
Khabarovsk, Russia  | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29
k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995
Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT]: ClangBSD is selfhosting, we need testers now

[Dima Panov]

On Saturday 17 April 2010 03:08:18 Roman Divacky wrote:
 Hi,
 
 ClangBSD is a branch of FreeBSD that aims at integrating clang
 (clang.llvm.org) into FreeBSD, replacing GCC as a system compiler.
 
 Recently, we've achieved the state when clang can compile all of FreeBSD
 world on i386/amd64 platforms (including all the C++ apps we have and
 itself) and a bootable kernel. Thus we feel that the time has come to ask
 the FreeBSD community for wider testing on i386/amd64 (you sure can help
 with other platforms too :)).
 

Great works, thanks!

But I have a problem with recently-compiled clangbsd (in chroot)

while building lang/ruby18:

clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC-DRUBY_EXPORT -I. -I. 
-I/usr/include
-c main.c
clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC-DRUBY_EXPORT -L.  -
rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o  
libruby18-static.a -lrt 
-lcrypt -lm -L/usr/lib  -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError)
from ./mkconfig.rb:11:in `require'
from ./mkconfig.rb:11
*** Error code 1


host system:

[r...@fluffy] ~# uname -a
FreeBSD Fluffy.Khv.RU 9.0-900010-CURRENT FreeBSD 9.0-900010-CURRENT #0 
r207097M: Fri Apr 
23 19:20:05 VLAST 2010 r...@fluffy.khv.ru:/usr/obj/usr/src/sys/Spot  amd64


clangbsd: /base/!svn/ver/206467/projects/clangbsd/sys


-- 
Dima Red Fox Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018
Khabarovsk, Russia  | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29
k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995
Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)

[Dima Panov]

On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote:
 According to Dima Panov:
  while building lang/ruby18:
 Which options to you use?
 
 _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1
 WITHOUT_ONIGURUMA=true
 WITH_RDOC=true
 WITHOUT_DEBUG=true
 
 I notice your ruby is compiling w/o any -On, try with -O at least?

same here. also on 1.8.7.249 snapshot.

ar rcu libruby18-static.a array.o  bignum.o  class.o  compar.o  dir.o  dln.o  
enum.o  
enumerator.o  error.o  eval.o  file.o  gc.o  hash.o  inits.o  io.o  marshal.o  
math.o  
numeric.o  object.o  pack.o  parse.o  process.o  prec.o  random.o  range.o  
re.o  regex.o  
ruby.o  signal.o  sprintf.o  st.o  string.o  struct.o  time.o  util.o  
variable.o  
version.o   dmyext.o
clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89  -fPIC
-DRUBY_EXPORT -I. 
-I. -I/usr/include-c main.c
clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89  -fPIC
-DRUBY_EXPORT -L.  
-rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o  
libruby18-static.a -
lrt -lcrypt -lm -L/usr/lib  -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment
ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9]

*** Signal 6

Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249.
*** Error code 1


_OPTIONS_READ=ruby-1.8.7.249,1
WITHOUT_ONIGURUMA=true
WITH_RDOC=true
WITHOUT_DEBUG=true


 
  clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC-DRUBY_EXPORT -I.
  -I. -I/usr/include -c main.c
  clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC-DRUBY_EXPORT -L. 
  - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o 
  libruby18-static.a -lrt -lcrypt -lm -L/usr/lib 
  -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
  ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError)
  
  from ./mkconfig.rb:11:in `require'
  from ./mkconfig.rb:11
  
  *** Error code 1
 
 Interesting, using a fairly recent clang snapshot from trunk, I get a sig11
 :(


Ruby is bad?

-- 
Dima Red Fox Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018
Khabarovsk, Russia  | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29
k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995
Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org