On Thu, 17 Sep 2020 at 11:47, matthew green wrote:
> > In file included from
> > usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
> > /libstdc++-v3/src/c++17/fs_dir.cc:29:10: fatal error:
> > bits/largefile-config.h: No such file or directory
> >29 | #include
> >
> > > In file included from
> > > usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
> > > /libstdc++-v3/src/c++17/fs_dir.cc:29:10: fatal error:
> > > bits/largefile-config.h: No such file or directory
> > >29 | #include
> > > |
> In file included from
> usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
> /libstdc++-v3/src/c++17/fs_dir.cc:29:10: fatal error:
> bits/largefile-config.h: No such file or directory
>29 | #include
> | ^
my fault, but this
I just pulled down sources at about 10:00 am BST. Here is the follow error:
# create libstdc++-v3/cow-fs_dir.d
...
In file included from
usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/c++17/cow-fs_dir.cc:26:
/libstdc++-v3/src/c++17/fs_dir.cc:29:10: fatal error:
bits/largefile-config.h: No
On Wed, 15 Jul 2020 at 18:32, Arthur Barlow wrote:
>
> This was updated from cvs about 10:00 am BST. The failure seems to happen
> when trying to link libgssapi with compat/amd64/i386 libraries. The error
> message(s) below:
I had a successful build at about 15:00.
>
> dependall ===>
>
This was updated from cvs about 10:00 am BST. The failure seems to happen
when trying to link libgssapi with compat/amd64/i386 libraries. The error
message(s) below:
dependall ===>
compat/amd64/i386/../../../lib/../crypto/external/bsd/heimdal/lib/libheimntlm
dependall ===>
Done, build completed.
On Wed, 20 May 2020 at 09:39, SAITOH Masanobu wrote:
>
> On 2020/05/20 17:33, Chavdar Ivanov wrote:
> > Hi,
> >
> > EVen after 'make cleandir' and removing the obj directory, I get three
> > times in a row:
> >
> > # compile GENERIC/if_media_80.o
> >
On 2020/05/20 17:33, Chavdar Ivanov wrote:
Hi,
EVen after 'make cleandir' and removing the obj directory, I get three
times in a row:
# compile GENERIC/if_media_80.o
/home/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float
Hi,
EVen after 'make cleandir' and removing the obj directory, I get three
times in a row:
# compile GENERIC/if_media_80.o
/home/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -mno-avx -msoft-float
-mindirect-branch=thunk -mindirect-branch-registe
Hi!
after upgrading all to 9.9.52... and finding it again acceptably stable
(only wifi issues.. but that about later) I am doing a full pkgsrc
rolling update
gobject-introspection fails:
[104/163] Generating gir-glib with a custom command
FAILED: gir/GLib-2.0.gir
/usr/pkg/bin/python3.7
In article ,
Riccardo Mottola wrote:
>Hi!
>
>while building (sources of this night) on amd64 userland, I get this error:
You need to clean the gcc tree (both tools/gcc and external/gpl3/gcc)
christos
Hi!
while building (sources of this night) on amd64 userland, I get this error:
/usr/src/obj/tooldir.NetBSD-9.99.50-amd64/bin/x86_64--netbsd-c++ -O2
-march=core2 -Wall -Wpointer-arith -Wno-sign-compare
-Wa,--fatal-warnings -Werror -fPIE -Wno-narrowing -Wno-unused
-march=core2 -std=gnu++98
Hi!
Martin Husemann wrote:
> On Wed, Mar 11, 2020 at 09:32:38AM +0100, Riccardo Mottola wrote:
>> ${EXTRA_OBJ} vers.o swapnetbsd.o
>> /usr/src/obj/tooldir.NetBSD-9.99.34-amd64/bin/x86_64--netbsd-ld:
>> ioconf.o:(.rodata+0x120): undefined reference to `stripattach'
>>
>>
>> any clues?
> strip(4)
On Wed, Mar 11, 2020 at 09:32:38AM +0100, Riccardo Mottola wrote:
> ${EXTRA_OBJ} vers.o swapnetbsd.o
> /usr/src/obj/tooldir.NetBSD-9.99.34-amd64/bin/x86_64--netbsd-ld:
> ioconf.o:(.rodata+0x120): undefined reference to `stripattach'
>
>
> any clues?
strip(4) has been removed, are you sure you
Hi alL!
I try to build a current kernel and have this issue
# link HP620/netbsd
/usr/src/obj/tooldir.NetBSD-9.99.34-amd64/bin/x86_64--netbsd-ld -Map
netbsd.map --cref -T netbsd.ldscript -Ttext 0x8020 -e start
-z max-page-size=0x20 -X -o netbsd
Hi,
Robert Swindells wrote:
I use a mix of them on different architectures to speed up the build and
they seem to work. I'm not seeing clang built for amd64.
Is the test for the value case-sensitive ?
I supposed so, since the code checks for != "no"
So I changed it, but with limited
Greg Troxel wrote:
>Edgar Pettijohn writes:
>
>> I have tried the MKXXX=NO for lots of stuff and they always fail, so
>> I'm not sure what the correct way to use them is.
>
>I suspect that they fail because they are non-deafult. The right way
>is to debug them and send a patch :-) But
Edgar Pettijohn writes:
> I have tried the MKXXX=NO for lots of stuff and they always fail, so I'm not
> sure what the correct way to use them is.
I suspect that they fail because they are non-deafult. The right way
is to debug them and send a patch :-) But seriously, reporting
problems is
Hi Edgar,
Edgar Pettijohn wrote:
MKLLVM = NO
MKLLVMRT = NO
yet I think it is building it anyway
Riccardo
I built current yesterday no problem.
I have tried the MKXXX=NO for lots of stuff and they always fail, so I'm not
sure what the correct way to use them is.
I think I was able to
On Jan 8, 2020 6:38 AM, Riccardo Mottola wrote:
>
> Hi!
>
> current fails do build userland for me:
>
> # compile libclangARCMigrate/Transforms.o
> /usr/src/obj/tooldir.NetBSD-9.99.34-amd64/bin/x86_64--netbsd-c++
> -frandom-seed=dedfa0f2 -O2 -march=core2 -Werror -Wno-stringop-overflow
>
Hi!
current fails do build userland for me:
# compile libclangARCMigrate/Transforms.o
/usr/src/obj/tooldir.NetBSD-9.99.34-amd64/bin/x86_64--netbsd-c++
-frandom-seed=dedfa0f2 -O2 -march=core2 -Werror -Wno-stringop-overflow
-fPIE -march=core2 -std=c++14 -fno-rtti -fno-exceptions
Hi!
Update: it was an update build that did not work. Retrying without -u
and waiting for some time... succeeded.
I hate that :)
Riccardo
Riccardo Mottola wrote:
Hi all!
I did update CVS yesterday and started a nice build from tools, but it
fails with:
(upgrade unprivileged build)
Hi all!
I did update CVS yesterday and started a nice build from tools, but it
fails with:
(upgrade unprivileged build)
./build.sh -U -u tools
[...]
c++ -fno-PIE -c -DIN_GCC_FRONTEND -O -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall
Riccardo Mottola writes:
> … I updated once again pkgsrc, rebuilt
> gtk... and now building of emacs completed!
>
> So that issue is solved for me.
One issue I have is at the creation of new frames.
The visible frame truncates rapidly to show a short 4 lines from the
buffer.
What I have in
Hi Leonardo,
Leonardo Taccari wrote:
(More information was appended to PR pkg/53688 opened by Andreas
but I will try to summarize all possible details here too for
completeness, TLDR; emacs25-25.3nb10 and emacs26-26.1nb3 should
now works properly.)
Despite the buildlink3.mk change was needed
Hello Greg, Andreas and Riccardo,
Leonardo Taccari writes:
> [...]
> I have just added it to buildlink3.mk, please let me know if that
> fixes the problem you have reported! (just a `make replace' in
> emacs or any other problematic package should be enough to test
> that)
> [...]
(More
Hello Andreas, Greg and Riccardo,
Andreas Gustafsson writes:
> Greg, Riccardo,
>
> Please disregard the parts of my earlier mail that pertained to
> tests run under NetBSD-current. I had missed the fact that
> ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz is only
> regenerated weekly,
Greg, Riccardo,
Please disregard the parts of my earlier mail that pertained to
tests run under NetBSD-current. I had missed the fact that
ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz is only
regenerated weekly, and accidentally tested using a pkgsrc.tar.gz
that was five days old and
Andreas Gustafsson writes:
> Riccardo Mottola wrote:
>> while doing a full update with today's pkgsrc con current, I get:
> [..]
>> /usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so: undefined
>> reference to `epoxy_has_glx'
>
> I believe this is a pkgsrc-current issue and not a
Riccardo Mottola writes:
> Hi Greg,
>
> Greg Troxel wrote:
>>
>> Yes, but it can hit an error and exit without finishing.
>>
>> So I would run it again and see if it reports that there's nothing to
>> do.
>
> I did re-run it and it breaks out in the same place!
That in general isn't a good way
Riccardo Mottola wrote:
> while doing a full update with today's pkgsrc con current, I get:
[..]
> /usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so: undefined
> reference to `epoxy_has_glx'
I believe this is a pkgsrc-current issue and not a NetBSD-current nor
emacs-current issue,
Hi Greg,
Greg Troxel wrote:
Yes, but it can hit an error and exit without finishing.
So I would run it again and see if it reports that there's nothing to
do.
I did re-run it and it breaks out in the same place!
I don't have much useful advice, other than to start using nm or objdump
on
Riccardo Mottola writes:
> Greg Troxel wrote:
>> Riccardo Mottola writes:
>>
>>> while doing a full update with today's pkgsrc con current, I get:
>> by 'full update', what do you mean?
>
> I updated kernel, tools & distribtion to latest.
>
> Then I did update pkgsrc and run
Hi,
Greg Troxel wrote:
Riccardo Mottola writes:
while doing a full update with today's pkgsrc con current, I get:
by 'full update', what do you mean?
I updated kernel, tools & distribtion to latest.
Then I did update pkgsrc and run pkg_rolling-replace -uv
host os?
amd64,
Riccardo Mottola writes:
> while doing a full update with today's pkgsrc con current, I get:
by 'full update', what do you mean?
host os?
> /usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so: undefined
> reference to `epoxy_has_glx'
I dimly remember seeing epoxy/glx issues where
Hi,
while doing a full update with today's pkgsrc con current, I get:
CC fontset.o
CC fringe.o
CC image.o
CC xgselect.o
CC terminfo.o
CC lastfile.o
CC gmalloc.o
CCLD temacs
/usr/pkgsrc/editors/emacs26/work/.buildlink/lib/libgdk-3.so:
Hi,
Robert Swindells wrote:
Have you updated your xsrc tree too ?
That was it! Thanks. I had file-permission problems that made the
checkout incomplete. A chmod -R is your friend in these cases. I thus
have a clean update of both src and xsrc.
The daily snapshot builds are not giving this
On Wed, May 14, 2014 at 09:10:46AM +0200, Riccardo Mottola wrote:
Robert Swindells wrote:
Have you updated your xsrc tree too ?
That was it! Thanks. I had file-permission problems that made the checkout
incomplete. A chmod -R is your friend in these cases. I thus have a clean
update of both
Hi,
Thomas Klausner wrote:
On Mon, May 12, 2014 at 09:10:07AM +0200, Riccardo Mottola wrote:
nobody has a clue on this? I tried to build twice... getting the same
error...
Forgotten -Pd when updating your source tree?
Thomas
I redid a cvs -q update -dP
however build still fails:
Riccardo Mottola wrote:
Thomas Klausner wrote:
On Mon, May 12, 2014 at 09:10:07AM +0200, Riccardo Mottola wrote:
nobody has a clue on this? I tried to build twice... getting the same
error...
Forgotten -Pd when updating your source tree?
Thomas
I redid a cvs -q update -dP
however
Hi,
nobody has a clue on this? I tried to build twice... getting the same
error...
Riccardo
On 05/11/14 08:46, Riccardo Mottola wrote:
Hi,
while building distribution I get:
includes === external/mit/xorg/include/xf86vidmodeproto
includes === external/mit/xorg/include/renderproto
includes
On Mon, May 12, 2014 at 09:10:07AM +0200, Riccardo Mottola wrote:
nobody has a clue on this? I tried to build twice... getting the same
error...
Forgotten -Pd when updating your source tree?
Thomas
42 matches
Mail list logo
