similar to: [LLVMdev] Subversion head: build problem on cygwin?

Hi, Jules. On Tue, March 11, 2008 2:14 pm, Jules wrote: > Not sure if this is me or not, because this is the first time I've built > LLVM on Cygwin, but I can't get a working compile. Last I checked, LLVM-on-Cygwin has at least two problems, and you've hit one of them. Working around them isn't too bad, though patches to fix them would be appreciated. >

I get the following problem building LLVM 2.7 on AIX 6: gmake[1]: Entering directory `/home/home/ac/psimmons/llvm/llvm-2.7/lib/System' llvm[1]: Compiling Path.cpp for Release build In file included from Path.cpp:262: Unix/Path.inc: In static member function 'static llvm::sys::Path llvm::sys::Path::GetTemporaryDirectory(std::string*)': Unix/Path.inc:142: error: 'mkdtemp' was

Dear Patrick, Documentation on some AIX routines to do the same thing can be found at http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/proguide/ref/dynamic_load.htm. Interestingly enough, the same page suggests that AIX does, in fact, support dlopen() and friends for POSIX compatibility. You might need to find out if there's a header file or a

On Aug 22, 2010, at 3:38 PM, Patrick Simmons wrote: > I get the following problem building LLVM 2.7 on AIX 6: > > gmake[1]: Entering directory > `/home/home/ac/psimmons/llvm/llvm-2.7/lib/System' > llvm[1]: Compiling Path.cpp for Release build > In file included from Path.cpp:262: > Unix/Path.inc: In static member function 'static llvm::sys::Path >

I am updating our out-of-tree copy of LLVM to track the head (revision #272991 specifically). I have it building successfully with VC++ 2013 and CMake v3.5.2 on Windows, and with GCC v4.8.5 and CMake v3.5.2 on CentOS; but when I try building on Windows using Cygwin32 I get the following build failures: [ 4%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/Signals.cpp.o In file

Googling indicates that cygwin doesn't have that functionality. Or, at least, didn't in 2010, when someone asked about the same problem: https://cygwin.com/ml/cygwin/2010-01/msg00596.html "cygwin has only dlsym() not the SGI DL_info + dladdr() yet. clang just needs it to get the path for the CIndex dll. This should be possible with the code in the LLVM_ON_WIN32 section, and convert

Hi All, I am trying to build llvm on AIX. I installed all the required packages including gcc, g++, etc ./configure also went fine. but i tried to run gmake, i got the following error: llvm[1]: Compiling MemoryBuffer.cpp for Release+Asserts build llvm[1]: Compiling MemoryObject.cpp for Release+Asserts build llvm[1]: Compiling Mutex.cpp for Release+Asserts build llvm[1]: Compiling Path.cpp for

Sam Bishop wrote: > What LLVM is trying to do here is determine its own path. I don't know > if the approach being used will work on Cygwin. (The code is very new, > and it's never worked on Cygwin.) You could try reading the > /proc/$$/exe symlink. I don't know how long Cygwin has been emulating > /proc, though. The dladdr() code won't work on Cygwin; the

I was able to process further by making some code changes and replacing export-dynamic with -bexpfull in Makefile.config. Now, i am getting following error while linking .. llvm[3]: Linking Release+Asserts Loadable Module LLVMHello.so ld: 0706-027 The -R $ORIGIN flag is ignored. ld: 0711-317 ERROR: Undefined symbol: llvm::Pass::getPassName() const ld: 0711-317 ERROR: Undefined symbol:

On Fri, Jul 13, 2012 at 1:40 PM, Benjamin Kramer <benny.kra at gmail.com>wrote: > > On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com> > wrote: > > > Benjamin Kramer wrote: > >> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> > wrote: > >> > >>> Hi all, > >>> >

Chandler Carruth wrote: > On Fri, Jul 13, 2012 at 1:40 PM, Benjamin Kramer <benny.kra at gmail.com > <mailto:benny.kra at gmail.com>> wrote: > > > On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com > <mailto:gabor.greif at alcatel-lucent.com>> wrote: > > > Benjamin Kramer wrote: > >> On 13.07.2012,

Hi everyone, I ran into a false positive with memory sanitizer due to it not intercepting dlinfo. I tried to get started on writing such an interceptor, but dlinfo seems like an extraordinarily difficult function to intercept. The three considerations that I would like somebody to look at are: 1) How do we get the enum values to decide what kind of pointer dlinfo is getting. Ideally we'd

Thanks! I'll try that. In order to avoid starting a new thread, let me ask you the next question. One of the shared libraries I load calls strtol and msan fails to intercept it. Why would this be? The library seems to be otherwise implemented. One of the potential culprits I saw is that strtol is marked as strong in libc. Is there any workaround? Keno On Thu, Apr 9, 2015 at 3:00 PM, Evgeniy

On Mar 11, 2008, at 8:10 PM, Sam Bishop wrote: > Sam Bishop wrote: >> What LLVM is trying to do here is determine its own path. I don't >> know >> if the approach being used will work on Cygwin. (The code is very >> new, >> and it's never worked on Cygwin.) You could try reading the >> /proc/$$/exe symlink. I don't know how long Cygwin

Hi, In FreeBSD 5.0-REL the dlinfo() manpage is present but the function does not seem to be implemented, is there a good reason for this ? -- Aurelien

On Wed, March 12, 2008 11:23 pm, Chris Lattner wrote: > Please attach patches as attachments (and name the file ".patch" just > in case). Mail readers commonly munge them (e.g. by removing trailing > whitespace) if not, which prevents the patch from applying. Hmm... What you got was the result of me telling Thunderbird to attach a file called

Seems like this in 83986 [1] needs a fix in Lapack.c: if (dladdr((void *) F77_NAME(ilaver), &dl_info)) { char buf[PATH_MAX+1]; char *res = realpath(dl_info.dli_fname, buf); if (res) { SEXP nfo = R_NilValue; if (strstr(res, "flexiblas")) nfo = R_flexiblas_info(); if

On 12/7/16, Yaakov Selkowitz <yselkowitz at cygwin.com> wrote: > On 2016-12-07 17:57, Roger Pack wrote: >> Awesome. I tried building 3.9.0 today and ran into >> >> llvm-3.9.0.src/lib/Support/Unix/Signals.inc:418:5: error: ‘Dl_info’ >> was not declared in this scope >> Dl_info dlinfo; > > Already fixed upstream: > >

Hi, The attached patch ensures that GetMainExecutable function in llvm-trunk/lib/System/Unix/Path.inc also works on Minix. I'm not sure it should be applied unmodified, because there may be controversial changes in it. In particular, one of the things it changes is this: - snprintf(buf, PATH_MAX, "%s//%s", dir, bin); + snprintf(buf, PATH_MAX, "%s/%s", dir, bin); in

On Sep 2, 2010, at 10:03 AM, Kees van Reeuwijk wrote: > - snprintf(buf, PATH_MAX, "%s//%s", dir, bin); There's no comment, and no mention in the commit message. It seems pretty safe to fix. > Also, the if-all-else-fails return value of GetMainExecutable is an empty path, but since the users of this function don't test for that, this choice leads to rather obscure