Re: [O] org-babel C math.h issue

[Thierry Banel]

To summarize this thread:
It seems there was an issue long ago.
Version 5 of GCC magically fixed it.
But it is still here for older compilers.

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

To debug, execute the following piece of lisp code:

    (defadvice org-babel-eval (before xxx (cmd body))
      ""
      (message "org-babel-eval : %s" cmd))
    (ad-activate 'org-babel-eval)

The actual compilation command will be displayed in the *Messages* buffer.

With your example, we get

   gcc -o /tmp/babel-8412zIw/C-bin-8412IZR -lm
/tmp/babel-8412zIw/C-src-84127OL.c

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

You are right, Oz, this can be fixed in line 147.
But :flags is intended for flags like -g or -O, which need to appear
before the source file.

Probably we are missing an additional flag, which could be named :libs
Then your example would be:

  #+BEGIN_SRC C :includes '(<math.h> <stdio.h>) :libs -lm
  int i=9;
  printf("%d\n",(int)sqrt(i));
  #+END_SRC

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

Oz, do you think you would be able to provide a patch?
The way to contribute is documented here:
http://orgmode.org/worg/org-contribute.html#orgheadline1

Thanks for reporting.
Thierry


Le 06/03/2016 23:44, Oz Ben-Ami a écrit :
> Hi,
>
> I'm a new org user, and I'm sorry if I'm missing something obvious.
> When executing a C code snippet with org-babel, that contains a math
> function, I get the famous "undefined reference" errors. I tried
> adding ":flags -lm", but that doesn't help. Looking at the code, it
> seems the -lm flag is inserted in the wrong place, before the source
> file. An easy change would be in line 147 of ob-C.el version
> 8.3.4-634, moving "flags" to after the source file. This seems to
> work, but I don't know if it would break anything else.
>
> A minimal working example, attached, includes the following snippet:
>
> #+BEGIN_SRC C :includes '(<math.h> <stdio.h>) :flags -lm
> int i=9;
> printf("%d\n",(int)sqrt(i));
> #+END_SRC
>
> Note the issue disappears if constants are directly used rather than
> variables, presumably because the function call is optimized away
> entirely.
>
> Any thoughts are appreciated.
>
> Oz