similar to: Broken build on musl libc

On 14 March 2016 at 09:02, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > commit a9f84425cfd5d1dbfb564730ca80d0b588cb4f24 > Author: Erik de Castro Lopo <erikd at mega-nerd.com> > Date: Mon Mar 14 18:14:31 2016 +1100 > > libFLAC/cpu.c: Use `sigemptyset` instead of `__sigemptyset` > > The former is POSIX while the later is a GNU

On 03/14/16 03:51 PM, lvqcl wrote: > With --disable-sse, FLAC__SSE_OS is undefined and FLAC__cpu_info() uses > sigemptyset/sigaction to determine OS SSE support. That's not quite right as I have to build binaries with --disable-sse (I build and distribute both with and without) so that some users on PII's don't get a sigill, even though the OS supports SSE. So it seems to

Hi, I?m trying to compile libguestfs on Alpine Linux, that uses musl libc (lightweight, fast and simple standards-conformance libc). It fails in the check phase due to missing glibc-style extended printf formatters. -- checking for register_printf_specifier... no checking for register_printf_function... no configure: error: in `/tmp/libguestfs/src/libguestfs-1.32.6?: configure: error: No support

Hello, I wanted to ask if there's a reason efi/wrapper.{h,c} use __uint*_t instead of including stdint.h and using the therein defined uint*_t types? This breaks compilation of the efi blobs on systems with the musl libc since that doesn't define __uint*_t types. -- Simon Thelen

https://bugzilla.mindrot.org/show_bug.cgi?id=2274 Bug ID: 2274 Summary: Build fixes for musl libc Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 Component: Miscellaneous Assignee: unassigned-bugs at mindrot.org

Commit-ID: e3e5ce11c99ce4e5638df44ed87661945a241632 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=e3e5ce11c99ce4e5638df44ed87661945a241632 Author: Baruch Siach <baruch at tkos.co.il> AuthorDate: Fri, 2 Mar 2018 08:32:16 +0200 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] histedit: fix build with musl

Commit-ID: a2020fbd897e3c3d41c75294f4e43a0e07487822 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=a2020fbd897e3c3d41c75294f4e43a0e07487822 Author: Baruch Siach <baruch at tkos.co.il> AuthorDate: Fri, 2 Mar 2018 08:32:16 +0200 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: histedit: fix build with

> Hello, > > I wanted to ask if there's a reason efi/wrapper.{h,c} use __uint*_t > instead of including stdint.h and using the therein defined uint*_t > types? This breaks compilation of the efi blobs on systems with the musl > libc since that doesn't define __uint*_t types. > > -- > Simon Thelen FWIW... As a simple quick basic test, I took the efi32

On Wed, Oct 7, 2020 at 3:43 AM Marvin Scholz <epirat07 at gmail.com> wrote: > > Hi, please provide the contents of the config.log > > I can not reproduce your issue on my machine, --without-openssl > works fine here. > > Oh and next time please mention that its about libshout right > away :) https://gist.github.com/neheb/a26714035978d07a822985477524cd45 > > On 7

Each time I run rsync it copies the same files even though I haven't made any changes. I doesn't copy all the files each time, just the same ones each time I run the command. I run rsync with the following command: rsync --verbose --stats --recursive user@host::directory directory The local system is Suse linux 9 and the remote system is Windows 2000 server. I have the same results

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good day eveyone, I'm hoping that someone can help me. Perhapps i'm overlooking the obvious, in truth, I hope that I am. I've scoured the mailing list and google, and haven't come up with much. I have a Digium T400P thats been connected to a channel bank for testing for some time now. all has been well. I've now just had

Vaclav, NUT is failing to build on OS X 10.6 and 10.7 With GCC/g++: http://buildbot.networkupstools.org/public/nut/builders/MacOSX-10.6-x86/builds/340/steps/compile/logs/stdio The same branch with clang/clang++: /bin/sh ../libtool --tag=CXX --mode=compile clang++ -DHAVE_CONFIG_H -I. -I../include -I../include -g -O2 -MT nutipc.lo -MD -MP -MF .deps/nutipc.Tpo -c -o nutipc.lo nutipc.cpp

# I need to generate some data. I'm modeling some time series that follow a # negative exponential decay (mostly). I have 20 samples that can easily be fit with cubic splines. # What I want to do is generate many thousands of similar samples using the parameters from the splines # For instance one data sample looks not unlike this: foo.curve <- 1 * exp(-0.01 * 1:500) + 0.5

I'm interested in further understanding the differences in using many classification trees to improve classification rates. I'm also interested in finding out what I can do in R and which methods will allow prediction. Can anybody point me to a citation or discussion? Specifically, I want to classify remotely sensed imagery where training data is extracted on class membership by the user.

> ELLCC (http://ellcc.org), my clang/LLVM based cross development tool chain for > ARM, Microblaze, Mips, Power PC, and X86, now incorporates musl > (http://www.etalabs.net/musl) as its standard C library for Linux. musl is a > MIT licensed, highly POSIX compliant library offering high performance and a > small foot print. I spent several weeks evaluating musl before deciding to use

ELLCC (http://ellcc.org), my clang/LLVM based cross development tool chain for ARM, Microblaze, Mips, Power PC, and X86, now incorporates musl (http://www.etalabs.net/musl) as its standard C library for Linux. musl is a MIT licensed, highly POSIX compliant library offering high performance and a small foot print. I spent several weeks evaluating musl before deciding to use it in ELLCC. The

>>>>> Alba Pompeo <albapompeo at gmail.com> >>>>> on Mon, 1 Feb 2016 15:33:11 -0200 writes: > Here's what I did. > svn checkout https://svn.r-project.org/R/trunk/ > cd ./trunk > aclocal -I m4 && autoconf > tools/rsync-recommended > cd .. > mkdir build > cd build > ../trunk/configure

Hi all, I'm interested in the LLVM Ocaml bindings so I pulled the current sources from SVN and built them. When I ran the test suite I got the following stats: # of expected passes 2631 # of unexpected failures 7 # of expected failures 11 It looks like some of the failures were due to the Ocaml parts of the tests: FAIL:

Hi, I've updated the musl version of the clang/LLVM based ELLCC compiler suite to use musl release 0.9.14. As usual the musl guys have been doing a great job. The new release looks great! http://ellcc.org I've also started to port libunwind into ELLCC. That's the last step for a fully non-gnu run-time environment: libcxx/libcxxabi/libunwind/musl/compiler-rt for C and C++ under

On Thu, Feb 04, 2016 at 04:35:22PM -0200, Alba Pompeo wrote: > I forwarded our talk on musl mailing list to R mailing list. > I got this response. > Does it help? > Also, what do you think about making a new email that's sent to both > musl and R mailing list, that way devs from both projects can > communicate? It's a tad inefficient for me to keep forwarding messages