similar to: [LLVMdev] CommandLine.cpp:189: error: `strdup' undeclared

Hi Guys I'm trying to port and build LLVM to the Interix environment. I've succeded until the Interix version of gcc program executes: Before the patch: gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support' gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' Compiling CommandLine.cpp

>From: Misha Brukman <brukman at uiuc.edu> >Date: Sat, 3 Jul 2004 19:33:12 -0500 >Well, the patch adds #include <cstring> to CommandLine.cpp, so you >should try the patch first. If it does not work, then the Interix SDK ><cstring> is not a fully complete substitue for <string.h>, which it >should be, then you may have to manually try changing the

Hi > >Are you able to explain below meaning to me? > >#if defined(_ALL_SOURCE) \ > || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED==1)) \ > || (__STDC__ - 0 == 0 && !defined(_POSIX_C_SOURCE)) >extern char* __cdecl strdup(const char *); >#endif /* defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED == 1) */ > (RTFM) Some of the above

Hi Guys I'm trying to port and build LLVM to the Interix environment. I've succeded until the Interix version of gcc program executes: gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support' gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' Compiling CommandLine.cpp CommandLine.cpp: In function

Hi I've found below declaration of strdup in /usr/include/string.h. But, I'm wondering why it doesn't belong to the ordinary function prototypes as extern char * __cdecl strcpy(char *, const char *);. Are you able to explain below meaning to me? #if defined(_ALL_SOURCE) \ || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE_EXTENDED==1)) \ || (__STDC__ - 0 == 0

>From: Chris Lattner <sabre at nondot.org> >Date: Wed, 14 Jul 2004 14:49:01 -0500 (CDT) > >There is currently support for building in non-cygwin windows environments >protected by _MSC_VER. You just need to broaden the scope of the #ifndef >to include internix. > Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting LLVM 1.2), so I'm not

>From: Chris Lattner <sabre at nondot.org> >Date: Wed, 14 Jul 2004 14:49:01 -0500 (CDT) >The file you need to modify is here: >llvm/include/Support/DataTypes.h.in > >There is currently support for building in non-cygwin windows environments >protected by _MSC_VER. You just need to broaden the scope of the #ifndef >to include internix. > Sorry, Chris, but my

Hi John, Please see below, too >From: John Criswell <criswell at cs.uiuc.edu> >Date: Tue, 27 Jul 2004 14:57:02 -0500 > >Henrik Bach wrote: >>Hi, > >Please see below. > >> >>I get this error: >>------------------ >>ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) >>ToolRunner.cpp:396: error: (Each

On Fri, 16 Jul 2004, Henrik Bach wrote: > >There is currently support for building in non-cygwin windows environments > >protected by _MSC_VER. You just need to broaden the scope of the #ifndef > >to include internix. > > > > Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting > LLVM 1.2), so I'm not at the moment able to edit the

Hi again Does cygwin support shared libraries. And if not, how did you port llvm on this issue? /Henrik >From: "Henrik Bach" <henrik_bach_llvm at hotmail.com> >Date: Tue, 27 Jul 2004 00:41:53 +0200 > >Hi, > >I get this error: >------------------ >ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) >ToolRunner.cpp:396:

>From: John Criswell <criswell at cs.uiuc.edu> >Date: Wed, 14 Jul 2004 09:11:03 -0500 > > >The DataTypes.h header file is generated by the configure script and placed >into your build tree. My best guess is that your system's header files do >not correctly define these macros, so they are missing. > I did a search on the build and source trees, but neither

Hi >From: Chris Lattner <sabre at nondot.org> >Date: Thu, 15 Jul 2004 17:43:27 -0500 (CDT) >Ah, suddenly everything makes sense. If you're interested in LLVM on the >windows platform, *please* get CVS. Last night I've got the latest version of LLVM from CVS and now porting LLVM to Interix from this version on. I got this error: --------------------- gmake[1]:

Hi Brian Here's the config.log (I'm not posting it on the dev-list). The automatic gcc macro for Interix is __INTERIX if this is to any help. /Henrik >From: "Brian R. Gaeke" <gaeke at uiuc.edu> >Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Subject: Re: [LLVMdev]

Hi, I get this error: ------------------ ToolRunner.cpp:396: error: `SHLIBEXT' undeclared (first use this function) ToolRunner.cpp:396: error: (Each undeclared identifier is reported only once for each function it appears in.) ------------------ And the config.log shows that configure has detected that ld on my platform (Interix) doesn't support shared libraries: ------------------

Here is an excerpt from the config.log: configure:19451: checking for int64_t configure:19476: gcc -c -g -O2 conftest.c >&5 configure:19479: $? = 0 configure:19482: test -s conftest.o configure:19485: $? = 0 configure:19496: result: yes configure:19511: checking for uint64_t configure:19536: gcc -c -g -O2 conftest.c >&5 configure:19539: $? = 0 configure:19542: test -s conftest.o

>From: Reid Spencer <reid at x10sys.com> >Date: Thu, 16 Sep 2004 13:26:09 -0700 > >Okay, so the question is, how do you do the equivalent of a MAP_ANON >allocation on Interix. We don't want to map a file here. We're just asking >for virtual memory (unbacked by swap or file) to be allocated to the >process. Is there a way to do that on Interix? The

Yes, Chris you're right. It seems that my << operator for int64_t is missing in my '/opt/gcc.3.3/include/c++/3.3/bits/ostream.tcc' file. Which ordinary version of GCC are you working with and how do your definition of the << operator for int64_t look like? /Henrik > >Here is an excerpt from the config.log for LLVM: > >configure:19451: checking for int64_t

Hi By manipulating a #define for G++ I've managed to compile int64_t type with ostream. Now, I'm stopped by some to me unknown constants: ----------------------------------- Compiling Constants.cpp Constants.cpp: In static member function `static bool llvm::ConstantSInt::isValueValidForType(const llvm::Type*, long long int)': Constants.cpp:368: error: `INT8_MAX' undeclared

On Wed, 7 Jul 2004, Henrik Bach wrote: > This tweak seems to work. > > As far as I can see, correct me if I'm wrong, it is the compiler, that can't > figure out which std::basic_ostream to use. Why? What I'm saying is that it appears that your implementation of operator<< is not functional or is missing. You said that you are using GCC on internix. Is it possible

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