Reid,>As for Interix support in general, I'm having a hard time determining >which variant of Unix Interix implements. It seems to be partially Posix >1 and partially Posix 2 based. Do you have any further information >related to the specific standards supported by Interix? I don't want to >incorrectly categorize the Interix support.I've discussed this subject with the support staff from Interix: http://www.interopsystems.com/tools/forum/tm.asp?m=3336&mpage=1&key=ഌ As I see it: Interix supports: POSIX.1, POSIX.2 and Single UNIX Specification (SUS). However, the general rule is to use the define _ALL_SOURCE when compiling the source. This is the behavior I've succeded with Interix till now. However, for some header files some other defines has to be set to compile or you directly have to manipulate the files (comment some functions). I'm working to iron these cases out. /Henrik _________________________________________________________________ F� alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/
Henrik, Since Interix is POSIX and SUS compatible, I've separated its implementation in lib/System from SunOS. There are now separate *.cpp files in lib/System/Interix. They *might* just compile for you. If not, please correct and submit patches. Please update your configure script and lib/System to get the changes. You'll need to reconfigure in order to get the correct Interix support. If you're not subscribed to llvm-commits yet, I suggest that you subscribe so that you know when there are implementation changes in lib/System that you need to be aware of. As I create new .cpp files in lib/System (like I just did for SysConfig.cpp), I will create a version in lib/System/Interix that I think works for that platform. Since I can't test it, I'll need you to test and correct. I'll try to be as responsive as I can on your patches. Also, I'm only implementing Unix based platforms. I don't know Win32 well enough to even take a stab at it. So, if you want to begin the implementation of Path, Program, Signals and SysConfig, that would be WONDERFUL :) Thanks, Reid. On Tue, 2004-08-31 at 10:47, Henrik Bach wrote:> Reid, > > >As for Interix support in general, I'm having a hard time determining > >which variant of Unix Interix implements. It seems to be partially Posix > >1 and partially Posix 2 based. Do you have any further information > >related to the specific standards supported by Interix? I don't want to > >incorrectly categorize the Interix support. > > I've discussed this subject with the support staff from Interix: > http://www.interopsystems.com/tools/forum/tm.asp?m=3336&mpage=1&key=ഌ > > As I see it: Interix supports: POSIX.1, POSIX.2 and Single UNIX > Specification (SUS). > > However, the general rule is to use the define _ALL_SOURCE when compiling > the source. > > This is the behavior I've succeded with Interix till now. However, for some > header files some other defines has to be set to compile or you directly > have to manipulate the files (comment some functions). I'm working to iron > these cases out. > > > /Henrik > > _________________________________________________________________ > F alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040831/4476174b/attachment.sig>
Jeff/Vladimir: As with Interix, I've recently added support for FreeBSD into lib/System. Currently, the implementation of FreeBSD just uses the "generic Unix" implementation which probably should work on FreeBSD. If not, I would appreciate it if you could make patches in the FreeBSD directory. If you do, don't forget that you need to remove anything that doesn't work in the lib/System/Unix directory and re-implement it on all platforms. Hopefully this will help you get better FreeBSD support out of LLVM. Thanks Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040831/7ef21d6d/attachment.sig>
> As with Interix, I've recently added support for FreeBSD into > lib/System. Currently, the implementation of FreeBSD just uses the > "generic Unix" implementation which probably should work on FreeBSD.This fix problem. And more! Test result get improvment from last succesful build before (2004-08-29). Feature Test Results : Before: 112 tests total 85 ( 76%) tests as expected 2 ( 2%) tests unexpected FAIL 25 ( 22%) tests unexpected PASS After: 112 tests total 110 ( 98%) tests as expected 2 ( 2%) tests unexpected FAIL Regression Test Results Before: 869 tests total 831 ( 96%) tests as expected 5 ( 1%) tests unexpected FAIL 1 ( 0%) tests unexpected UNTESTED 32 ( 4%) tests unexpected PASS After: 869 tests total 866 (100%) tests as expected 2 ( 0%) tests unexpected FAIL 1 ( 0%) tests unexpected UNTESTED Vladimir
My experiment to build as if Linux has failed: gmake[1]: Entering directory `/usr/home/llvm/obj/tools/llvmc' Compiling ConfigLexer.cpp /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l: In function ` llvm::ConfigLexerTokens handleSubstitution(llvm::ConfigLexerTokens)': /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l:66: error: `assert' undeclared (first use this function) /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l:66: error: (Each undeclared identifier is reported only once for each function it appears in.) /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l: In function ` llvm::ConfigLexerTokens llvm::Configlex()': /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l:174: error: `assert' undeclared (first use this function) ConfigLexer.cpp: In function `int yy_get_next_buffer()': ConfigLexer.cpp:1314: error: `assert' undeclared (first use this function) ConfigLexer.cpp: In function `void yyunput(int, char*)': ConfigLexer.cpp:1533: error: `assert' undeclared (first use this function) ConfigLexer.cpp: In function `yy_buffer_state* Config_create_buffer(FILE*, int) ': ConfigLexer.cpp:1689: error: `assert' undeclared (first use this function) ConfigLexer.cpp: In function `yy_buffer_state* Config_scan_buffer(char*, unsigned int)': ConfigLexer.cpp:1810: error: `assert' undeclared (first use this function) ConfigLexer.cpp: In function `yy_buffer_state* Config_scan_bytes(const char*, int)': ConfigLexer.cpp:1864: error: `assert' undeclared (first use this function) gmake[1]: *** [/usr/home/llvm/obj/tools/llvmc/Debug/ConfigLexer.lo] Error 1 gmake[1]: Leaving directory `/usr/home/llvm/obj/tools/llvmc' gmake: *** [llvmc/.makeall] Error 2 What I don't understand is that the assert macro is used all over the place, so why is it undeclared only here? It is declared in assert.h on FreeBSD, but there is not a single include for it I can find other than lib/System/Unix/Unix.h, and I'm not using "Unix" platform. I'll start over and use Unix. It won't be until Friday before I have results. On Tue, 31 Aug 2004 11:12:49 -0700 Reid Spencer <reid at x10sys.com> wrote:> Jeff/Vladimir: > > As with Interix, I've recently added support for FreeBSD into > lib/System. Currently, the implementation of FreeBSD just uses the > "generic Unix" implementation which probably should work on FreeBSD. If > not, I would appreciate it if you could make patches in the FreeBSD > directory. If you do, don't forget that you need to remove anything that > doesn't work in the lib/System/Unix directory and re-implement it on all > platforms. > > Hopefully this will help you get better FreeBSD support out of LLVM. > > Thanks > > Reid. >
I did an update, reran configure, and got: config.status: linking ../lib/System/FreeBSD to lib/System/platform config.status: error: ../lib/System/FreeBSD: file not found I assume I should just copy the files from the Unix directory? On Tue, 31 Aug 2004 11:12:49 -0700 Reid Spencer <reid at x10sys.com> wrote:> Jeff/Vladimir: > > As with Interix, I've recently added support for FreeBSD into > lib/System. Currently, the implementation of FreeBSD just uses the > "generic Unix" implementation which probably should work on FreeBSD. If > not, I would appreciate it if you could make patches in the FreeBSD > directory. If you do, don't forget that you need to remove anything that > doesn't work in the lib/System/Unix directory and re-implement it on all > platforms. > > Hopefully this will help you get better FreeBSD support out of LLVM. > > Thanks > > Reid. >
Well, that didn't take long. "Unix" doesn't work either: gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen' Compiling AsmWriterEmitter.cpp Compiling CodeEmitterGen.cpp Compiling CodeGenTarget.cpp Compiling FileLexer.cpp Compiling FileParser.cpp Compiling InstrInfoEmitter.cpp Compiling InstrSelectorEmitter.cpp Compiling Record.cpp Compiling RegisterInfoEmitter.cpp Compiling TableGen.cpp Compiling TableGenBackend.cpp Linking tblgen debug executable (without symbols) /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function `llvm::sys::Path::is_file() const': /usr/include/c++/3.3/bits/basic_string.h:889: undefined reference to `llvm::sys::Path::is_valid() const' /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function `llvm::sys::Path::is_directory() const': /usr/include/c++/3.3/bits/basic_string.h:891: undefined reference to `llvm::sys::Path::is_valid() const' /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function `llvm::sys::Path::Path(std::string)': /usr/home/llvm/obj/lib/System/platform/Path.cpp:32: undefined reference to `llvm::sys::Path::is_valid() const' /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function `llvm::sys::Path::Path(std::string)': /usr/home/llvm/obj/lib/System/platform/Path.cpp:32: undefined reference to `llvm::sys::Path::is_valid() const' /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function `llvm::sys::Path::set_directory(std::string const&)': /usr/home/llvm/obj/lib/System/platform/Path.cpp:131: undefined reference to `llvm::sys::Path::is_valid() const' /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o):/usr/home/llvm/obj/lib/System/platform/Path.cpp:148: more undefined references to `llvm::sys::Path::is_valid() const' follow gmake[2]: *** [/usr/home/llvm/obj/tools/Debug/tblgen] Error 1 gmake[2]: Leaving directory `/usr/home/llvm/obj/utils/TableGen' On Tue, 31 Aug 2004 11:12:49 -0700 Reid Spencer <reid at x10sys.com> wrote:> Jeff/Vladimir: > > As with Interix, I've recently added support for FreeBSD into > lib/System. Currently, the implementation of FreeBSD just uses the > "generic Unix" implementation which probably should work on FreeBSD. If > not, I would appreciate it if you could make patches in the FreeBSD > directory. If you do, don't forget that you need to remove anything that > doesn't work in the lib/System/Unix directory and re-implement it on all > platforms. > > Hopefully this will help you get better FreeBSD support out of LLVM. > > Thanks > > Reid. >
Jeff & others
A couple words on how lib/System works that might help you.
1. The configure script identifies the build host and puts it in the
$build variable. We use that to determine the basic kind of
platform
and put it in a variable named $OS. The value of $OS can be: Linux,
FreeBSD, Interix, SunOS, Darwin, etc.
2. The platform name is used to create a link from
$BUILD_OBJ_ROOT/lib/System/platform to
$BUILD_SRC_ROOT/lib/System/$OS
3. All the *.cpp files in lib/System may *only* contain absolutely
pure/vanilla platform independent code and they will #include
a file of the same name in the "platform" subdirectory. For
example lib/System/Path.cpp #includes lib/System/platform/Path.cpp.
Since "platform" is a link, it will go to
lib/System/FreeBSD/Path.cpp on a FreeBSD system. This file then
contains the FreeBSD specific implementation of Path.
4. The "Unix" directory is intended to contain common/shared portions
of the implementation. It must contain only that code which is
guaranteed to work on all Unix platforms. Similarly for Win32
directory (which has no implementation yet). As time goes on we'll
create subdirectories under Unix to factor out common code by
the various standards: BSD, SUS, POSIX, SysV, etc.
Reid
On Wed, 2004-09-01 at 08:08, Jeff Cohen wrote:> The mailing list appears down right now, so I'm forwarding my recent
> submissions to you directly.
>
> ============================================================>
> My experiment to build as if Linux has failed:
>
> gmake[1]: Entering directory `/usr/home/llvm/obj/tools/llvmc'
> Compiling ConfigLexer.cpp
> /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l: In function `
> llvm::ConfigLexerTokens
handleSubstitution(llvm::ConfigLexerTokens)':
> /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l:66: error: `assert'
undeclared
> (first use this function)
> /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l:66: error: (Each undeclared
> identifier is reported only once for each function it appears in.)
> /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l: In function `
> llvm::ConfigLexerTokens llvm::Configlex()':
> /usr/home/llvm/obj/../tools/llvmc/ConfigLexer.l:174: error: `assert'
undeclared
> (first use this function)
> ConfigLexer.cpp: In function `int yy_get_next_buffer()':
> ConfigLexer.cpp:1314: error: `assert' undeclared (first use this
function)
> ConfigLexer.cpp: In function `void yyunput(int, char*)':
> ConfigLexer.cpp:1533: error: `assert' undeclared (first use this
function)
> ConfigLexer.cpp: In function `yy_buffer_state* Config_create_buffer(FILE*,
int)
> ':
> ConfigLexer.cpp:1689: error: `assert' undeclared (first use this
function)
> ConfigLexer.cpp: In function `yy_buffer_state* Config_scan_buffer(char*,
> unsigned int)':
> ConfigLexer.cpp:1810: error: `assert' undeclared (first use this
function)
> ConfigLexer.cpp: In function `yy_buffer_state* Config_scan_bytes(const
char*,
> int)':
> ConfigLexer.cpp:1864: error: `assert' undeclared (first use this
function)
> gmake[1]: *** [/usr/home/llvm/obj/tools/llvmc/Debug/ConfigLexer.lo] Error 1
> gmake[1]: Leaving directory `/usr/home/llvm/obj/tools/llvmc'
> gmake: *** [llvmc/.makeall] Error 2
>
> What I don't understand is that the assert macro is used all over the
> place, so why is it undeclared only here? It is declared in assert.h on
> FreeBSD, but there is not a single include for it I can find other than
> lib/System/Unix/Unix.h, and I'm not using "Unix" platform.
>
> I'll start over and use Unix. It won't be until Friday before I
have
> results.
>
> ============================================================>
> I did an update, reran configure, and got:
>
> config.status: linking ../lib/System/FreeBSD to lib/System/platform
> config.status: error: ../lib/System/FreeBSD: file not found
>
> I assume I should just copy the files from the Unix directory?
>
> ============================================================>
> Well, that didn't take long. "Unix" doesn't work either:
>
> gmake[2]: Entering directory `/usr/home/llvm/obj/utils/TableGen'
> Compiling AsmWriterEmitter.cpp
> Compiling CodeEmitterGen.cpp
> Compiling CodeGenTarget.cpp
> Compiling FileLexer.cpp
> Compiling FileParser.cpp
> Compiling InstrInfoEmitter.cpp
> Compiling InstrSelectorEmitter.cpp
> Compiling Record.cpp
> Compiling RegisterInfoEmitter.cpp
> Compiling TableGen.cpp
> Compiling TableGenBackend.cpp
> Linking tblgen debug executable (without symbols)
> /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function
`llvm::sys::Path::is_file() const':
> /usr/include/c++/3.3/bits/basic_string.h:889: undefined reference to
`llvm::sys::Path::is_valid() const'
> /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function
`llvm::sys::Path::is_directory() const':
> /usr/include/c++/3.3/bits/basic_string.h:891: undefined reference to
`llvm::sys::Path::is_valid() const'
> /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function
`llvm::sys::Path::Path(std::string)':
> /usr/home/llvm/obj/lib/System/platform/Path.cpp:32: undefined reference to
`llvm::sys::Path::is_valid() const'
> /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function
`llvm::sys::Path::Path(std::string)':
> /usr/home/llvm/obj/lib/System/platform/Path.cpp:32: undefined reference to
`llvm::sys::Path::is_valid() const'
> /usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o): In function
`llvm::sys::Path::set_directory(std::string const&)':
> /usr/home/llvm/obj/lib/System/platform/Path.cpp:131: undefined reference to
`llvm::sys::Path::is_valid() const'
>
/usr/home/llvm/obj/lib/Debug/libLLVMsystem.a(Path.o):/usr/home/llvm/obj/lib/System/platform/Path.cpp:148:
more undefined references to `llvm::sys::Path::is_valid() const' follow
> gmake[2]: *** [/usr/home/llvm/obj/tools/Debug/tblgen] Error 1
> gmake[2]: Leaving directory `/usr/home/llvm/obj/utils/TableGen'
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20040901/d0398925/attachment.sig>
/lib/System/platform/Path.cpp is not compilable under Cygwin (although it was motivated to be for Cygwin...): ----------------------------------- Compiling Path.cpp In file included from Path.cpp:37: platform/Path.cpp: In static member function `static llvm::sys::Path llvm::sys::Path::GetTemporaryDirectory()': platform/Path.cpp:41: error: `mkdtemp' undeclared (first use this function) ----------------------------------- The problem is probably that mkdtemp is not POSIX: https://catamaran.labs.cs.uu.nl/jira/browse/STR-134?page=all BTW, another problem I got under cygwin is absence of 'pax' utility. -- Valery
Thanks for noting it. I'll see what cygwin has to offer in this area and correct the implementation. Thanks, Reid. On Wed, 2004-09-01 at 09:11, Valery A.Khamenya wrote:> /lib/System/platform/Path.cpp is not compilable under Cygwin > (although it was motivated to be for Cygwin...): > ----------------------------------- > Compiling Path.cpp > In file included from Path.cpp:37: > platform/Path.cpp: In static member function `static llvm::sys::Path > llvm::sys::Path::GetTemporaryDirectory()': > platform/Path.cpp:41: error: `mkdtemp' undeclared (first use this function) > ----------------------------------- > > The problem is probably that mkdtemp is not POSIX: > https://catamaran.labs.cs.uu.nl/jira/browse/STR-134?page=all > > BTW, another problem I got under cygwin is absence of 'pax' > utility. > > -- > Valery > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040901/abfbef7e/attachment.sig>
Possibly Parallel Threads
- [LLVMdev] FreeBSD Support In lib/System
- [LLVMdev] FreeBSD Support In lib/System
- xapian-core-1.2.21 ported to Interix / 'gmake check' compile error
- [LLVMdev] Problem with CVS LLVM build in obj != src dir case
- [LLVMdev] Problem with CVS LLVM build in obj != src dir case