search for: __assert

.../llvm-objects/tools/llvm-shlib' llvm[1]: Linking Release Shared Library LLVM-2.7.so /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x135): In function `(anonymous namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': : undefined reference to `__assert' /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x3e3): In function `(anonymous namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': : undefined reference to `__assert' /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(A...

On Thu, Apr 29, 2010 at 6:31 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Wed, Apr 28, 2010 at 10:48 AM, Yuri <yuri at tsoft.com> wrote: >> Jeffrey Yasskin wrote: >>> >>> We currently use two different techniques to get whole libraries >>> included into the .so. On Linux (gnu ld and gold), we pass >>> --whole-archive, while on

...e be warned as your get miss compiles and things will do strange `stuff`. As can be seen here, the reverse is true for both the GNU binutils and XPG4 versions of `nm' : -bash-3.2$ /usr/xpg4/bin/nm -p -u `find . -name libLLVMCore.a` | head ./Debug/lib/libLLVMCore.a[AsmWriter.o]: 0000000000 U __assert 0000000000 U __clzdi2 0000000000 U __udivdi3 0000000000 U __umoddi3 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 U _ZdaPv 0000000000 U _ZdlPv -bash-3.2$ /usr/bin/nm -p -u `find . -name libLLVMCore.a` | head ./Debug/lib/libLLVMCore.a[AsmWriter.o]: __assert __clzdi2 __udivdi3 __umo...

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: Nice!

...m-shlib' > llvm[1]: Linking Release Shared Library LLVM-2.7.so > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x135): > In function `(anonymous > namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': > : undefined reference to `__assert' > /tmp/llvm-build/2.7/llvm-objects/Release/lib/libLLVMARMAsmParser.a(ARMAsmParser.o)(.text+0x3e3): > In function `(anonymous > namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken)': > : undefined reference to `__assert' > /tmp/llvm-build/2.7/llvm-objects/Release/lib/...

...ed". Actually it was the -u that's redundant - the -g was necessary for GenLibDeps.pl: $ nm -p -u libLLVMCore.a libLLVMCore.a[AsmWriter.o]: __asert atof _GLOBAL_OFFSET_TABLE_ isalnum ... etc ... $ nm -p -g libLLVMCore.a libLLVMCore.a[AsmWriter.o]: 0000000000 U __assert 0000000000 U atof 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 U isalnum The latter being what GenLibDeps.pl expects to see. All else being equal though, it might be better to change GenLibDeps.pl to recognize the first version: --- GenLibDeps.pl (revision 78653) +++ GenLibDeps.pl...

...Program received signal SIGABRT, Aborted. [Switching to Thread 0x2002040 (LWP 100048)] 0x2229ce08 in kill () from /lib/libc.so.7 (gdb) bt #0 0x2229ce08 in kill () from /lib/libc.so.7 #1 0x22000848 in raise () from /lib/libthr.so.3 #2 0x2229b6a4 in abort () from /lib/libc.so.7 #3 0x22281d80 in __assert () from /lib/libc.so.7 #4 0x01c34a78 in update (this=0x200c940, n=1515870810, R=1515870810, Subtree=0x20298c0) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/ PredicateSimplifier.cpp:702 #5 0x01c3d134 in makeEqual (this=0x7fffd550, V1=0x2009730, V2=0x2006624) at /nfs/llvm/src/llvm/lib/Transform...

...1/04 16:33:02, 0] lib/util.c:log_stack_trace(1737) BACKTRACE: 21 stack frames: #0 0xd317d <smb_panic+93> at /usr/local/sbin/winbindd #1 0xbd536 <dump_core_setup+1014> at /usr/local/sbin/winbindd #2 0xbfbfffb4 #3 0x20694b8a <abort+106> at /lib/libc.so.7 #4 0x2067d096 <__assert+86> at /lib/libc.so.7 #5 0x2058a43f <ldap_parse_result+863> at /usr/local/lib/libldap-2.4.so.3 #6 0x1db45c <ads_clear_service_principal_names+2172> at /usr/local/sbin/winbindd #7 0x1db7df <ads_do_search_all_args+111> at /usr/local/sbin/winbindd #8 0x1e4d16 <ads_atyp...

...str) == 0, file /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c, line 3338. Abort (core dumped) (gdb) bt #0 0x481dfff7 in kill () from /lib/libc.so.7 #1 0x481dff56 in raise () from /lib/libc.so.7 #2 0x481deb8a in abort () from /lib/libc.so.7 #3 0x481c6546 in __assert () from /lib/libc.so.7 #4 0x0804aca7 in get_history_one (zhp=0x4831a100, data=0xbfbfac40) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c:3337 #5 0x0805293f in pool_list_iter (zlp=0x4830e030, unavail=0, func=0x804ab30 <get_history_one>, data=0xbfbfac40...

I am trying to install wine from the latest source on a FreeBSD 4.4 box. I did chip# ./configure --prefix=/usr/local/wine chip# make depend && make then chip# make install but am getting the following error. cd `dirname advapi32/__install__` && make install [ -d /usr/local/wine/lib ] || mkdir -p /usr/local/wine/lib /usr/bin/install -c libadvapi32.so

...uot;), function update, file /nfs/llvm/src/llvm/lib/Transforms/Scalar/ PredicateSimplifier.cpp, line 711. Abort (core dumped) (gdb) bt #0 0x2229ce08 in kill () from /lib/libc.so.7 #1 0x22000848 in raise () from /lib/libthr.so.3 #2 0x2229b6ec in abort () from /lib/libc.so.7 #3 0x22281d80 in __assert () from /lib/libc.so.7 #4 0x01c34b4c in update (this=0x200c940, n=1515870810, R=1515870810, Subtree=0x20298c0) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/ PredicateSimplifier.cpp:711 #5 0x01c3d224 in makeEqual (this=0x7fffd580, V1=0x2009730, V2=0x2006624) at /nfs/llvm/src/llvm/lib/Transform...

Hello, Alain. > I'm starting to play with LLVM today and I've trouble compiling it. > I'm > working under Windows Vista, with the gcc from Cygwin: Oh, this seems to be killer mix :) GCC (at least native mingw32 port) has known problems being running on Vista. > Is LLVM supposed to work with this version of GCC (probably using the > -mno-cygwin option to get a

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: > Could

...rc/llvm/lib/Transforms/Scalar/ > PredicateSimplifier.cpp, line 711. > Abort (core dumped) > > > (gdb) bt > #0 0x2229ce08 in kill () from /lib/libc.so.7 > #1 0x22000848 in raise () from /lib/libthr.so.3 > #2 0x2229b6ec in abort () from /lib/libc.so.7 > #3 0x22281d80 in __assert () from /lib/libc.so.7 > #4 0x01c34b4c in update (this=0x200c940, n=1515870810, R=1515870810, > Subtree=0x20298c0) at /nfs/llvm/src/llvm/lib/Transforms/Scalar/ > PredicateSimplifier.cpp:711 > #5 0x01c3d224 in makeEqual (this=0x7fffd580, V1=0x2009730, > V2=0x2006624) at /nfs/llvm/sr...

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

...) bt full #0 0x00000008014e6f7a in thr_kill () from /lib/libc.so.7 No symbol table info available. #1 0x00000008014e6f66 in raise () from /lib/libc.so.7 No symbol table info available. #2 0x00000008014e6ee9 in abort () from /lib/libc.so.7 No symbol table info available. #3 0x000000080154dee1 in __assert () from /lib/libc.so.7 No symbol table info available. #4 0x0000000803ea1762 in lucene::index::DocumentsWriter::closeDocStore() () from /usr/local/lib/libclucene-core.so.1 No symbol table info available. #5 0x0000000803ea3d89 in lucene::index::DocumentsWriter::flush(bool) () from /usr/local...

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

Hi! We found some problems with those patches, and ended up doing slightly different fix: https://github.com/dovecot/core/compare/3e41b3d%5E...cca98b.patch Aki On 24.10.2016 10:17, Aki Tuomi wrote: > Hi! > > Can you try these two patches? > > Aki > > > On 24.10.2016 08:48, Aki Tuomi wrote: >> Ok so that timeval makes no sense. We'll look into it. >>