quantlib-python compile error

[Brad-11]

Hi,

I tried to compile quantlib-python (after installing quantlib), and get the
following error:

$ python setup.py build
running build
running build_py
running build_ext
building 'QuantLib._QuantLib' extension
g++ -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/local/include
-I/usr/include/python2.3 -c QuantLib/quantlib_wrap.cpp -o
build/temp.linux-i686-2.3/QuantLib/quantlib_wrap.o -Wno-unused
In file included from /usr/local/include/ql/PricingEngines/Barrier/all.hpp:24,
                 from /usr/local/include/ql/PricingEngines/all.hpp:31,
                 from /usr/local/include/ql/quantlib.hpp:41,
                 from QuantLib/quantlib_wrap.cpp:1878:
/usr/local/include/ql/PricingEngines/Barrier/analyticbarrierengine.hpp:56:
error: declaration
   does not declare anything
/usr/local/include/ql/PricingEngines/Barrier/analyticbarrierengine.hpp:56:
error: syntax
   error before `__asm__'
error: command 'g++' failed with exit status 1

I checked, on line 56 it says
Real barrier() const;

I don't understand why that's not a declaration, and what __asm__ has to do with
this. Any pointers?

Thanks,

Brad

ql and ql-python 0.3.10, gcc 3.3.6, python 2.3.5

[Dirk Eddelbuettel]

On 4 October 2005 at 18:20, Brad wrote:
| I tried to compile quantlib-python (after installing quantlib), and get the
| following error:
|
| $ python setup.py build
| running build
| running build_py
| running build_ext
| building 'QuantLib._QuantLib' extension
| g++ -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/local/include
| -I/usr/include/python2.3 -c QuantLib/quantlib_wrap.cpp -o
| build/temp.linux-i686-2.3/QuantLib/quantlib_wrap.o -Wno-unused
| In file included from /usr/local/include/ql/PricingEngines/Barrier/all.hpp:24,
|                  from /usr/local/include/ql/PricingEngines/all.hpp:31,
|                  from /usr/local/include/ql/quantlib.hpp:41,
|                  from QuantLib/quantlib_wrap.cpp:1878:
| /usr/local/include/ql/PricingEngines/Barrier/analyticbarrierengine.hpp:56:
| error: declaration
|    does not declare anything
| /usr/local/include/ql/PricingEngines/Barrier/analyticbarrierengine.hpp:56:
| error: syntax
|    error before `__asm__'
| error: command 'g++' failed with exit status 1
|
| I checked, on line 56 it says
| Real barrier() const;
|
| I don't understand why that's not a declaration, and what __asm__ has to do with
| this. Any pointers?
[...]
| ql and ql-python 0.3.10, gcc 3.3.6, python 2.3.5

Can you try gcc 3.4.* or 4.0.*?  Works for the Debian packages I maintain ...

Dirk

--
Statistics: The (futile) attempt to offer certainty about uncertainty.
         -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'

[Brad-11]

Dirk Eddelbuettel <edd <at> debian.org> writes:
>
> Can you try gcc 3.4.* or 4.0.*?  Works for the Debian packages I maintain ...
>
I get a slightly different error message with gcc 3.4.4:
$ python setup.py build
running build
running build_py
running build_ext
building 'QuantLib._QuantLib' extension
g++ -fno-strict-aliasing -DNDEBUG -fPIC -I/usr/local/include
-I/usr/include/python2.3 -c QuantLib/quantlib_wrap.cpp -o
build/temp.linux-i686-2.3/QuantLib/quantlib_wrap.o -Wno-unused
In file included from /usr/local/include/ql/PricingEngines/Barrier/all.hpp:24,
                 from /usr/local/include/ql/PricingEngines/all.hpp:31,
                 from /usr/local/include/ql/quantlib.hpp:41,
                 from QuantLib/quantlib_wrap.cpp:1136:
/usr/local/include/ql/PricingEngines/Barrier/analyticbarrierengine.hpp:56:
error: expected unqualified-id before "asm"
error: command 'g++' failed with exit status 1

As you can see, it still fails. I thought about where the "asm" comes from, and
thought that maybe it is something to do with the preprocessing. So I ran the
above g++ line, but with -E instead of -c.

It seems that this is the offending bit:
        Volatility volatility() const;
        Real __asm__ __volatile__ ("" : : : "memory") const;
        Real rebate() const;

Unfortunately, I have no idea why the preprocessor inserts that bit there. Is
"barrier()" a macro somewhere?

What do you think?

Brad

[Luigi Ballabio]

On 10/05/2005 05:35:03 PM, Brad wrote:

>
> ... I thought about where the "asm" comes from, and
> thought that maybe it is something to do with the preprocessing. So I
> ran the above g++ line, but with -E instead of -c.
>
> It seems that this is the offending bit:
>         Volatility volatility() const;
>         Real __asm__ __volatile__ ("" : : : "memory") const;
>         Real rebate() const;
>
> Unfortunately, I have no idea why the preprocessor inserts that bit
> there. Is "barrier()" a macro somewhere?

Google suggests that it's a macro in the Linux kernel source. Why it  
gets included beats me. Why the kernel developers don't know better  
than defining macros with such generic names is beyond my wits.

Ranting aside, try modifying the source and adding

#ifdef barrier
#undef barrier
#endif

before the class is parsed.

Later,
        Luigi


----------------------------------------

The nice thing about standards is that there are so many of them to
choose from.
-- Andrew S. Tanenbaum

[Brad-11]

I think I found the offending header that defines a barrier() macro:

This problem appears to be one of the kernel headers of the kernel that I am usi
ng (2.6.12-gentoo-r10, although it is also in the plain vanilla kernel.org
2.6.12.5):

in /usr/include/linux/compiler-gcc.h:
[...]
/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")
[...]

This obviously destroys the following declaration:
Real barrier() const;

This isn't really a quantlib-python issue, it is a quantlib/ kernel/ gcc issue,
I guess.

Any ideas as to how I could get around this?

Brad

[Brad-11]

Thanks, I tried putting the #undef just in front of the #include statement that
pulled in the file with the "Real barrier() const;" declaration, and put the
macro back in directly after that.

Here is a diff in case anyone else runs into this problem.
1878,1880d1877
< #ifdef barrier
< #undef barrier
< #endif
1882d1878
< #define barrier() __asm__ __volatile__("": : :"memory"

The unit tests (python setup.py test) hang after testing build_ext, but maybe
that's an unrelated problem.

Maybe someone wants to file a bug/ complaint with the kernel developers for
choosing a pretty bad name for a macro.

[Dirk Eddelbuettel]

On 5 October 2005 at 16:57, Brad wrote:
| Thanks, I tried putting the #undef just in front of the #include statement that
| pulled in the file with the "Real barrier() const;" declaration, and put the
| macro back in directly after that.
|
| Here is a diff in case anyone else runs into this problem.
| 1878,1880d1877
| < #ifdef barrier
| < #undef barrier
| < #endif
| 1882d1878
| < #define barrier() __asm__ __volatile__("": : :"memory"

How do you end up with the include but nobody else does? Can you backtrack
and see who calls what to end up with it?  If it is an internal header file
for the kernel then there is no point including it ...

| The unit tests (python setup.py test) hang after testing build_ext, but maybe
| that's an unrelated problem.

I had that for a while on Debian often need to disable TermStructureTest and
InstrumentTest in tests/QuantLibTestSuite.py.  

Hth, Dirk

--
Statistics: The (futile) attempt to offer certainty about uncertainty.
         -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'

[Brad-11]

Dirk Eddelbuettel <edd <at> debian.org> writes:
>
> How do you end up with the include but nobody else does? Can you backtrack
> and see who calls what to end up with it?  If it is an internal header file
> for the kernel then there is no point including it ...
Ok, I tried to see how compiler-gcc.h gets included. Here it is:

/usr/include/python2.3/Python.h includes
 /usr/include/pth.h includes
  /usr/include/sys/signal.h includes
   /usr/include/signal.h includes
    /usr/include/bits/sigcontext.h includes
     /usr/include/asm/sigcontext.h includes
      /usr/include/linux/compiler.h includes
       /usr/include/linux/compiler-gcc3.h includes
        /usr/include/linux/compiler-gcc.h

Hope this helps. That last one is the one with the offending macro in it.

> | The unit tests (python setup.py test) hang after testing build_ext, but
> | maybe that's an unrelated problem.
Just for the record: This problem was totally unrelated. The problem was between
keyboard and chair for that one... I am too embarrassed to talk about it. The
unit tests run fine now.

[Luigi Ballabio]

On 10/06/2005 11:24:36 AM, Brad wrote:

> Ok, I tried to see how compiler-gcc.h gets included. Here it is:
>
> /usr/include/python2.3/Python.h includes
>  /usr/include/pth.h includes
>   /usr/include/sys/signal.h includes
>    /usr/include/signal.h includes
>     /usr/include/bits/sigcontext.h includes
>      /usr/include/asm/sigcontext.h includes
>       /usr/include/linux/compiler.h includes
>        /usr/include/linux/compiler-gcc3.h includes
>         /usr/include/linux/compiler-gcc.h
>
> Hope this helps. That last one is the one with the offending macro in
> it.

Ok, I just added the #undef code to the interfaces.

Thanks,
        Luigi

----------------------------------------

Weiler's Law:
         Nothing is impossible for the man who doesn't have to
         do it himself.

[Yi Zhao-2]

I am trying to build quantlib-python in cygwin.
Can anyone tell me how to disable the debug flag "-g" in the setup.py??
Thanks a lot!

> -----Original Message-----
> From: Brad [mailto:[hidden email]]
> Sent: Wednesday, October 05, 2005 11:58 AM
> To: [hidden email]
> Subject: [Quantlib-users] Re: quantlib-python compile error
>
>
> Thanks, I tried putting the #undef just in front of the
> #include statement that pulled in the file with the "Real
> barrier() const;" declaration, and put the macro back in
> directly after that.
>
> Here is a diff in case anyone else runs into this problem.
> 1878,1880d1877 < #ifdef barrier < #undef barrier < #endif
> 1882d1878 < #define barrier() __asm__ __volatile__("": : :"memory"
>
> The unit tests (python setup.py test) hang after testing
> build_ext, but maybe that's an unrelated problem.
>
> Maybe someone wants to file a bug/ complaint with the kernel
> developers for choosing a pretty bad name for a macro.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Quantlib-users mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Luigi Ballabio]

On 10/06/2005 10:15:57 PM, Yi Zhao wrote:
> I am trying to build quantlib-python in cygwin.
> Can anyone tell me how to disable the debug flag "-g" in the
> setup.py??

Unfortunately, distutils inherits that flag from Python---in order to  
ensure compatibility, it tries to make sure extensions are compiled  
with the same flags used to compile Python.
The only way I found was to modify the Makefile used for Python, which  
distutils read---mine is in /usr/lib/python2.3/config/Makefile, but its  
location might change under Cygwin.

Later,
        Luigi

----------------------------------------

Though this be madness, yet there is method in't.
-- Hamlet, Act II, scene II