similar to: Speex 1.2 beta2 Win32 tools binaries

On 7/27/07, Ivo Emanuel Gon?alves <justivo@gmail.com> wrote: > On 7/24/07, Arseny Krasutsky <dtiger@mail.ru> wrote: > > So I can send this binaries to you if you want to place it online. > > I'm sure people need it :-) > > I do not know Jean-Marc's position on this -- it's his project, so I > don't want to meddle -- but if he does not oppose, I

Hi, I am an user of speex codec.Can I ask some question about the speexcodec 1.2beta2 on installed to linux(fedora 6) thanks! After I downloaded the latest version of codec then I type the commands to install : configure -prefix=/home/...../test -enable-shared -enable-static make make install then I try to compile my encode.c here is the encode.c of mine: =====================================

This is really unfortunate. I've read the discussion threads for the atom/chunk controversy and I feel like I understand the reasons for rewriting the linker, but this does not seem to have anything to do with whether the linker is usable as a library or not. As it stands, not only does lld have two completely different linkers (I'm treating COFF/ELF2 as one since they are really two

Hi, Jean-Marc, I have another quick question, I got following message when compile speexdec.exe: Linking... libspeex.lib(sb_celp.obj) : error LNK2001: unresolved external symbol _lpc_window Release/speexdec.exe : fatal error LNK1120: 1 unresolved externals Where does this lpc_window declare? Thanks a lot, -Allen On 8/8/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: >

----- Original Message ----- > From: "Rafael Espíndola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Yaron Keren" <yaron.keren at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Arseny Kapoulkine" <arseny.kapoulkine at gmail.com> > Sent: Tuesday, January 26, 2016 9:39:34 AM > Subject: Re: [llvm-dev] lld:

In the process of migrating from old lld ELF linker to new (previously ELF2) I noticed the interface lost several important features (ordered by importance for my use case): 1. Detecting errors in the first place. New linker seems to call exit(1) for any error. 2. Reporting messages to non-stderr outputs. Previously all link functions had a raw_ostream argument so it was possible to delay the

Hi everyone, I'm planning on releasing Speex 1.2beta2 in the next few days. I'd appreciate if everyone could try and test the current svn to make sure no bug crept in for your favourite plarform/application. Cheers, Jean-Marc

I think I have an idea to cover your need and possibly other people's on this thread. It provides the "main() as a library function" feature, input/output files wouldn't go through disks nor file systems, and it doesn't require any major design changes. Sounds too good? That is, we can provide a function that takes command line parameters, do fork, and call the linker's

If you want to link ELF object files, you are likely to be using a Unix machine. I'm not trying to address all possible problems but suggesting a practical solution. On Fri, Jan 22, 2016 at 9:49 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > On Windows fork() is not available. If exec() is used instead, process > creation time is several times slower than Linux. This may be

Dear all, In the download section of the Speex web site, you can find the Windows DLLs until the 1.2beta2 version, but for the newest version 1.2rc1 there aren?t any available. Therefore, I?m trying to generate the Windows DLLs for the 1.2rc1 version using the MSVC 2005 project files available in the source code. After a lot of problems, finally I have generated the DLLs. However there is a

> If I were a user, I definitely want the former instead of the latter because the former just provides more. This is if you wanted to use the library (e.g. embed linker into clang, do parallel linking of many executables from the same process, etc.). For some use cases there's no difference because the only thing you'll do with a library is link it into a command-line executable and

As a person who started this thread I should probably comment on the interface. My needs only require a library-like version of a command-line interface. Just to be specific, the interface that would work okay is the old high-level lld interface: bool link(ArrayRef<const char*> args, raw_ostream& diagnostics) This would require round-tripping data through files which is not ideal but

> Also, one of the other possible motivations of using LLD directly from Clang would be to avoid process overhead on operating systems where that is a much more significant part of the compile time cost. We could today actually take the fork out of the Clang driver because the Clang frontend *is* designed in this way. But we would also need LLD to work in this way. Then go change clang and

The context issue may be solved by making all functions and context data members of a class. Sort of having the convenience of global variables accessible from all linker functions but without the regular global variable problems of initializing and re-entry. so the class is suitable aspart of a library. Most clang and LLVM classes works this way, not passing contexts around. 2016-01-22 6:25

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: speex_vs2008.diff Type: application/octet-stream Size: 165590 bytes Desc: speex_vs2008.diff Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20071127/08917736/speex_vs2008-0001.obj

Hi, I am using version libvirt on debian lenny from backports repository, version 0.7.6-1~bpo50+1, amd64. Th functionality of "virsh net-edit" command is not very clearly documented, and I think it should change a configuration of a running network. But I see it doesn't. So, I want to add new host, for example: #I have old configuration root at xxx:/etc/libvirt/qemu/networks#

On Thu, Jan 7, 2016 at 7:18 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jan 7, 2016 at 7:03 AM, Arseny Kapoulkine via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In the process of migrating from old lld ELF linker to new (previously >> ELF2) I noticed the interface lost several important features (ordered by >>

Hi, Thanks! can this program generate speex.lib instead of libspeex.lib?? the OpenSpeak link to speex.lib instead of libspeex.lib I can compiled the libspeex.lib but not speex.lib. Correct me if I am wrong Thanks ----- Original Message ----- From: "Alexander Chemeris" <ipse.sipx@gmail.com> To: <alex@gorex.com.hk> Cc: <speex-dev@xiph.org> Sent: Tuesday, May 29,

Jean-Marc Valin wrote: ... > I think the amount of Windows crap is getting a bit ridiculous. Does > anyone know of a solution to keep things manageable? I mean, the same > autotools files manage the build for Linux PCs, Blackfins and MacOS (and > others). Yet, we need one set of files for each MS compiler version > (good thing they don't practice "release early, release

Hi Rui I agree separating the components out in to libraries only makes sense when there is a clear reason to do so. However, just this year there was a very involved discussion about what it means to be a library. Specifically, I don't think your current 'main-as-library' argument is valid while you call exit or (if you) rely on mutable global state. Having a single entry point