that "we" in your post should mean the bluesky community,in my opinion, or under the rules Apache that determines whether stlport can be imported in our project.
ps:i find that our teammates still misunderstand about how to work here.There are too many preliminary things we haven't done well yet.I feel relieved that Apache community shows such a great tolerance and so much patience.It would be a SHAME if we did't work hard to make this project successful. 2008/9/9 chen hecky <[EMAIL PROTECTED]> > So, is it that we should determine STLport is ASL or not at first ? Or > what > is the license of stlport on earth? > > 2008/9/9 Samul Kevin <[EMAIL PROTECTED]> > > > I remembered that there is a host.h file which lots of configure > sentences > > are included in.Check it out and you may find something > > > > plus,we still don't solve the "license" problem of stlport, should we > use > > it in such a hurry? > > > > 2008/9/8 chen hecky <[EMAIL PROTECTED]> > > > > > Hi, everyone! > > > > > > As far as I know, STLport is not in conflict with ASL, it could be > > ASL.(Am > > > I > > > right?) We can replace the C++ lib(GPL) by using STLport. But it links > to > > > C++ lib in some code of STLport when we compile our code of Bluesky. > Such > > > as > > > : > > > . adminserver.h > > > .. /usr/include/stlport/list > > > ... /usr/include/stlport/stl/_prolog.h > > > ... /usr/include/stlport/stl/_list.h > > > .... /usr/include/stlport/stl/_algobase.h > > > ..... /usr/include/stlport/cstddef > > > ...... /usr/include/c++/3.4/cstddef > > > ....... /usr/include/stlport/stddef.h > > > ........ /usr/lib/gcc/i486-linux-gnu/3.4.6/include/../include/stddef.h > > > ..... /usr/include/stlport/cstring > > > ...... /usr/include/c++/3.4/cstring > > > ....... /usr/include/stlport/string.h > > > ...... /usr/include/stlport/using/cstring > > > ..... /usr/include/stlport/climits > > > ...... /usr/include/c++/3.4/climits > > > ....... /usr/lib/gcc/i486-linux-gnu/3.4.6/include/limits.h > > > ..... /usr/include/stlport/cstdlib > > > ...... /usr/include/c++/3.4/cstdlib > > > ....... /usr/include/c++/3.4/i486-linux-gnu/bits/c++config.h > > > ........ /usr/include/c++/3.4/i486-linux-gnu/bits/os_defines.h > > > ....... /usr/include/stlport/stdlib.h > > > ........ /usr/include/../include/stdlib.h > > > ......... /usr/include/stlport/stddef.h > > > .......... > /usr/lib/gcc/i486-linux-gnu/3.4.6/include/../include/stddef.h > > > ......... /usr/include/bits/waitflags.h > > > ......... /usr/include/bits/waitstatus.h > > > ......... /usr/include/alloca.h > > > > > > > > > We are puzzling about it at first. After checked the code of the > STLport, > > > we > > > find that it is linking to C++ lib in some code of STLport. Such as: > > > In cstddef of stlport: > > > > > > # if (__GNUC__ >= 3) && defined(__CYGWIN__) // this total HACK is the > > only > > > expedient way I could cygwin to work with GCC 3.0 > > > # define __need_wint_t // mostly because wint_t didn't seem to get > > defined > > > otherwise :( > > > # define __need_wchar_t > > > # define __need_size_t > > > # define __need_ptrdiff_t > > > # define __need_NULL > > > # endif > > > # if defined (_STLP_USE_NEW_C_HEADERS) > > > # include _STLP_NATIVE_CPP_C_HEADER(cstddef) // I think it must link > to > > > cstdd of C++ from here. ------> ...... /usr/include/c++/3.4/cstddef > > > # else > > > # include _STLP_NATIVE_C_HEADER(stddef.h) > > > # endif > > > # ifdef _STLP_IMPORT_VENDOR_CSTD > > > _STLP_BEGIN_NAMESPACE > > > using _STLP_VENDOR_CSTD::ptrdiff_t; > > > using _STLP_VENDOR_CSTD::size_t; > > > _STLP_END_NAMESPACE > > > #endif /* _STLP_IMPORT_VENDOR_CSTD */ > > > > > > > > > > > > So, we must make our code be ASL, does it matter linking to C++(GPL) in > > > STLport? Or how can we do to escape linking to C++? > > > > > > Thanks! > > > > > > > > > > > -- > > Bowen Ma a.k.a Samul Kevin @ Bluesky Dev Team XJTU > > > -- Bowen Ma a.k.a Samul Kevin @ Bluesky Dev Team XJTU
