POSIX compliance

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=&#3340

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

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 :slight_smile:

Thanks,

Reid.

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.

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.

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'

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

/lib/System/platform/Path.cpp is not compilable under Cygwin
(although it was motivated to be for Cygwin...):

Vladimir,

That's currently 100%. We have two feature tests for packed types that
are waiting for some changes yet to be committed. There's also a couple
broken regressions right now. So you're as healthy as any other
supported platform.

:slight_smile:

Reid.

Thanks for noting it. I'll see what cygwin has to offer in this area and
correct the implementation.

Thanks,

Reid.

Thanks for noting it. I'll see what cygwin has to offer in this area and
correct the implementation.

no problem, always happy to help.
BTW, you could insert

#include <cassert>

into C section of .../llvmc/ConfigLexer.l it helps to pass compilation
ander cygwin as well