(I didn't figure out yet how to rebuild the control file, to get these
installed into a .deb, and I have no clue how to test it either.)
I believe that "fakeroot debian/rules control" before build is sufficient.
No 'undefined reference' errors in the build log. Both regular and -m32
multilib
On 12/09/14 21:44, Petr Salinger wrote:
It seems that simple drop of kfreebsd-gnu from libphobos_no_systems does
not suffice.
In the build logs are messages like
/build/manual/gcc-4.9-4.9.1/build/x86_64-kfreebsd-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/rt/dmain2.d:419
Am 12.09.2014 um 15:13 schrieb Thibaut Paumard:
While it's your prerogative to decrease the severity, please note that
this bug means that all the packages that build-depend on gdc (22
packages in jessie) are currently in an FTBFS-state on kfreebsd.
sure, and they still will ftbfs without libph
Package: gcj-4.8-jre-headless
Version: 4.8.1-6
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
there is a significant regression in libjava testsuite.
Debian 4.8.1-5
http://lists.debian.org/debian-gcc/2013/06/msg00221.html
http://lists.debian.org/debian-
Package: gcc-4.8
Version: 4.8.1-2
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Please,
could you add into patches the attached one.
It provides handling for unwind inside signal trampoline for kfreebsd.
Please also add/raise build-depends
kfreebsd-kernel-headers (>= 0.84)
please find out why, -v shows you the directories searched. amd64 seems to be
correct about the search path.
g++ -m64:
ignoring nonexistent directory "/usr/include/i386-kfreebsd-gnu/c++/4.7/."
ignoring nonexistent directory "/usr/local/include/x86_64-kfreebsd-gnu"
ignoring nonexistent directory
Package: gcc-4.7
Version: 4.7.3-3
Severity: important
The g++ compiler in 32-bit pass on kfreebsd-amd64 cannot
find it's include files. They exist in
/usr/include/x86_64-kfreebsd-gnu/c++/4.7/32/bits/c++config.h
It breaks at least testsuite of eglibc (leads into FTBFS).
The wheezy version is fine
Package: gcc-4.7
Version: 4.7.1-2
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
current gcc produces (at least on kfreebsd-amd64) misleading warning
during compilation of xserver-xorg-input-mouse.
It together with -Werror leads to #665390.
Attached please find reduced testcase, it
reassign 576335 cvc3
found 576335 2.2-13
tag 576335 = patch
thanks
Hi,
it looks like the java on kfreebsd-amd64 problem
is solved with gcj-4.6 (4.6.1-6) upload.
Please change Architecture of libcvc3-2-jni to any
and drop 50_exclude_java_tests_on_kfreebsd_amd64.patch.
Many thanks
Petr
I am unable to get the failure neither on my PC,
neither on asdfasdf.d.n
Would be possible to disable parallel
build of gcc-4.6/gcj-4.6/gnat-4.6 on kfreebsd(-amd64) ?
That way we could at least compare failing and working build log.
And may be do DD uploads from i386 to test also linux-amd64 bu
user debian-...@lists.debian.org
usertag 642928 + kfreebsd
usertag 642162 + kfreebsd
--
Could be this related to CPU ?
My is "Intel(R) Core(TM)2 Duo CPU E6750"
asdfasdf's "AMD Sempron(tm) Processor 3000+"
After changing configure.ac and propagating it into
configure, the testsuite of 3.0.1
I tried the same on my PC,
testsuite of all available (stable, sid, experimental) libffi passes.
On asdfasdf.d.n they fails.
Could be this related to CPU ?
My is "Intel(R) Core(TM)2 Duo CPU E6750"
asdfasdf's "AMD Sempron(tm) Processor 3000+"
Petr
--
To UNSUBSCRIBE, email to debian-gcc-r
Hi.
suggesting that the functions I'm looking for are missing entirely.
Is that so?
Yes.
They are optional part, see
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_setprioceiling.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_setp
Apparently gcc-4.5 is not good enough as a bootstrap compiler for gcc-4.6.
Please could somebody check/confirm that using gcc-4.4 as the bootstrap
compiler works around the build failure?
As gcc-4.6 is already available on both kfreebsd-*,
wouldn't be better to use gcc-4.6 as a bootstrap compile
Apparently gcc-4.5 is not good enough as a bootstrap compiler for gcc-4.6.
Please could somebody check/confirm that using gcc-4.4 as the bootstrap
compiler works around the build failure?
As gcc-4.6 is already available on both kfreebsd-*,
wouldn't be better to use gcc-4.6 as a bootstrap compil
As far as I can see, gcj suffers a bus error trying to compile even
the trivial "Hello World" program (see #594830) since last summer.
This problem is exhibited in GCC 4.4 and GCC 4.6 releases.
Only on kfreebsd-amd64 and only on some machines.
gcj fails under fash.d.o, but not fano.d.o,
it work
notfound 619792 4.6.0~rc1-3
--
The failure is on kfreebsd-amd64 with 4.6.0-1,
but the 4.6.0~rc1-2, 4.6.0~rc1-3 have been fine.
All tried on fash. The difference is used gcc-4.5.
Failed builds used gcc-4.5_4.5.2-7,
the previous used gcc-4.5_4.5.2-6.
Petr
--
To UNSUBSCRIBE, email to debian-g
2) liblto_plugin.* is missing in generated gcc-4.6 binary package
The liblto_plugin.* have to be installed on kfreebsd-* somehow.
or -fno-use-linker-plugin have to be default.
I saw changes in SVN, the r5135 should fix it,
please from r5130 revert this:
gold_cpus = i386 i486 i586 i686 x86_64
2) liblto_plugin.* is missing in generated gcc-4.6 binary package
Please add "kfreebsd-i386 kfreebsd-amd64" into
"gold_archs" in debian/rules.defs or test against
DEB_TARGET_ARCH_CPU instead of DEB_TARGET_ARCH for
"with_gold".
Oh, ld.gold is not available on kfreebsd-*.
But without liblto_plugi
Package: gcc-4.6
Version: 4.6.0~rc1-1
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
1) problem during testing of libgomp in 32 bit mode
Please "disable" the problematic test.
Tested on kfreebsd-amd64.
--- a/src/libgomp/testsuite/libgomp.c/lock-2.c
+++ b/src/libgomp/testsuite/libgomp
gcc-4.6 fails in experimental after build & check while generating/printing
the
test summary. I can't see any kfreebsd specific. Could somebody from the
kfreebsd porters please investigate the build failure?
There is a problem during testing of libgomp in 32 bit mode.
I.e. on kfreebsd-amd64 the
gcc-4.6 fails in experimental after build & check while
generating/printing the
test summary. I can't see any kfreebsd specific. Could somebody from the
kfreebsd porters please investigate the build failure?
There is a problem during testing of libgomp in 32 bit mode.
I.e. on kfreebsd-amd64 the
I'll make gcc-4.5 the default for (at least some) architectures within the next
two weeks before more transitions start. GCC-4.5 is already used as the default
compiler for almost any other distribution, so there shouldn't be many surprises
on at least the common architectures. About 50% of the
applied, however this reverts somehow the change in the kfreebsd-gnu patch.
In the gcc-4.5 this part in kfreebsd-gnu patch have been:
- x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h" ;;
+ x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h
i386/kfreebsd-gnu.h" ;
The failure on kfreebsd-i386 is a different one:
make[4]: *** [check-recursive] Error 1
make[4]: Target `check' not remade because of errors.
make[4]: Leaving directory
`/build/buildd-gcc-4.6_4.6-20110227-1-kfreebsd-i386-oLsZOn/gcc-4.6-4.6-20110227/build/i486-kfreebsd-gnu/libstdc++-v3'
make[3]
The failure on kfreebsd-amd64 seems be due to incomplete config.gcc
after recent cleanup.
The config.gcc for kfreebsd-i386 does not have this problem,
but the build log is not shown on buildd.d.o.
Petr
--- src/gcc/config.gcc
+++ src/gcc/config.gcc
@@ -1293,7 +1293,7 @@
case ${target} i
I believe, that even plain i486 have to be supported,
also changelog claims that default should still be i486.
yes, I think I did change that to avoid libgomp failures, which requires
i586, and not just i486. Not sure what to do about that for squeeze.
Just document it in release notes/errat
Package: gcc-4.4
Version: 4.4.5-8
Hi,
the current gcc-4.4 uses (tested on i386/4.4.5-6 and kfreebsd-i386/4.4.5-8)
as a default arch i586.
COLLECT_GCC_OPTIONS='-v' '-dD' '-E' '-mtune=generic' '-march=i586'
echo "" | gcc-4.4 -dD -x c -E - | grep 86
#define __DBL_MAX__ 1.7976931348623157e+308
#de
This package builds with a non standard compiler version; please check
if this package can be built with the default version of gcc/g++.
Please keep this report open until the package uses the default
compiler version for the package build.
The severity of this report is likely to be raised befo
reassign 571532 gcj-4.4
retitle 571532 gcj-4.4: FileChannel.transferTo() does not conform to java
specification (gij: Bus error when executing ant)
tags 571532 - moreinfo
tags 571532 - help
thanks
I believe that all needed info have been already provided
in Message #85 and Message #90.
Petr
user debian-...@lists.debian.org
usertag 576335 + kfreebsd
--
Hi,
I am unable to reproduce these failures locally.
Would you mind to run these tests even on kfreebsd-amd64,
build libcvc3-2-jni on kfreebsd-amd64,
but just ignore errors from Java tests on kfreebsd-amd64.
Petr
--
To UNSUBS
Hi,
I am unable to reproduce neither voms neither brltty FBTBF
with gcj 4.4.3-6 and up-to-date sid.
Petr
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.lnx.4.6
Moreover, it looks like transferTo(0, 4096, ...) would write
4096 bytes to destination file from file with size 1701.
It can be shown by this snippet:
-
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.channels.FileChann
Hi.
The problem is triggered by this line, for any small file,
which seems to me allowed by java specification
srcChannel.transferTo(0, FileUtils.BUF_SIZE,destChannel);
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/FileChannel.html:
An attempt is made to read up to count bytes fr
notfixed 571542 1.8.0-3
found 571542 1.8.0-3
tags 571542 +patch
--
Hello.
The problem is that FileUtils.BUF_SIZE (8192)
is currently bigger than page size (4096) on
some architectures, the copied file is mmaped-in
and the code tries to access after end of a file.
The patch bellow will provide f
Now it looks like wider problem - #571532, #571542, #571397.
Does ant actually try to mmap stdin? That's a bug in ant.
POSIX says you may only mmap a file, shared memory object,
or typed memory object. The stdin file descriptor is neither
of those things therefore you can't mmap stdin.
No, no
On Thu, Feb 25, 2010 at 9:23 AM, Petr Salinger wrote:
The file, which have to be copied, have size 1701,
but two pages (2*4096) are mmaped. It is allowed on both
Linux and FreeBSD.
When the 2nd page of that file would be accessed, it would
generate SIGBUS.
The question is of course whether it
I'm new to Debian GNU/kFreeBSD and I came to it in order to solve a
FTBFS bug (561121) in package polyorb. Bug 561121 is a consequence of
bug 564232 (in gnat-4.4). I have found a fix for 564232 (tested up to
packaging) and there is two solutions for me now :
- 1/ don't touch to gnat-4.4 and appl
tags 512277 + patch
thanks
Hi,
I tested the proposed patch, it suffices to build asis and
adabrowse packages.
Please could you include this tiny extension of libgnatprj/configure.ac:
+ | *86-*-kfreebsd*-gnu \
+ | *x86_64-*-kfreebsd*-gnu )
Many thanks in advance
Petr
--
To UNSUBSCRIBE,
Package: gnat-4.3
Severity: important
Version: 4.3.2-1.1
User: glibc-bsd-de...@lists.alioth.debian.org
Usertags: kfreebsd
The build logs for kfreebsd-i386 of packages like adabrowse and asis says
"libraries are not supported on this platform".
I suspect, it is due to missing case in libgnatprj/
Package: gcc-defaults
Severity: important
Version: 1.75
Tags: patch
User: [EMAIL PROTECTED]
Usertags: kfreebsd
Hi,
the current version does not list kfreebsd-i386 and kfreebsd-amd64
as gcj architectures.
Please add them into gcj_archs and into gcj_native_archs.
To be honest, I do not understa
The same error also occurs in etch environment,
"cross" compile on i386:
gcc -m64 -O0 -fschedule-insns -c t.c
***
struct timespec
{
long tv_sec;
long tv_nsec;
};
int f(char ** a)
{
int ga_testing = 0;
if (!strcmp(a[1], "-ga"))
{
ga_t
clone 429657 -1
reassign -1 abuse-sdl
retitle -1 uses abs() instead of labs()
quit
abuse-sdl-0.7.0 has a gun aiming problem due to a mis-optimisation.
attached is a canned example.
The "dx" and "dy" are defined as longs, so you have to use rather
labs() (and #include to get the prototype).
Th
Hi.
and by building gcjwebplugin on GNU/kFreeBSD
(I don't know why it was disabled).
It have been disabled in days without xulrunner,
but now is xulrunner available also on GNU/kFreeBSD.
Please enable gcjwebplugin and change in debian/rules.conf
" ifeq ($(distribution),Debian)
JAVA_BUILD_
see http://bugs.debian.org/391268
For kfreebsd, it seems ok:
$ g++ -dumpspecs | grep "*cpp:" -A 1
*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
Petr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I will try to rebuild with attached patch, but it takes some time ...
Rebuild finished, it looks OK.
Please, could you apply gcj41c.diff (it contains also initial gcc41.diff)
and regenerate debian/control for next upload.
Many thanks.
Petr
--
To UNSUBSCRIBE, email to [EMAI
Package: gcc-4.1
Severity: important
Version: 4.1.1-13
Tags: patch
Hello,
the current version fails to build on GNU/kFreeBSD, due to
collision between libjava-backport.dpatch and kbsd-gnu-java.dpatch.
It needs either drop lines 3929-3937 from libjava-backport.dpatch
or apply attached patch to k
This is an automatic notification regarding your Bug report
#370320: gcc-4.1: FTBFS on GNU/kFreeBSD (CRLF in dpatch),
which was filed against the gcc-4.1 package.
Thanks for fixing gcc-4.1 on kFreeBSD.
Please, could you also upload this fixed version
as gcj-4.1 4.1.1-2 to fix gcj-4.1 on kFreeBSD
Package: gcc-4.1
Severity: important
Version: 4.1.1-1
Tags: patch
Hello,
thanks for enabling java on kFreeBSD.
Unfortunately, the kbsd-gnu-java.dpatch somehow got DOS (CRLF) end of lines.
Please, could you filter it through "fromdos" or "tr -d \\r"
and preferably also verify result via "od -ax"
severity 368477 normal
thanks
It is not definitely grave,
gcc can generate kernels, without libc6-dev,
so it is usable.
IMHO, this bug should be simply closed.
Petr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: gcc-defaults
Version: 1.35
Hi,
gcc-defaults 1.35 made gij-4.1/gcj-4.1 the default gij/gcj.
I would expect that it should build-depends on gcj-4.1-base
instead of gcj-4.0-base. Am I missing something ?
Petr
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubsc
10
# of untested testcases 20
#! /bin/sh -e
# Description: java support for GNU/k*BSD
# Author: Robert Millan, Petr Salinger
dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then
pdir="-d $3"
dir="$3/"
elif [ $# -ne 1 ]; then
echo >&2
It seems the problem here is "signed types are undefined on overflow".
abs (2083755264 + abs (abs (79364096) - 256))
Let express in hex on 32bit platform:
abs (0x7c339500 + abs (abs (0x4bb) - 0x100))
abs (0x7c339500 + 0x4baff00)
abs (undefined)
Does help to change definition of sum_abs fro
It seems the problem here is "signed types are undefined on overflow".
abs (2083755264 + abs (abs (79364096) - 256))
Let express in hex on 32bit platform:
abs (0x7c339500 + abs (abs (0x4bb) - 0x100))
abs (0x7c339500 + 0x4baff00)
abs (undefined)
Does help to change definition of sum_abs from
Please, could you also test glibc test package at
http://sci.felk.cvut.cz/~salinger/glibc/
changes are:
- add "libc_MIN_KERNEL_SUPPORTED=2.4.1" into debian/sysdeps/i386.mk
- copy linuxthreads/sysdeps/i386/i686/pt-machine.h into
linuxthreads/sysdeps/i386/i486/pt-machine.h
Petr
--
To UNSUB
> > Current glibc does not support TLS under 2.4 kernels (see #226716),
> > so this is probalby glibc bug (some people call it feature).
> glibc does support TLS on all kernels (even non-linux ones), if there is
> the corresponding kernel support.
Unfortunately not absolutely,
nevertheless i38
> > > Current glibc does not support TLS under 2.4 kernels (see #226716),
> > > so this is probalby glibc bug (some people call it feature).
> > - provide TLS support for 2.4 kernels and an upgrade path?
> 2.4 kernels does not have the necessary stuff to support TLS,
> so that's not possible
> > Only experimental gcc-4.1 4.1-0exp6 have to re-enable
> > cpu-default-i486.dpatch
>
> yes, pending for the next upload.
>
> it's currently not possible to configure using --with-arch=i486 and
> having the compiler be built as biarch. see the cpu-default-i486 patch
> in the source package.
Ye
Hi,
the current set of gcc in sid/i386 is OK (-march=i486 -mtune=i686).
gcc-3.3 3.3.6-12
gcc-3.4 3.4.5-2
gcc-4.0 4.0.2-7
Only experimental gcc-4.1 4.1-0exp6 have to re-enable
cpu-default-i486.dpatch
On the other hand, the (now tested) results
for gcc -m32 on amd64 are a little bit different:
Package: gcc-4.0
Hi.
Today defaults on ix86 are a little bit different:
gcc-3.3 -march=i486 -mtune=i686
gcc-3.4 -march=i486 -mtune=i486
gcc-4.0 -march=i386 -mtune=i686
Please, could you synchronize it.
Thanks
Petr
--
To UNSUBSCRIBE, email to [EMAIL PROTE
Hi,
in floating point code is better to avoid testing with equality.
In your example, you should change
if (fa == 0.0)
if (fb == 0.0)
into:
if (fabs(fa) < DBL_EPSILON)
if (fabs(fb) < DBL_EPSILON)
After that, it works with gcc -O2.
Regards
Petr
--
To UNSUBSCRIBE, email t
I think, there are 3 debian version of libc for ix86:
linuxthreadsMIN_KERNEL_SUPPORTED := 2.2.0 /lib
nptlMIN_KERNEL_SUPPORTED := ? /lib/tls
nptl+i686 MIN_KERNEL_SUPPORTED := 2.6.0 /lib/tls/i686/cmov/
nptl requires futex and {g,s}et_thread_area syscalls,
see also
reopen 305690
thanks
Hi,
package FTBS in sid, probably due to small typo.
Build-Depends contains
gnat-4.0 [...], gnat-3.3 [...] | gnat-3.4 [...]
instead of
gnat-4.0 [...] | gnat-3.3 [...] | gnat-3.4 [...]
Version: 4.0.0-2
apt-get build-dep gcc-4.0
Reading Package Lists... Done
Building De
63 matches
Mail list logo
