Re: Network and port redirection with QEMU not working with package compiled on 10.0_RC1
Marc Baudoin écrit : > Greg Troxel écrit : > > > > When you upgrade packages, make sure you have every single package from > > a consistent build - same branch, same OS version. > [...] > > In the case of QEMU, I don't see any direct dependency which > could influence networking but I might be wrong. I was. net/libslirp (from DESCR: libslirp is a user-mode networking library used by virtual machines, containers or various tools) seemed to be the most probable suspect. My previous package had been compiled on 9.3 so I compiled a new one and QEMU now works like a charm.
Re: Network and port redirection with QEMU not working with package compiled on 10.0_RC1
Greg Troxel écrit : > > I really doubt reinstalling is necessary. > > When you upgrade packages, make sure you have every single package from > a consistent build - same branch, same OS version. Which would be almost as long as reinstalling from scratch anyway. I've been using pkgsrc for some 25 years and I never had to do that across system upgrades, it just works fine (well, except this time). Frequent revbumps make me compile anew most of what I use anyway. In the case of QEMU, I don't see any direct dependency which could influence networking but I might be wrong. > diff your /etc from unpacking the etc.tgz and xetc.tgz sets someplace > else. Understand the differences. I try to minimize them if I don't > intend them to differ. postinstall already does most of that. I generally just need to manually adjust /etc/master.passwd because postinstall does not seem to handle added users (no big deal). > Check your firewall configs extra carefully. Doesn't have any. So I'm stuck but I still have my not so old qemu-8.1.2nb1 package.
Re: Network and port redirection with QEMU not working with package compiled on 10.0_RC1
Michael van Elst écrit : > baba...@babafou.eu.org (Marc Baudoin) writes: > > >Has anybody got a working QEMU (at least network-wise) compiled > >on NetBSD 10.0_RC[12]? > > No problems here, neither with qemu-8.1.0 (2023Q3) nor qemu-8.1.3 (2023Q4): > > Host: > NetBSD tazz 10.99.10 NetBSD 10.99.10 (TAZZ) #311: Sun Dec 24 15:24:24 UTC > 2023 > mlelstv@slowpoke:/scratch2/obj.amd64/scratch/netbsd-current/src/sys/arch/amd64/compile/TAZZ > amd64 > > Guest: > NetBSD standalone 10.99.5 NetBSD 10.99.5 (GENERIC) #0: Sun Jul 9 00:01:55 > UTC 2023 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > amd64 > > configured with: > > -netdev user,id=n1 > -device virtio-net,netdev=n1 Thanks. Then it must be a problem specific to my computer but I don't know what could be the cause of this. As it's my main system, I'm reluctant to reinstall NetBSD from scratch (I've been upgrading it since it was originally installed with version 7) in order to have the least amount of downtime possible but that's the only solution I see now...
Re: Network and port redirection with QEMU not working with package compiled on 10.0_RC1
Marc Baudoin écrit : > > With all the recent revbumps in pkgsrc, emulators/qemu had to be > recompiled quite a few times in the last weeks. In the meantime, > I have upgraded my computer to 10.0_RC1. I delved a little more into this problem. Using a Debian 12 guest, the logging of dhclient is different (lines from a correct QEMU are prefixed with <, lines from a faulty QEMU with >): 9,10c9,10 < DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 5 < DHCPOFFER of 10.0.2.15 from 10.0.2.2 --- > DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 7 > DHCPOFFER of 10.0.2.15 from 255.255.0.10 12,13c12,14 < DHCPACK of 10.0.2.15 from 10.0.2.2 < bound to 10.0.2.15 -- renewal in 42303 seconds. --- > DHCPACK of 10.0.2.15 from 255.255.0.10 > Error: inet prefix is expected rather than "10.0.2.15/0.2.0.255". > bound to 10.0.2.15 -- renewal in 40924 seconds. Any other kind of guest system has the same problem (but the traces are more extensive with Debian) so it's a general QEMU problem. The last correct version of QEMU working for me is qemu-8.1.2nb1 compiled on NetBSD/amd64 9.3. Then I upgraded to 10.0_RC1 (and RC2 is no better) and recompiled QEMU because of several revbumps. qemu-8.1.2nb2 and later exhibit the problem above, although the version of QEMU was the same at the beginning (but 8.1.3 and 8.2.0 do not work either), so I suspect the problem lies with NetBSD 10.0 (probably a static library because behavior should be identical between versions with a shared library). Has anybody got a working QEMU (at least network-wise) compiled on NetBSD 10.0_RC[12]?
Re: Network and port redirection with QEMU not working with package
Marijan Unetić écrit : > Check chapter 30.4.2 in the netbsd guide, NetBSD VMs lacking IPv6 That's not my problem. NetBSD is my host, my guests are mostly Linux and they have no network whatsoever (and it's still working fine with a QEMU package built on 9.3).
Re: Network and port redirection with QEMU not working with package compiled on 10.0_RC1
Hi, Marc Baudoin écrit : > > With all the recent revbumps in pkgsrc, emulators/qemu had to be > recompiled quite a few times in the last weeks. In the meantime, > I have upgraded my computer to 10.0_RC1. > > I'm running my VMs with port redirection to be able to connect to > them with SSH this way: > > qemu-system-x86_64 -accel nvmm -m 1024 -hda vm.qcow2 -nic > user,hostfwd=tcp::-:22 > > This works fine with qemu-8.1.2nb1 (which I have compiled on > NetBSD 9.3): > [...] > > But it does not work with packages I have compiled since I > upgraded to NetBSD 10.0_RC1 (qemu-8.1.2nb2, qemu-8.1.2nb3 and > qemu-8.1.2nb4): Still not working with qemu-8.2.0 (package updated today). > Moreover, the VM has no network access. > > Downgrading to qemu-8.1.2nb1 compiled on NetBSD 9.3 makes port > redirection and the network work again on NetBSD 10.0_RC1. > > Does anybody else have the same problem? Am I the only one to have this problem?
10.0_RC1 iwm panic
Hi, Since I upgraded my laptop to 10.0_RC1 a little over a month ago, I've experienced three panics with the iwm driver. Here's the iwm0 I have in my laptop: [ 1,041044] iwm0 at pci3 dev 0 function 0: Intel Dual Band Wireless AC 8260 (rev. 0x3a) [ 1,041044] iwm0: interrupting at msi4 vec 0 Panics always happened while compiling mail/thunderbird on a mechanical hard drive (I cannot compile it anymore on my small SSD because newer versions require too much free space). Yes, this has nothing in common with Wi-Fi but that's what I experienced. The panics happen after many of this kind of message in the kernel log: [ 20699,125473] iwm0: autoconfiguration error: unhandled firmware response 0x8544 0x44/0x2c4208 rx ring 87[0] [ 20699,125473] iwm0: autoconfiguration error: unhandled firmware response 0xfcce 0xce/0xd1399214 rx ring 127[99] [ 20699,125473] iwm0: autoconfiguration error: unhandled firmware response 0xe0 0xe0/0x400d rx ring 0[0] Then: [ 20701,655451] panic: m_copydata(0x8d4601653000,104,0,0xc3842fe4f000): m=NULL, off=0 (0), len=16 (88) [ 20701,655451] cpu0: Begin traceback... [ 20701,655451] vpanic() at netbsd:vpanic+0x183 [ 20701,655451] panic() at netbsd:panic+0x3c [ 20701,665448] m_copydata.part.0() at netbsd:m_copydata.part.0+0xe9 [ 20701,665448] bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x263 [ 20701,665448] iwm_start() at netbsd:iwm_start+0x6f2 [ 20701,665448] if_transmit() at netbsd:if_transmit+0x140 [ 20701,665448] ether_output() at netbsd:ether_output+0x36b [ 20701,665448] ip_if_output() at netbsd:ip_if_output+0x86 [ 20701,665448] ip_output() at netbsd:ip_output+0xf04 [ 20701,665448] tcp_output() at netbsd:tcp_output+0x1622 [ 20701,665448] tcp_input() at netbsd:tcp_input+0xe80 [ 20701,665448] ipintr() at netbsd:ipintr+0x803 [ 20701,665448] softint_dispatch() at netbsd:softint_dispatch+0x95 [ 20701,665448] DDB lost frame for netbsd:Xsoftintr+0x4c, trying 0xc3842f99d0f0 [ 20701,665448] Xsoftintr() at netbsd:Xsoftintr+0x4c [ 20701,665448] --- interrupt --- [ 20701,665448] acda0ff91521d306: [ 20701,665448] cpu0: End traceback... The iwm driver has always been problematic (transfer rates are way lower compared to the same system running Linux, for instance) but it seems worse in 10. Getting a DHCP lease also often requires manually running dhcpcd after booting. I'll be happy to test patches, if anybody have an idea on how to solve these panics.
Network and port redirection with QEMU not working with package compiled on 10.0_RC1
Hi, With all the recent revbumps in pkgsrc, emulators/qemu had to be recompiled quite a few times in the last weeks. In the meantime, I have upgraded my computer to 10.0_RC1. I'm running my VMs with port redirection to be able to connect to them with SSH this way: qemu-system-x86_64 -accel nvmm -m 1024 -hda vm.qcow2 -nic user,hostfwd=tcp::-:22 This works fine with qemu-8.1.2nb1 (which I have compiled on NetBSD 9.3): % telnet localhost Trying ::1... telnet: Connect to address ::1: : Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u1 But it does not work with packages I have compiled since I upgraded to NetBSD 10.0_RC1 (qemu-8.1.2nb2, qemu-8.1.2nb3 and qemu-8.1.2nb4): % telnet localhost Trying ::1... telnet: Connect to address ::1: : Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. Moreover, the VM has no network access. Downgrading to qemu-8.1.2nb1 compiled on NetBSD 9.3 makes port redirection and the network work again on NetBSD 10.0_RC1. Does anybody else have the same problem?
Re: Bluetooth woes
Marc Baudoin écrit : > > # /etc/rc.d/bluetooth onestart > configuring Bluetooth controllers: ubt0btconfig: SIOCSBTFLAGS: Resource > temporarily unavailable > btconfig: cmd (03|024): Destination address required > btconfig: cmd (03|019): Destination address required > . > starting Bluetooth Link Key/PIN Code manager > starting Bluetooth Service Discovery server I forgot: % btconfig ubt0: bdaddr 00:00:00:00:00:00 flags 0x6e0
Bluetooth woes
Hi, I'm trying to use a Bluetooth mouse on my NetBSD/amd64 9.3 laptop but I can't get it to work: % dmesg | grep ubt [ 3,395938] ubt0 at uhub1 port 5 [ 3,395938] ubt0: vendor 8087 (0x8087) product 0a2b (0xa2b), rev 2.00/0.01, addr 1 % cat /etc/rc.conf.d/bluetooth btconfig_ubt0="name laptop-hostname" # /etc/rc.d/bluetooth onestart configuring Bluetooth controllers: ubt0btconfig: SIOCSBTFLAGS: Resource temporarily unavailable btconfig: cmd (03|024): Destination address required btconfig: cmd (03|019): Destination address required . starting Bluetooth Link Key/PIN Code manager starting Bluetooth Service Discovery server % dmesg | tail -n 1 [ 4899,826920] ubt0: autoconfiguration error: CommandComplete opcode (003|0003) failed (status=0x01) What I am doing wrong? The same laptop, when booted with Linux, has Bluetooth and the mouse working smoothly (so the hardware is fine).
Re: Problem with Firefox browser on NetBSD
Dmitrii Postolov écrit : > > On NetBSD and Firefox: window frames are not displayed correctly on some > sites and some pictures are not visible. I had exactly the same problem. Moreover some servers don't display properly at all (for me, it was Google calendar and Google maps). I figured out that might be related to locale. I have LANG=fr_FR.UTF-8 in my environment. Launching firefox with LANG=C solved the problem. I also had to delete ~/.dbus, ~/.cache and kill dbus before restarting firefox with LANG=C but I'm not sure it was really necessary after all. Does LANG=C work for you? > P.S. In some sites on NetBSD use Firefox without change of the > User Agent is impossible, some sites don't know about NetBSD > specs and try to display mobile version of site. That's something else.
Re: Bug in NetBSD grep ?
RVP écrit :
> On Tue, 16 Aug 2022, Marc Baudoin wrote:
>
> > The following command-line:
> >
> > echo 00:00: | grep -E '^([0]{2}[:-]){2}$'
> >
> > doesn't print anything on NetBSD (9.3) but it prints 00:00: back
> > (as it should, unless I made a mistake in my regular expression):
> > - on NetBSD with GNU grep from pkgsrc
> > - on FreeBSD with their standard grep (which claims to be
> > GNU-compatible)
> > - on Linux (with GNU grep)
> >
> > Is there a problem with the grep command shipped with NetBSD?
>
> Looks like a bug. It works if you force a C locale:
>
> $ echo 00:00: | LC_ALL=C grep -E '^([0]{2}[:-]){2}$'
> 00:00:
> $ echo $LANG
> en_GB.UTF-8
> $ echo 00:00: | grep -E '^([0]{2}[:-]){2}$'
> $ # nada
That's right:
% echo $LANG
fr_FR.UTF-8
% echo 00:00: | grep -E '^([0]{2}[:-]){2}$'
% echo 00:00: | LANG=C grep -E '^([0]{2}[:-]){2}$'
00:00:
I don't understand how the locale can impact grep that much.
Should I open a PR?
Bug in NetBSD grep ?
Hi,
The following command-line:
echo 00:00: | grep -E '^([0]{2}[:-]){2}$'
doesn't print anything on NetBSD (9.3) but it prints 00:00: back
(as it should, unless I made a mistake in my regular expression):
- on NetBSD with GNU grep from pkgsrc
- on FreeBSD with their standard grep (which claims to be
GNU-compatible)
- on Linux (with GNU grep)
Is there a problem with the grep command shipped with NetBSD?
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit : > On Mon, Feb 10, 2020 at 01:17:31PM +0100, Marc Baudoin wrote: > > Strangely enough, it doesn't happen on another system that have > > been upgraded (always with a binary install image) from 8.1 to > > several 9.0_BETAs over time then 9.0_RC1 then 9.0_RC2... > > The difference is: > > lrwxr-xr-x 1 martin wheel 12 Jan 31 13:19 > ./9.0/usr/include/g++/bits/gthr-default.h@ -> gthr-posix.h > -rwxr-xr-x 1 martin wheel 0 Jan 31 13:19 > ./updated/usr/include/g++/bits/gthr-default.h* Indeed, I have an empty (executable) /usr/include/g++/bits/gthr-default.h regular file. Replacing it with a symbolic link to gthr-posix.h seems to work (at least your previous example compiles now). > Sounds like a bsdtar bug :-( which also explains why it did not happen > for your beta updates. Then it would be nice to have it fixed before 9.0. Thanks!
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit :
> On Mon, Feb 10, 2020 at 11:01:37AM +0100, Marc Baudoin wrote:
> > I believe only C++ programs using pthread fail. I don't know how
> > to do a minimal example but the easiest way to see the problem is
> > to compile pkgsrc/multimedia/libvpx (which doesn't have too many
> > dependencies).
>
> Here is a trivial reproducer:
>
> --8<--
> #include
> #include
> using namespace std;
>
> int main(int argc, char **argv)
> {
> cout << "hello world\n";
> return 0;
> }
> -->8--
Thanks.
> Compile with c++ and watch it fail as you described.
>
> The original compilation was done with -std=c++11, but that does not seem
> to matter here.
It doesn't matter indeed, it always fail for me:
% c++ -std=c++11 toto.cxx
In file included from /usr/include/g++/memory:74:0,
from toto.cxx:1:
/usr/include/g++/ext/concurrence.h:124:5: error: ‘__gthread_mutex_t’ does not
name a type; did you mean ‘__pthread_volatile’?
__gthread_mutex_t _M_mutex;
^
__pthread_volatile
/usr/include/g++/ext/concurrence.h:169:5: error: ‘__gthread_mutex_t’ does not
name a type; did you mean ‘__pthread_volatile’?
__gthread_mutex_t* gthread_mutex(void)
^
__pthread_volatile
/usr/include/g++/ext/concurrence.h:179:5: error: ‘__gthread_recursive_mutex_t’
does not name a type; did you mean ‘__recursive_mutex’?
__gthread_recursive_mutex_t _M_mutex;
^~~
__recursive_mutex
/usr/include/g++/ext/concurrence.h:224:5: error: ‘__gthread_recursive_mutex_t’
does not name a type; did you mean ‘__recursive_mutex’?
__gthread_recursive_mutex_t* gthread_recursive_mutex(void)
^~~
__recursive_mutex
> The failure (at least with above test) does not happen in -current, nor
> when installing 9.0_RC2 from scratch.
But it happens for me on every system I have that have been
upgraded with an install ISO from 8.1 to 9.0_RC2.
Strangely enough, it doesn't happen on another system that have
been upgraded (always with a binary install image) from 8.1 to
several 9.0_BETAs over time then 9.0_RC1 then 9.0_RC2...
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit : > On Mon, Feb 10, 2020 at 08:07:07AM +0100, Marc Baudoin wrote: > > I just tried : > > > > - install NetBSD/amd64 8.1 from ISO > > - boot from 9.0_RC2 ISO and upgrade > > - reboot, get pkgsrc: any C++ build will fail > > Can you try a minimal C++ hello world program? > > I tried your recipe with i386 and at last hello world in c++ did work just > fine. I believe only C++ programs using pthread fail. I don't know how to do a minimal example but the easiest way to see the problem is to compile pkgsrc/multimedia/libvpx (which doesn't have too many dependencies).
Re: Problems with C++ compiler on 9.0_RC2
Kamil Rytarowski écrit : > On 06.02.2020 10:09, Marc Baudoin wrote: > > > > I recently upgraded a NetBSD/amd64 8.1 system to 9.0_RC2 and I > > noticed problems when compiling C++ programs. > > Please share a minimal reproducer. I just tried : - install NetBSD/amd64 8.1 from ISO - boot from 9.0_RC2 ISO and upgrade - reboot, get pkgsrc: any C++ build will fail
Re: Problems with C++ compiler on 9.0_RC2
Greg Troxel écrit : > Marc Baudoin writes: > > >> I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did > >> build > >> fine. > > > > Then can it be because of some leftover files from a previous > > version (the machine I have the problem on has seen every NetBSD > > version since 2013)? > > Yes, it could be. There is stuff in /usr/include/g++, and you need to > make sure you have only the bits that correspond to your installed > system version. > > Two things: > > postinstall check (and then fix) It has already been done in the upgrade process (I do it with sysinst while booting on an install USB stick and this is done after unpacking the new sets). > look in /usr/include for files that have a ctime greater than when you > unpacked the new sets. remove the old ones.Alternatively, unpack > the sets in a directory someplace and compare. Everything checks out, there are no leftover files in /usr/include...
Re: Problems with C++ compiler on 9.0_RC2
Manuel Bouyer écrit : > On Thu, Feb 06, 2020 at 12:13:31PM +0100, Marc Baudoin wrote: > > [...] > > I can't because I gave up on C++ some 20 years ago. Anyway, > > trying to compile pkgsrc/devel/cmake or pkgsrc/print/poppler > > fails every time for me as indicated in my previous message. > > > > It could also be a pthreads problem. But it's definitely linked > > to 9.0_RC2 as I didn't have it with 8.1. > > I guess it's from pkgsrc-current ? Yes it is. > I'm building pkgsrc 2019Q4 on 9.0_RC2/i386 and both poppler and cmake did > build > fine. Then can it be because of some leftover files from a previous version (the machine I have the problem on has seen every NetBSD version since 2013)?
Re: Problems with C++ compiler on 9.0_RC2
Kamil Rytarowski écrit : > On 06.02.2020 10:09, Marc Baudoin wrote: > > > > I recently upgraded a NetBSD/amd64 8.1 system to 9.0_RC2 and I > > noticed problems when compiling C++ programs. > > > > For instance, with pkgsrc/devel/cmake: [...] > > or with pkgsrc/print/poppler: > > Please share a minimal reproducer. I can't because I gave up on C++ some 20 years ago. Anyway, trying to compile pkgsrc/devel/cmake or pkgsrc/print/poppler fails every time for me as indicated in my previous message. It could also be a pthreads problem. But it's definitely linked to 9.0_RC2 as I didn't have it with 8.1.
Problems with C++ compiler on 9.0_RC2
Hi, I recently upgraded a NetBSD/amd64 8.1 system to 9.0_RC2 and I noticed problems when compiling C++ programs. For instance, with pkgsrc/devel/cmake: In file included from /usr/include/g++/memory:74:0, from cmake_bootstrap_13004_test.cxx:3: /usr/include/g++/ext/concurrence.h:124:5: error: '__gthread_mutex_t' does not name a type; did you mean '__pthread_mutex_st'? __gthread_mutex_t _M_mutex; ^ __pthread_mutex_st /usr/include/g++/ext/concurrence.h:169:5: error: '__gthread_mutex_t' does not name a type; did you mean '__pthread_mutex_st'? __gthread_mutex_t* gthread_mutex(void) ^ __pthread_mutex_st /usr/include/g++/ext/concurrence.h:179:5: error: '__gthread_recursive_mutex_t' does not name a type; did you mean '__recursive_mutex'? __gthread_recursive_mutex_t _M_mutex; ^~~ [...] or with pkgsrc/print/poppler: In file included from /usr/include/g++/mutex:43:0, from /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Array.h:32, from /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Object.h:335, from /usr/pkgsrc/print/poppler/work/poppler-0.84.0/poppler/Annot.cc:61: /usr/include/g++/bits/std_mutex.h:63:13: error: '__gthread_mutex_t' does not name a type; did you mean '__pthread_mutex_st'? typedef __gthread_mutex_t __native_type; ^ __pthread_mutex_st /usr/include/g++/bits/std_mutex.h:70:5: error: '__native_type' does not name a type; did you mean '__false_type'? __native_type _M_mutex; ^ __false_type /usr/include/g++/bits/std_mutex.h: In constructor 'std::__mutex_base::__mutex_base()': /usr/include/g++/bits/std_mutex.h:75:38: error: '_M_mutex' was not declared in this scope __GTHREAD_MUTEX_INIT_FUNCTION(&_M_mutex); ^~~~ Is it a problem with my setup, with pkgsrc or is there something wrong with the C++ environment in 9.0_RC2?
State of ZFS in 9.0_BETA
Hi, ZFS has been updated for 9.0_BETA. I've tried it and it seems usable (I couldn't make it work in 8.0 so it's a real progress). Now I'd like to know what's its state in 9.0_BETA (still experimental, quite stable, production ready --- might be too early) and what's the goal for the future? Thanks.
Re: libstdc++.so.7 is missing
Martin Husemann écrit : > On Thu, Jan 17, 2019 at 02:35:34PM +0100, Pedro Pinho wrote: > > Nope, this was/is 8.0 from the start. > > And you did not have any pkgs pre-installed? > > The problem is that 8.0 had libstdc++.so.8.0, and nothing compiled for 8.0 > should ever refer to libstdc++.so.7. It depends where this libstdc++.so.7 is. On my system (8.0 from the start also), gcc packages install several versions of libstdc++.so.7: /usr/pkg/gcc6/lib/libstdc++.so.7 /usr/pkg/gcc6/lib/libstdc++.so.7.22 /usr/pkg/gcc6/lib/libstdc++.so.7.22-gdb.py /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7 /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22 /usr/pkg/gcc6/x86_64--netbsd/lib/libstdc++.so.7.22-gdb.py /usr/pkg/gcc8/lib/libstdc++.so.7 /usr/pkg/gcc8/lib/libstdc++.so.7.25 /usr/pkg/gcc8/lib/libstdc++.so.7.25-gdb.py
Re: uselocale() function
Martin Husemann <mar...@duskware.de> écrit : > On Tue, Feb 14, 2017 at 12:39:52PM +0100, Marc Baudoin wrote: > > Well, that piece of software happens to be written in C++. I > > dont't know why the author doesn't use that model. > > In case it wasn't clear: what I meant is: set the locale for individual > stream objects explicitly. > > Most simple example: > >cout.imbue(locale::classic()); >cout << 2.5f << endl; > > (this is a bad example as it modifies the global cout, which is nearly > as bad as calling uselocale()/setlocale() or friends). > > In general you would open a stream on a file and then set its locale reference > properly for that file. The C variant (printf_l(3)) is slightly > worse, as you need to pass the locale on every output call. Thanks.
Re: uselocale() function
Martin Husemann <mar...@duskware.de> écrit : > On Tue, Feb 14, 2017 at 11:23:45AM +0100, Marc Baudoin wrote: > > Hi, > > > > I'm responsible for building the NetBSD binaries for the TeX Live > > distribution. We're preparing the 2017 release and I have a > > problem with the new version of a component (dvisvgm). It uses a > > uselocale() function which doesn't seem to exist in > > NetBSD-release. It's supposed to be part of POSIX : > > > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/uselocale.html > > We do not implement that. It is rarely usefull and only obfuscates code > by separating the locale setting from the actual output that requires it. > The C++ model is much more usefull... Well, that piece of software happens to be written in C++. I dont't know why the author doesn't use that model. > > How to handle this? Is there a replacement that could act as this > > uselocale() function or emulate it? > > Use printf_l(3) and friends. Most typical use in software is to force the > C locale, which is even simpler by using LC_C_LOCALE, like: > > printf_l(LC_C_LOCALE, "this is a float value: %.2f\n", 2.5f); Thanks, I'll suggest that to the author.
uselocale() function
Hi, I'm responsible for building the NetBSD binaries for the TeX Live distribution. We're preparing the 2017 release and I have a problem with the new version of a component (dvisvgm). It uses a uselocale() function which doesn't seem to exist in NetBSD-release. It's supposed to be part of POSIX : http://pubs.opengroup.org/onlinepubs/9699919799/functions/uselocale.html How to handle this? Is there a replacement that could act as this uselocale() function or emulate it?
