similar to: problem when using xapian's static libs in windows

I'm getting the following error when trying to build xapian. I've tried versions 0.9.1 and 0.9.2, same error. It's a x86 debian box, gcc 4.0.1. It builds fine on my gentoo amd64 box (gcc 3.4.3). Any ideas? Thanks, Alex make[3]: Leaving directory `/home/mcam/xapian-core-0.9.1/backends/flint' Making all in inmemory make[3]: Entering directory

Dear All, I've tried to build xapian-core 1.4.3 on MSYS2. It fails with attached error (undefined reference to `exp10'). I think it might be missing an explicit link to 'm'. I'm not able to fix this myself as I do not know autotools sufficiently well, but I hope you might be able to help. Cheers, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel.

Report by Eric Lindblad 13-09-2015 http://www.ericlindblad.blogspot.com cf: http://comments.gmane.org/gmane.comp.search.xapian.general/9862 I ported xapian-core-1.2.21 to Interix today having disabled the default chert and development brass backends, using flint, which was the 1.0.x series' default, which ships with the 1.2.x series; the disabling do to an unresolved 'ambiguous

Report by Eric Lindblad 10-09-2015 http://www.ericlindblad.blogspot.com cf: http://comments.gmane.org/gmane.comp.search.xapian.general/9862 interix Yesterday I compiled cppunit-1.12.1 on the Interix g++ (3.3) compiler. xapian Subsequent to disabling the remote backend which caused gmake to skip over the /net/tcpclient.cc:77 error, resulting in xapian libs' compile, today I disabled the

I posted this message first. But it was missing so I post again. I think there is a some bug in build configration files. Can you check up the following errors and fix it? The error has no concern with UTF-8 patch. Environment : CentOS 4.3 x86_64 Sungsoo Kim ---------------------------------- [root at saturn xapian-core-0.9.4_svn6707]# make ... ... mkdir .libs/libxapian.lax/libqueryparser.a

Eric, please keep these discussions on list. J > Begin forwarded message: > > From: Eric Lindblad <geirfuglaps at yahoo.com> > Subject: Interix issue resolved / Eric Lindblad > Date: 10 September 2015 10:01:06 BST > To: James Aylett <james-xapian at tartarus.org> > > J., > > Looks like the 'ambiguous overload' error* was due to Interix gcc-3.3

Report by Eric Lindblad 06-10-2015 http://www.ericlindblad.blogspot.com cf: http://permalink.gmane.org/gmane.comp.search.xapian.general/9885 modifications allowing for brass and chert to compile on SFU Interix 3.5 (modified) [code change not performance critical] /xapian-core-1.2.21/backends/brass/brass_check.cc /xapian-core-1.2.21/backends/chert/chert_check.cc #include <climits> +

[I took the liberty of replying on nut-upsdev - not many people are using github yet since the NUT repository native format is still SVN.] On Sep 4, 2012, at 10:17 AM, Emilien Kia wrote: > This is a proposal for a new client library which scopes an higher level than the existing libupsclient. > > It needs less dependencies to be compiled than the libupsclient and can be easier to

Report by Eric Lindblad 28-08-2015 http://www.ericlindblad.blogspot.com As of Windows 8.1 MS has discontinued enabling for Interix, so perhaps there is little or no interest in this e-mail's subject matter. NB: As far as possible languages for xapian-bindings I only have be able to compile earlier versions of Tcl with a static library on Interix 3.5, Perl versions fail 'make check',

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

On Fri, Dec 5, 2008 at 1:57 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >> / * snip */ > > Actually, rebuilding it makes "debug tblgen" fail with the errors at > the end of this email, and as such everything that depends on it, how > odd... > When I get back to that

Anton Korobeynikov pravi: > Hello, Ziga. > > >> VCPP throws a warning that class is previously declared as struct. >> Either it must be struct everywhere or class everywhere. >> Declaration uses struct, while the definition uses class. >> > Nice! However it will be better to do the opposite: have it struct > everywhere. I'll fix this. >

On 3/26/2012 06:52, Glenn McCord wrote: >> >> Did you compile the dll earlier? If so, you can try cleaning the project >> and rebuilding. > > I've compiled the .dll earlier, but they've now all been deleted. They > would have been built when I built the entire solution (and thus all > the projects). I've subsequently deleted them and just built the >

Question by Eric Lindblad 05-09-2015 http://www.ericlindblad.blogspot.com I would enquire if anyone has an opinion on whether it might be a possibility that adding the following #ifdef in certain xapian-core-1.2.21 /common and/or /backends files following the string #include <sys/types.h> might move closer towards resolution the 'ambiguous overload' issue. +#ifdef __INTERIX +#

Hi. I'm trying to get a project linking to libFLAC_static.lib but I get linker errors such as the following. 6>AudioDecoder.lib(CFlacDecoder.obj) : error LNK2019: unresolved external symbol __imp__FLAC__stream_decoder_process_until_end_of_metadata referenced in function "protected: int __thiscall CFlacDecoder::CreateDecoder(void)" (?CreateDecoder at CFlacDecoder@@IAEHXZ)

On Fri, Mar 23, 2012 at 9:45 PM, JonY <jon_y at users.sourceforge.net> wrote: > On 3/23/2012 13:59, Glenn McCord wrote: >> Hi. I'm trying to get a project linking to libFLAC_static.lib but I >> get linker errors such as the following. >> >> The __imp__ prefix seems to imply that some kind of .dll usage is >> happening, which it shouldn't. >>

On Tue, May 12, 2009 at 11:55 PM, Chris Lattner <clattner at apple.com> wrote: > Dan, can you add IVUsers.cpp to the appropriate cmakefile? > > -chris > > > On May 12, 2009, at 10:54 PM, OvermindDL1 wrote: > >> On Tue, May 12, 2009 at 11:40 PM, Chris Lattner <clattner at apple.com> >> wrote: >>> >>> On May 12, 2009, at 10:24 PM,

On Fri, Dec 5, 2008 at 1:58 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Fri, Dec 5, 2008 at 1:57 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >> On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >>> / * snip */ >> >> Actually, rebuilding it makes "debug tblgen" fail with the errors at >> the

Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at

I am now getting the following link errors on all executables: x86.lib(X86AsmPrinter.obj) : error LNK2001: unresolved external symbol "public: virtual bool __thiscall llvm::x86::X86ATTAsmPrinter::runOnMachineFunction(class llvm::MachineFunction &)" (?runOnMachineFunction at X86ATTAsmPrinter@x86 at llvm@@UAE_NAAVMachineFunction at 3@@Z) x86.lib(X86AsmPrinter.obj) : error LNK2001: