Hi! Just a quick update. As a final attempt, before I implemented Martin's suggestion, I chaged the order of the includes. Having Python.h last in the includes, solved everything (apart from a warning, about _FILE_OFFSET_BITS being redefined. If it's already defined by the OS, does pyconfig.h have to define it?). Is there somewhere to log things such as this? Does it warrant a bug report? Regards John Martin v. Löwis wrote: >John Abel <johnfabel@btinternet.com> writes: > > > >>Is there a way, to tell Python to compile a module in 32bit mode? >> >> > >You could edit pyconfig.h after configuring but before compiling >Python. I would advise against doing so. > > > >>Or, is there a workaround for this Solaris oddity? >> >> > >You could split your code into two files, with LFS-independent data >structures in-between them. IOW, define JA_psinfo_t, which has just >the fields of psinfo_t that you are interested in, using >LFS-independent data types. In the source file opening /proc, copy all >interesting fields in the data structure pointed-to by the caller, and >compile this without LFS. Then, in the Python module proper, call >these helper functions, passing JA_psinfo_t. > >AFAICT, it is only priovec_t, anyway, which is affected by the >incompatibility, so if you don't use that, you could just pass >psinfo_t through. I might be wrong here, though. > >Regards, >Martin > > >_______________________________________________ >Python-Dev mailing list >Python-Dev@python.org >http://mail.python.org/mailman/listinfo/python-dev > > >
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4