search for: _sources

Is there any specific reason why the clang_rt.builtins-${arch} library is disabled for windows builds? if (NOT WIN32) foreach(arch x86_64 i386 arm) if(CAN_TARGET_${arch}) set_source_files_properties(${${arch}_SOURCES} PROPERTIES LANGUAGE C) add_compiler_rt_runtime(clang_rt.builtins-${arch} ${arch} STATIC SOURCES ${${arch}_SOURCES} CFLAGS "-std=c99") add_dependencies(builtins clang_rt.builtins-${arch}) endif() endforeach() endif() --Sumanth G ----...

..._script.rst was created to document the linker script support as implemented in lld. I just checked the website http://lld.llvm.org/ . At the bottom there is a link "Linker Script implementation notes and policy" but the target page shows as 403 Forbidden. Relatedly, http://lld.llvm.org/_sources/ does not include the "ELF" directory. Does the page require a webmaster's manual operation?

...:37:10 CET Richard W.M. Jones wrote: > This commit, which is just code motion, moves the common XDR protocol > code (libprotocol) and the common errno handling (liberrnostring) into > libraries which are each built once and shared between the library and > daemon. > --- > guestfsd_SOURCES = \ > + ../common/errnostring/errnostring.h \ > + ../common/protocol/guestfs_protocol.h \ > [...] > libguestfs_la_SOURCES = \ > + ../common/errnostring/errnostring.h \ > + ../common/protocol/guestfs_protocol.h \ Are these two changes needed? The targets already depend on the ....

according to my little knowledge about automake, its not possible to put variables in _SOURCES. so something like speexdec_SOURCES = speexdec.c wav_io.c $(WIN32_OBJ) is not possible. but than i looked into wave_out.c and the entire source is surrounded by #if defined WIN32 || defined _WIN32 so it will just disappear than build on linux. j On Fri, 2004-02-13 at 07:59, Jean-Marc Valin wrote:...

I have an old conferencing app that uses theora and I'm building it for win64. libthora 1.1 builds just fine, but libtheora 1.0 has errors related to assembly code when building for x64. I've tried using 1.1, but the video does not look right -- the clients all generate their own first 3 packets instead of sending them over the network since they assume they are all on the same version

...ly CPU time involved. The "distcheck" target builds a distribution candidate, produces a tar.gz of it, unpacks it, rebuilds it, and if everything is okay, the tar.gz is good to go. This will find ALL KINDS of subtle errors and a big part of getting the distribution right is setting up the _SOURCES variables to list things correctly. There's some other points not mentioned in the automake documentation. (1) It turns out to be incredibly handy to have control over what actually gets built when you're doing multi-platform stuff. You can add files to directories that WON'T be comp...

Because this 'feature' is broken (since 2013): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928 we have to replace all instances of $(top_srcdir) in *_SOURCES lines with a relative path. According to what I read, this shouldn't break split builds, but I didn't test it. The only things automake moans about now are: * Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/...

Hi, We are rebasing our audio compression subsystem using OPUS rather than SPEEX. The platform is Android but this piece is written in C code: we need to support armv5/armv7/x86 architectures.... and we use the released opus-1.1beta package from here<http://downloads.xiph.org/releases/opus/opus-1.1-beta.tar.gz>. A lot of our OPUS build system + code to drive the audio compression has been

.... The "distcheck" target builds a > distribution candidate, produces a tar.gz of it, unpacks it, rebuilds > it, and if everything is okay, the tar.gz is good to go. This will find > ALL KINDS of subtle errors and a big part of getting the distribution > right is setting up the _SOURCES variables to list things correctly. FWIW, I don't believe that the build system for LLVM proper is the problem. I think the problems stem from the following: o) The llvm-gcc binary distributions take awhile due to the following complications: o After building it, I put the build into a cf...

-------------- next part -------------- A non-text attachment was scrubbed... Name: speex.mingw.patch__charset_ISO-8859-15 Type: text/x-patch Size: 1490 bytes Desc: speex.mingw.patch__charset_ISO-8859-15 Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20040212/51b4c2a9/speex.mingw-0001.bin

...bj/local/armeabi/lib0.a(analysis.o): in function > run_analysis:jni/src/libopus/src/analysis.c:636: error: undefined reference to > 'optimize_framesize' Don't include analysis.c, mlp.c or mlp_data.c in the fixed point build. Those files are float-only. I'd recommend parsing *_sources.mk from the source tree and using that to construct your build dictionaries. That way you'll get an accurate source list and not have to track changes to the source file lists manually. -r

Eric Anholt (20): Use ENXIO instead of ENODATA for pci reads returning less than desired. Add endian macros for BSD. Add the beginnings of a FreeBSD port. Add missing newline at the end of the file. Update .gitignores. Add pciaccess_private.h to _SOURCES so it gets included in the dist. Enable more warnings when the compiler is GCC. Fix many warnings and bugs in the freebsd implementation. Remove extra fallback definition of PCIIDS_PATH. Open the pci device read-write so we can read and write config regs. Add support f...

...nows about your source files, usually the only things that need to be added are random little files that aren't used directly in the build. These should be added to an EXTRA_DIST variable in the appropriate Makefile.am. You also have to be sure that all of your .h files are listed either in a _SOURCES variable (for headers that should not be installed) or in an include_HEADERS variable. I'll try to put together a patch to make all of this work; it shouldn't take too much effort. If you use 'make distcheck', it will build the distribution, then attempt a VPATH build. This is a...

...t; --- Makefile.am | 6 +++--- intel/Makefile.am | 10 ++++++---- nouveau/Makefile.am | 4 +++- 3 files changed, 12 insertions(+), 8 deletions(-) diff --git a/Makefile.am b/Makefile.am index e434e1d..61da186 100644 --- a/Makefile.am +++ b/Makefile.am @@ -55,13 +55,13 @@ libdrm_la_SOURCES = \ xf86drmHash.c \ xf86drmRandom.c \ xf86drmSL.c \ - xf86drmMode.c \ - libdrm_lists.h + xf86drmMode.c libdrmincludedir = ${includedir} libdrminclude_HEADERS = xf86drm.h xf86drmMode.h -noinst_HEADERS = xf86atomic.h +noinst_HEADERS = xf86atomic.h \ + libdrm_lists.h EX...

On 20 December 2013 10:43, Alexey Samsonov <samsonov at google.com> wrote: > There are simply no CMake build rules for building compiler-rt > libraries targeting ARM (see compiler-rt/lib/CMakeLists.txt). > Hi Alexey, I've added the ARM files on that CMake file but I got nothing compiled on ARM. Am I missing something? About the sanitizers, is there anyone that is known to

...AME[.c])])dnl AC_CHECK_FUNCS([$1], , [gl_LIBOBJ($ac_func)]) ]) # Like AC_LIBSOURCES, except the directory where the source file is # expected is derived from the gnulib-tool parameterization, # and alloca is special cased (for the alloca-opt module). # We could also entirely rely on EXTRA_lib..._SOURCES. AC_DEFUN([gl_LIBSOURCES], [ m4_foreach([_gl_NAME], [$1], [ m4_if(_gl_NAME, [alloca.c], [], [ m4_define([gl_LIBSOURCES_DIR], [lib]) m4_append([gl_LIBSOURCES_LIST], _gl_NAME, [ ]) ]) ]) ]) # Like AC_LIBOBJ, except that the module name goes # into gltests_LIBOBJS instea...

Hi I'm new with ogg and also with using third party libraries. I'm making a C++ PocketPC program and I need a simple wav->ogg encoder function. But as I have tried to use ogg vorbis libraries I don't know what or how to use them. I think that best way would be to use libogg 1.1.3 and libvorbis 1.1.2. Do I even need both of them, since I only need to have capability of

...k" target builds a > > distribution candidate, produces a tar.gz of it, unpacks it, rebuilds > > it, and if everything is okay, the tar.gz is good to go. This will find > > ALL KINDS of subtle errors and a big part of getting the distribution > > right is setting up the _SOURCES variables to list things correctly. > > FWIW, I don't believe that the build system for LLVM proper is the > problem. I think the problems stem from the following: > > o) The llvm-gcc binary distributions take awhile due to the following > complications: > o After bui...

--- Christian Weisgerber <naddy@mips.inka.de> wrote: > Josh Coalson <xflac@yahoo.com> wrote: > > > I have checked in all the latest into CVS and am going to start the > > test suite again. if all goes well I will probably release this as > > beta 10. > > What's the sequence of steps required to turn this into a buildable > distribution? >

...source files, usually the only things that need to be added > are random little files that aren't used directly in the build. These should > be added to an EXTRA_DIST variable in the appropriate Makefile.am. You also > have to be sure that all of your .h files are listed either in a _SOURCES > variable (for headers that should not be installed) or in an include_HEADERS > variable. I'll try to put together a patch to make all of this work; it > shouldn't take too much effort. Attached is the diff. I wasn't able to completely test the distribution, since src/libFL...