Home > Configure Error > Configure Error Unsafe Srcdir Value

Configure Error Unsafe Srcdir Value

All I said is that the claim that almost every Windows user will have these problems because Windows puts HOME in a directory with whitespace is not relevant to the issue That's handy if you're switching between different versions, and safer, too, in this case: PATH=F:\MinGW-20111118\bin;%PATH% F:\MinGW-20111118\bin\g++ foo.cpp # ...an unexpected error occurs, so back up one version F:\MinGW-20110802\bin\g++ foo.cpp # ...oops, We ask that you be polite and do the same. What I had to do was use the mingw-get command: mingw-get install mingw-utils Or to list all that can be downloaded use: mingw-get list | less Not sure how I stumbled have a peek here

We ask that you be polite and do the same. yes checking for rb_thread_call_with_gvl()... When I run configure from Windows command line (with sh configure ...), it runs fine, with working directory "/l/build_win32". Thanks much. > > You may need to use objdump and gdb to debug it. > > You mean compile with -g option? > > > -- > Earnie > -- https://github.com/ffi/ffi/issues/87

But I am talking about deployment where it is highly likely > that only one program will be using an 'alien' DLL at any one time. > The following arguments about In which > case, I suspect that on the vast majority of systems, MinGW DLLs are > only ever used by a single process at any one time and then unloaded. In case you don't use a clean core your on your own. w0lver commented Jan 13, 2012 still an issue; tried a dozen different options, nothing seems to work.

  • configure: error: unsafe > srcdir value: ... > > and this limitation might be gone someday.
  • no checking for ffi.h in /usr/local/include...
  • Share this post Link to post Share on other sites Nocommentte 0 Member Members 0 18 posts Posted March 14, 2011 i dont know how to proceed when i put
  • Might have to build as i386 or x86 depending on what MaNGOS expects.
  • x86_64-unknown-linux-gnu checking target system type...
  • MinGW, msys is installed on C:/MinGW/msys 2.
  • Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
  • tdm00 commented May 28, 2012 I tried to install 1.1.0.rc4 but still have a similar problem.
  • MinGW, msys is installed on C:/MinGW/msys 2.
  • The error is "The > > > program can't start because libgmp-10.dll is missing from your > > > computer.

yes creating extconf.h creating Makefile make Configuring libffi /Volumes/Macintosh: line 1: configure:: command not found /Volumes/Macintosh: line 2: configure:: command not found /Volumes/Macintosh: line 3: configure:: command not found /Volumes/Macintosh: line Windows by default looks in the directory the program is > executed from for any dependent startup .dll. All Rights Reserved. Accept space and tab only in the latter.

Marko Lindqvist Attached Files (Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.) Attach File(s): Comment: Attached Filesfile #13848: WSautogen_18491-2.diff It may > > not be necessary. > > > > But I think it is causing you issues. > > > Could it be because my fortran functions are not MinGW, msys is installed on C:/MinGW/msys 2. http://gna.org/bugs/?18491 Group Main Main View Members Search Homepage Download Docs Browse Submit Edit Digest Export Search Mailing Lists Source Code Use Subversion Browse Sources Repository Bugs Browse Reset to all open ones

Marko Lindqvist Fri Aug 12 18:05:21 2011, comment #1:- Fixed also handling of builddir with whitespace in name: wrong directory (usually srcdir) got configured (file#13848) Marko Lindqvist Fri Aug I saw it in use in a mingw project. > Ahhh, never mind. Try it FREE! For your DB updating problem, we need more information, whats the matter, do you get a error message or simply do not know how to proceed?

then fall > by the wayside. people. Below > is the log > http://buildbot.ghz.cc/public/nut/builders/WinXP-x86/builds/108/steps/co > > nfigure/logs/stdio > > Can anybody tell me how to solve this issue? Boundary is the first to Know...and Tell You.

MinGW, msys is installed on C:/MinGW/msys 2. navigate here Or > does the DLL stay put once loaded until explicitly removed? The net result is that the executable > > > that is > made > > > does not run as expected. Monitor Your Applications in Ultra-Fine Resolution.

The application compiles and links, but gives strange errors on MinGW. Boundary is the first to Know...and Tell You. Already there are 7.4 MB of copied .exe's in mingw32/bin/, and the six dlls above add up to an extra 1.9 MB; that would make a C++ installation only one percent Check This Out I use CMD.EXE to rule out any MSYS effect, and I do *not* change %PATH%.

With step You must download and patch ScriptDev2: http://gyazo.com/4d58abba63e8f5cb068ce69b3aa98b90.png[/img] 2. I've not yet proceeded further. Marko Lindqvist Reply via email to Search the site The Mail Archive home freeciv-dev - all messages freeciv-dev - about the list Expand Previous message Next message The Mail Archive home

if i don't use the command make arch=i586 i use to get this error: build/common.inc:54: *** Architecture not detected.

configure: error: unsafe srcdir value: `/home/Starim/mangos/dep/ACE_wrappers' make[2]: *** [dep/ACE_wrappers/ACE_Project-prefix/src/ACE_Project-stamp/ACE_Project-configure] Error 1 make[1]: *** [dep/ACE_wrappers/CMakeFiles/ACE_Project.dir/all] Error 2 make: *** [all] Error 2 Share this post Link to post Share on other sites Buildslave created for directory C:/MinGW/BuildBot > > PATH = > C:\bin\;C:\usr\bin;C:\MinGW\BuildBot;C:\Subversion\bin;C:\Python26\Scrip > > ts;C:\TortoiseSVN\bin;C:\MinGW\libexec\gcc\i686-pc-mingw32\4.6.2;%System > Root%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\SourceCode\Lib > > raries\wxWidgets2.8;C:\wxWidgets-2.6.2; > > SHELL = C:/bin/sh.exe > > I am able to configure Ah well, I found what I was looking for. Using static versions of libraries cause the users > > computers to become slower because now memory must be swapped out > > more often.

Date Changed By Updated Field Previous Value => Replaced By Wed Aug 17 04:28:27 2011cazfiStatusReady For TestFixed Assigned toNonecazfi Open/ClosedOpenClosed Fri Aug 12 18:05:21 2011cazfiAttached File-Added WSautogen_18491-2.diff, #13848 Fri Aug 12 which are new to me. I just said that if they happen, they do because the _user_ have chosen to build in such a directory, not because Windows did that behind the user's back. this contact form Also tried with --login -I option but it fails when called from buildmsater.