similar to: Opus cmake build

Hi Mark, Thanks for the feedback. By default CMake is building the static library in debug, to get other things one has to explicit turn it on. To build in release mode for CMake you use the following flag: -DCMAKE_BUILD_TYPE=Release https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html CMAKE_BUILD_TYPE — CMake 3.14.1

On Wed, Apr 10, 2019 at 5:30 PM Marcus Asteborg <xnorpx at outlook.com> wrote: > Hi Mark, > > Thanks for the feedback. > > By default CMake is building the static library in debug, to get other > things one has to explicit turn it on. > > Hi, By default CMake uses the "empty" build, which is used in combination with the environment variables CFLAGS and

Right that I had completely missed, I have added the files and verified that it builds with CMake from the tar on Linux (out of the git repo) I am parsing the package_version file from the tarball if it exists so it should maintain the version info. //Marcus ________________________________ From: Jean-Marc Valin <jmvalin at jmvalin.ca> Sent: Tuesday, April 2, 2019 11:38 To: Marcus

Hi, Thanks for the quick feedback I have changed the name to avoid conflict. Attached is the updated patch. //Marcus ________________________________ From: Jean-Marc Valin <jmvalin at jmvalin.ca> Sent: Tuesday, April 2, 2019 00:07 To: Marcus Asteborg; opus at xiph.org Subject: Re: [opus] CMake support for Opus proposal (in addition to Autotools) Hi Marcus, There seems to be a conflict

Hi, Here is a proposal for adding CMake in addition of Autotools. See the attached patch for changes or the pull request here: https://github.com/xiph/opus/pull/100 The CMake scripts are parsing the filelist from Autotools, so only one file list needs to be maintained. With this change the checked in Visual Studio solution can be removed and no longer need to be maintained and updated when

Hi Marcus, Thanks for the fixes. I did some more cmake build testing and encountered a few issues: The option -DFORTIFY_SOURCE=2 should be -D_FORTIFY_SOURCE=2, as the macro has a leading underscore. In the autotools build it defines this if it is not already defined (m4/ax_add_fortify_source.m4). When custom modes are not enabled, the cmake build is nevertheless installing the include file

Hi all, With some downtime it's time for some CMake fixes. Most critically is the SSE fixes to avoid crashes that is described in 154 and 132 in github. Patch 5 should address this and also adding APPROX-FLOAT option. Hopefully this can give some gains for those of us running on Windows servers.j I went through the pull request and picked out a few that will ease up integration for

Hi I'm having a problem compiling opus-tools-0.1.7. Version opus-tools-0.1.6 seems to compile OK. I've tried with opus-1.0.3 and opus-1.1-beta. The errors are like this:- "undefined reference to `sqrtf'" etc. This OS is Peppermint Three, similar to Ubuntu 12.04. It uses:- gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Google says it's maybe something to do

Hello, I've spent some time hacking up the Debian packaging to use CMake instead of autotools; it's still a work in progress, but it works. It's a bit of a mess, though, primarily because there are differences in the output of the CMake and autotools builds. On my Ubuntu machine, the dependencies for clang-3.6 look like this: $ ldd /usr/bin/clang-3.6 linux-vdso.so.1 =>

On 2013-09-24 5:46 AM, Jean-Marc Valin wrote: > Seems like it's not linking with libm. I suspect it has to do with > linking statically with libopus.a (is that intended?). Maybe opus-tools > relies on the fact that libopus is linked with libm and doesn't > explicitly add it? Greg? Indeed. The opus-tools build explicitly adds -lm for opusdec and opusenc because they use math

Hi xiph, I'm trying to compile libopus from git.xiph.org/opus.git with emscripten. The regular: $ emconfigure ./configure --enable-fixed-point $ emmake make gets me quite far, but it hangs on the use of __malloc_hook in the tests: tests/test_opus_api.c:1776:16: error: use of undeclared identifier '__malloc_hook'; did you mean 'malloc_hook'? orig_malloc=__malloc_hook;

On Jul 24, 2013, at 11:11 AM, Jeremy Huddleston Sequoia wrote: > I recently took a stab at changing the MacPorts llvm-3.4 port from the configure-based build system to the cmake-based build system. > > There are a couple of issues that I still haven't been able to work out yet and would like to know if these are just configuration issues on my side or bugs I should file at

Hi, It looks like cmake currently defaults to no optimization, which I think is a bit unexpected for most users. I don't know how to do that in cmake, but it would be good to default to a "release" build with optimizations. Can you have a patch to do that? Also, is there a way to manually add flags to the compiler (like setting CFLAGS with autotools)? Cheers, Jean-Marc On

Hi, the first question is addressed both to llvm-dev and gentoo-dev. The second one is Gentoo specific. Is there any possibility to build LLVM both as static and shared libraries? What I see currently is that our ebuild makes LLVM to build shared libs unconditionally. Is there a possibility (if it is impossible to build both lib types) to at least give to user control on what kind of libs he

Thanks, it applies now. I think you'd also want to add some (all?) of these files to EXTRA_DIST in Makefile.am, otherwise your cmake files won't be included in release tarballs, which are generate using "make dist". To test, you should try running run "make dist" to generate a tarball yourself. From there, you try building the contents with your cmake files and see if

Hi Any idea what's causing these errors:- /home/user/build/lib/libopencore-amrnb.a(preemph.o): In function `preemphasis': /home/user/build/opencore-amr-0.1.3/amrnb/../opencore/codecs_v2/audio/gsm_amr/amr_nb/dec/src/preemph.cpp:193: multiple definition of `preemphasis' /home/user/build/lib/libopus.a(celt_encoder.o):/home/user/build/opus/celt/celt_encoder.c:455: first defined here

Samuel Crow <samuraileumas at yahoo.com> writes: > This time the autotools version of LLVM trunk build with Clang trunk compiled in > Debug+Asserts mode without complaint with --enable-bindings=none. I suspect > this makes something fishy looking with the CMake build. Do you need logfiles > from configure? I'm clueless about what's happening there. The cyclic

I want to start using cmake+ninja instead of autoconf for configuring and building llvm from svn, but I have no idea how to map my existing list of autoconf flags to cmake. Here's how I run ./configure right now in the top directory: PREFIX=_some_prefix_dir_ \ ../llvm/configure \ --prefix=$PREFIX \ --libdir=$PREFIX/lib/llvm \ --sysconfdir=$PREFIX/etc \ --enable-shared \

Using FFmpeg, I can stream to a file on disk okay: c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek High Definition Audio)" -c:a libopus -ac 1 -b:a 32000 live.caf But, if I add Icey metadata, FFmpeg throws errors: c:\apps\ffmpeg\bin\ffmpeg.exe -f dshow -i audio="Line In (Realtek High Definition Audio)" -c:a libopus -ac 1 -b:a 32000^ -ice_name

Hi All, First time poster to this group, please ignore my ignorance? I?m trying to use Opus 1.1 on a 400MHz MIPS 24k CPU (AR9331, specifically, like in the Arduino Yun). I?ve successfully built (I think) opus-1.1 and opus-tools-1.8 and they run, but are dog slow. opus-1.1 does have the ?enable-fixed-point option set, as this chip only has soft-float. My short test file (less than one