> There are a number of things that seem incorrect in
> this post.
Well, let's see if we can correct them...
gzip -dc PyLucene-2.2.0-2-src-jcc.tar.gz | tar xf -
tar: ././@LongLink: typeflag 'L' not recognized, converting to regular file
tar: ././@LongLink: typeflag 'L' not recognized, converting to regular file
Oops, GNU tar was used. Unfortunate, since GNU tar does not properly handle
archiving, and on top of that, apparently doesn't write System V compliant tar
archives.
Can this please be fixed?
Moving right along...
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2] 4> setenv CC cc
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2] 4> setenv CXX CC
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2] 4> find . -depth -type f
-print | xargs grep errno
Errno does not seem to be used, so we'll use -xbuiltin=%all...
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2] 4> setenv CFLAGS "-xO4
-xprefetch=auto -xbuiltin=%all -m64 -xarch=generic -xtarget=generic
-xchip=generic"
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2] 4> setenv CXXFLAGS
"$CFLAGS"
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2] 4> cd jcc/
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2/jcc] 4> [EMAIL
PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2/jcc] 4> python setup.py build
Traceback (most recent call last):
File "setup.py", line 131, in <module>
main()
File "setup.py", line 62, in main
_includes = INCLUDES[sys.platform]
KeyError: 'sunos5'
Well, looks like "setup.py" is broken. BTW, why wasn't a good old fashioned
System V Makefile used? Anyways, let's see if we can fix that...
The relevant lines seem to be these:
INCLUDES = {
'darwin':
['/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers'],
'linux2': ['/usr/lib/jvm/java-6-sun/include',
'/usr/lib/jvm/java-6-sun/include/linux'],
'win32': ['o:/Java/jdk1.6.0_02/include',
'o:/Java/jdk1.6.0_02/include/win32'],
}
As the system seems to expect "sunos5", we mimic the previous entries thus:
INCLUDES = {
'darwin':
['/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers'],
'linux2': ['/usr/lib/jvm/java-6-sun/include',
'/usr/lib/jvm/java-6-sun/include/linux'],
'win32': ['o:/Java/jdk1.6.0_02/include',
'o:/Java/jdk1.6.0_02/include/win32'],
'sunos5': ['/usr/java/include',
'/usr/java/include/solaris'],
}
And these:
LFLAGS = {
'darwin': ['-framework', 'JavaVM'],
'linux2': ['-L/usr/lib/jvm/java-6-sun/jre/lib/i386', '-ljava',
'-Wl,-rpath=/usr/lib/jvm/java-6-sun/jre/lib/i386:/usr/lib/jvm/java-6-sun/jre/lib/i386/client'],
# 'linux2': ['-L/usr/lib/jvm/java-6-sun/jre/lib/amd64', '-ljava',
#
'-Wl,-rpath=/usr/lib/jvm/java-6-sun/jre/lib/amd64:/usr/lib/jvm/java-6-sun/jre/lib/amd64/server'],
'win32': ['/LIBPATH:o:/Java/jdk1.6.0_02/lib', 'jvm.lib']
}
Hmmm, "-Wl" is a compiler switch which passes the options to the link editor,
ld(1), and drives the link editor via the compiler front end (clever, clever!)
The only problem is, a standard system V link editor does not use "-rpath", not
on Solaris, not on HP-UX, and not on IRIX. Luckily, we can add a hook, but this
choice, although clever, is rather unfortunate.
The clean way to do this would have been to specify "-L/bla/blabla/lib
-R/bla/blabla/lib" in the $CFLAGS and $CXXFLAGS, but seeing as to how no .so's
seem to be in /usr/java/lib/ (on Solaris at least), one is left wondering as to
where that path should point to... regardless:
LFLAGS = {
'darwin': ['-framework', 'JavaVM'],
'linux2': ['-L/usr/lib/jvm/java-6-sun/jre/lib/i386', '-ljava',
'-Wl,-rpath=/usr/lib/jvm/java-6-sun/jre/lib/i386:/usr/lib/jvm/java-6-sun/jre/lib/i386/client'],
# 'linux2': ['-L/usr/lib/jvm/java-6-sun/jre/lib/amd64', '-ljava',
#
'-Wl,-rpath=/usr/lib/jvm/java-6-sun/jre/lib/amd64:/usr/lib/jvm/java-6-sun/jre/lib/amd64/server'],
'win32': ['/LIBPATH:o:/Java/jdk1.6.0_02/lib', 'jvm.lib'],
'sunos5': ['-L/usr/jdk/latest/jre/lib/sparcv9
-R/usr/jdk/latest/jre/lib/sparcv9', '-ljava',
'-Wl,-R/usr/jdk/latest/jre/lib/sparcv9']
}
...and let's hope that's what's actually expected, since I didn't see it
documented anywhere, what exactly should be linked against.
Let's give it another shot...
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2/jcc] 4> python setup.py
build
running build
running build_py
creating build
creating build/lib.solaris-2.10-sun4u-2.5
creating build/lib.solaris-2.10-sun4u-2.5/jcc
copying jcc/__init__.py -> build/lib.solaris-2.10-sun4u-2.5/jcc
copying jcc/cpp.py -> build/lib.solaris-2.10-sun4u-2.5/jcc
copying jcc/python.py -> build/lib.solaris-2.10-sun4u-2.5/jcc
copying jcc/config.py -> build/lib.solaris-2.10-sun4u-2.5/jcc
creating build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/functions.cpp ->
build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/jcc.cpp -> build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/JCCEnv.cpp -> build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/JObject.cpp -> build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/functions.h -> build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/JArray.h -> build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/JCCEnv.h -> build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/JObject.h -> build/lib.solaris-2.10-sun4u-2.5/jcc/sources
copying jcc/sources/macros.h -> build/lib.solaris-2.10-sun4u-2.5/jcc/sources
running build_ext
building 'jcc._jcc' extension
creating build/temp.solaris-2.10-sun4u-2.5
creating build/temp.solaris-2.10-sun4u-2.5/jcc
creating build/temp.solaris-2.10-sun4u-2.5/jcc/sources
creating build/temp.solaris-2.10-sun4u-2.5/_jcc
creating build/temp.solaris-2.10-sun4u-2.5/_jcc/java
creating build/temp.solaris-2.10-sun4u-2.5/_jcc/java/lang
creating build/temp.solaris-2.10-sun4u-2.5/_jcc/java/lang/reflect
creating build/temp.solaris-2.10-sun4u-2.5/_jcc/java/util
cc -DNDEBUG -xO4 -xprefetch=auto -xarch=generic -xchip=generic -xtarget=generic
-xO4 -xprefetch=auto -xbuiltin=%all -m64 -xarch=generic -xtarget=generic
-xchip=generic -xcode=pic32 -I/usr/java/include -I/usr/java/include/solaris
-I_jcc -Ijcc/sources -I/opt/blablabla/include/python2.5 -c jcc/sources/jcc.cpp
-o build/temp.solaris-2.10-sun4u-2.5/jcc/sources/jcc.o -DPYTHON
cc: No input file specified, no output generated
error: command 'cc' failed with exit status 1
Ah, there it is, trying to compile C++ code with a C compiler. Hm. But where
does that come from?
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2/jcc] 4> find
/opt/blablabla/ -depth -type f -print | xargs grep "\-xcode=pic32"
/opt/blablabla/lib/python2.5/config/Makefile:CCSHARED= -xcode=pic32
Well, that looks like a winner. The relevant fragments seem to be:
CC= cc
CXX= CC
MAINCC= CC $(OPT)
LINKCC= $(PURIFY) $(MAINCC)
...
CCSHARED= -xcode=pic32
...But that all looks OK.
So, the winning question is, what's busted?
Be that as it may, I'll play along, although I shouldn't even have to be doing
this:
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2/jcc] 5> setenv CC CC
> Is that so ? PyLucene's C++ code is vanilla enough to
> compile with gcc everywhere and with Microsoft's VC++
> on Windows with very little conditional code. Can you
> be more specific as to how PyLucene's C++ code is
> incompatible with Sun Studio C++ ?
It certainly seems to be:
[EMAIL PROTECTED]/devel/src/PyLucene/PyLucene-2.2.0-2/jcc] 5> python setup.py
build
running build
running build_py
copying jcc/config.py -> build/lib.solaris-2.10-sun4u-2.5/jcc
running build_ext
building 'jcc._jcc' extension
CC -DNDEBUG -xO4 -xprefetch=auto -xarch=generic -xchip=generic -xtarget=generic
-xcode=pic32 -I/usr/java/include -I/usr/java/include/solaris -I_jcc
-Ijcc/sources -I/opt/blablabla/include/python2.5 -c jcc/sources/jcc.cpp -o
build/temp.solaris-2.10-sun4u-2.5/jcc/sources/jcc.o -DPYTHON
"/opt/blablabla/include/python2.5/pyconfig.h", line 917: Warning (Anachronism):
Attempt to redefine _FILE_OFFSET_BITS without using #undef.
"jcc/sources/JCCEnv.h", line 85: Warning: throwable hides
JCCEnv::exception::throwable.
"jcc/sources/JCCEnv.h", line 94: Warning: throwable hides
JCCEnv::pythonError::throwable.
"jcc/sources/JObject.h", line 32: Error: A declaration does not specify a tag
or an identifier.
"jcc/sources/JObject.h", line 32: Error: Use ";" to terminate declarations.
"jcc/sources/JObject.h", line 32: Error: "}" expected instead of "this".
"jcc/sources/JObject.h", line 32: Error: Use ";" to terminate declarations.
"jcc/sources/JObject.h", line 32: Error: A declaration was expected instead of
"this".
"jcc/sources/JObject.h", line 35: Error: "explicit" is not allowed here.
"jcc/sources/JObject.h", line 35: Error: No direct declarator preceding "(".
"jcc/sources/JObject.h", line 38: Error: env, of type int, was previously
declared JCCEnv*.
"jcc/sources/JObject.h", line 38: Error: "," expected instead of "->".
"jcc/sources/JObject.h", line 39: Error: A declaration was expected instead of
"}".
"jcc/sources/JObject.h", line 41: Error: No direct declarator preceding "(".
"jcc/sources/JObject.h", line 44: Error: Multiple declaration for env.
"jcc/sources/JObject.h", line 44: Error: "," expected instead of "->".
"jcc/sources/JObject.h", line 44: Error: Use ";" to terminate declarations.
"jcc/sources/JObject.h", line 44: Error: A declaration was expected instead of
",".
"jcc/sources/JObject.h", line 44: Error: Multiple declaration for id.
"jcc/sources/JObject.h", line 44: Error: "," expected instead of ")".
"jcc/sources/JObject.h", line 45: Error: A declaration was expected instead of
"}".
"jcc/sources/JObject.h", line 47: Error: "virtual" is not allowed here.
"jcc/sources/JObject.h", line 48: Error: Illegal number of arguments for ~file
level().
"jcc/sources/JObject.h", line 49: Error: Can only use this within a non-static
member function.
"jcc/sources/JObject.h", line 49: Error: Use ";" to terminate statements.
"jcc/sources/JObject.h", line 49: Error: "}" expected instead of "$".
"jcc/sources/JObject.h", line 52: Error: "virtual" is not allowed here.
"jcc/sources/JObject.h", line 53: Error: The function "isNull() const" cannot
be declared const.
Compilation aborted, too many Error messages.
error: command 'CC' failed with exit status 1
> PyLucene does not invoke gcc or any compiler itself.
> Like I said above, PyLucene relies on
> Python/distutils to invoke the compiler. If Python
> was built with Sun Studio, I expect Python to build
> PyLucene with Sun Studio as well with all the
> switches it normally uses to build any other Python
> extension. JCC is a regular Python extension. There
> is nothing special about building its C++ code other
> than entering the correct paths to the JDK's JNI
> headers and libraries.
Apparently, the Python's build system isn't all that it's cracked up to be.
The point is this though:
- assumptions were made, where they didn't have to be
- developer(s) of PyLucene are relying on a non-standard, I'd say even exotic,
build system (Python), instead of using proven, robust tools like make(1).
> The bottom line is that PyLucene has never been built
> on Solaris (at least not with Sun Studio C++) and
> that someone with access to that OS and its native
> compiler needs to do a quick port. I expect this port
> to be very easy since Sun Studio would then be the
> third compiler in use after gcc and msvc. The port to
> msvc took all of one hour.
Why "someone"? Why not you? Solaris is freeware, opensource, and easily
installable on the i86pc platform, including an intel Mac.
> If someone does this port and submits a patch, I'll
> be glad to incorporate it into the PyLucene/JCC svn.
See all the detective work I had to do, above? Hey, I don't even have anything
to do with Python, Lucene, or PyLucene. All I tried to do was help someone
figure out why they were busted.
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
