Re: Development branch mkoctfile missing compiler and linker options?

[Jarno Rajahalme]

On May 3, 2010, at 10:46 AM, ext John W. Eaton wrote:

> On  3-May-2010, Jarno Rajahalme wrote:
> 
> | -D_THREAD_SAFE
> | -pthread
> 
> Please remind me why/how -pthread is added to the options?  In what
> variable does it appear in Octave's generated Makefiles?

These options are generated by ./configure. -pthread is one of the options 
./configure tries out for pthreads support. Here is a related patch that is 
currently needed for Octave to compile in OSX:

diff -r ec3cec8277df m4/acx_pthread.m4
--- a/m4/acx_pthread.m4 Wed Apr 28 01:41:22 2010 -0400
+++ b/m4/acx_pthread.m4 Mon May 03 10:51:07 2010 -0700
@@ -149,6 +149,10 @@
 
         acx_pthread_flags="-pthreads pthread -mt -pthread $acx_pthread_flags"
         ;;
+
+       *-darwin*)
+       acx_pthread_flags="-pthread"
+       ;;
 esac
 
 if test x"$acx_pthread_ok" = xno; then


Other build environments can have other ./configure results (i.e. "-pthreads" 
or "-mt").

./configure adds "-D_THREAD_SAFE". It is actually this define which, if 
missing, causes the compile failure on OSX. AFAIK Octave does not need 
pthreads, but this define is needed to avoid a compile error in one of the 
headers.

In my current config.status:

$ grep "\-pthread" config.status
CFLAGS='-O3 -m64 -I/Users/Shared/Development/include -I/opt/local/include 
-D_THREAD_SAFE -pthread -fopenmp'
LTCFLAGS='-O3 -m64 -I/Users/Shared/Development/include -I/opt/local/include 
-D_THREAD_SAFE -pthread -fopenmp'
S["PTHREAD_CFLAGS"]="-D_THREAD_SAFE -pthread"
S["CFLAGS"]="-O3 -m64 -I/Users/Shared/Development/include -I/opt/local/include 
-D_THREAD_SAFE -pthread -fopenmp"

> | -DPIC
> | -fno-common
> 
> Likewise for this one.  Where does it come from and what is it for?

These are compiler options for creating position independent code, so that a 
library can be placed in an arbitrary memory location without  relinking it's 
internal references. ./configure or libtool defines these.

in my current config.status:

$ grep "\-DPIC" config.status
lt_prog_compiler_pic=' -fno-common -DPIC'
lt_prog_compiler_pic_CXX=' -fno-common -DPIC'


> 
> | -I/Users/Shared/Development/octave/libgnu
> | -L/Users/Shared/Development/octave/libgnu
> 
> I can see that there could be trouble if Octave header files include
> other headers that might be replaced by gnulib.  In what cases does
> that happen?
> 

I noticed earlier that gnulib re-defines int64_t, among other things, if 
stdint.h needs to be replaced (which is true for OSX with GCC 4.4 or earlier). 
This leads to link failures on GCC 4.3 or earlier, as the C++ name mangling 
changes due to the redefinition. Similar problems are possible also on other 
platforms than OSX.

So, I don't know what would break if GNUlib includes were not used. Maybe 
should try to build all DLDs of Octave without gnulib and see what happens?

  Jarno