Re: [q-lang-users] Build problems with q-6.0

[Albert G. <Dr....@t-...>]

Thomas Pasch wrote:
> I report this hier because the bug tracking page at
> sourceforge seems not to be use by this project.

It's supposed to work, but noone has actually entered anything there yet.

> There are some glitches with building q-6.0. On my
> AthlonXp Debian testing system, it is not possible
> to build the opendx (dxl) extension. This is the
> error
> 
> make[4]: Entering directory `/home/tpasch/compile/q-6.0/modules/dxl'
> /bin/sh ../../libtool --mode=link --tag=CC gcc-3.4  -O3 -o dxl.la -rpath 
> /opt/lib/q
> -no-undefined -module -avoid-version dxl.lo ../../libq/libq.la -lDXL  
> -lcrypt -lutil -lnsl -lm
> grep: /usr/lib/libXm.la: No such file or directory
> /bin/sed: can't read /usr/lib/libXm.la: No such file or directory
> libtool: link: `/usr/lib/libXm.la' is not a valid libtool archive
> make[4]: *** [dxl.la] Fehler 1

Hmm, it shouldn't need libXm.la... Wait, I vaguely remember some probs 
with the .la's from the OpenDX libraries. Can you please check whether 
your .../dx/lib_linux directory contains some .la files? If so, try 
moving those temporarily to a directory where libtool won't find them.

> The libtool tries to build static libraries a (even with 
> --disable-static configure
> option!).

I'll have to recheck this, last time I checked --disable-static worked, 
but I've upgraded to a newer libtool since then.

> In addition I think the state of q-6.0 on AMD64 (aka x86_64) is dubious
> at best.

That's true, as I don't have a 64 bit system yet, Q has never been 
tested there before, so there surely are some 64 bit related glitches. 
Your input (preferably patches ;-) would be very valuable! But as I 
cannot test this here, right now you're on your own. :( (Unless someone 
else on this list can help. Anyone?)

> Building opendx-4.3.2 (dxl) extension does not work (no surprise):
> [...]
> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: 
> /usr/dx/lib_linux/libDXL.a(close.o): relocation R_X86_64_32 against `a 
> local symbol' can not be used when making a shared object; recompile 
> with -fPIC
> /usr/dx/lib_linux/libDXL.a(close.o): could not read symbols: Bad value
> collect2: ld returned 1 exit status

Mmh, could that be a libtool bug?

> Building the ImageMagick extension also fails. This is perhaps
> because I'm using a very recent version (6.1.8.8) on AMD64:

Yep, support for ImageMagick 6.x is still on my TODO list. That error is 
probably easy to fix, though. If you can live without that specific 
function, a quick workaround would be to just comment out the stuff 
around the call to GetColorList in magick.c and make the wrapper 
function return __FAIL instead.

> Without this extensions, I managed to build q-6.0. But the
> build failes with:
> 
> PATH=.:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3:/opt/blackdown-jdk-1.4.2/bin:/opt/blackdown-jdk-1.4.2/jre/bin:/usr/qt/3/bin:/usr/kde/3.3/bin:/usr/kde/3.2/bin:/usr/kde/3.1/bin:/usr/games/bin 
> QPATH=../stdlib:../modules/clib:../modules/clib q ./qcwrap.q ./qcwrap.q
> def: error loading module

That looks rather severe. There's no module named "def", "def" just 
happens to be the first symbol in the symbol table, IIRC. So it looks 
like the bytecode compiler generated bogus code. My guess is that some 
pointers in the compiler's symbol table get trashed during pointer 
arithmetic. Maybe it's just a few long long casts that's needed... 
Sorry, I'd need a 64 bit machine, a complete build log, gdb and a big 
can of coffee to find out about this one. ;-)

> Trying to invoke the (partly) build q I got:

Yep, that's the same error.

> regex.c: In function `xxre_match_2':

I don't know whether the bundled version of GNU regex has ever been 
tested on a 64 bit system. Probably not. It should be easy to replace it 
with a more current 64-bit safe version, though.

> odbc.c: In function `__F__odbc_sql_exec':
> odbc.c:610: warning: passing arg 10 of `SQLBindParameter' from 
> incompatible pointer type
> qmfuns.c: In function `ptr_hash':
> qmfuns.c:1974: warning: cast from pointer to integer of different size
> qmfuns.c: In function `ptr_hash':
> qmfuns.c:1974: warning: cast from pointer to integer of different size
> libtool: link: warning: `-dlopen self' is ignored for libtool libraries
> qmfuns.c: In function `ptr_hash':
> qmfuns.c:1974: warning: cast from pointer to integer of different size
> libtool: link: warning: `-dlopen self' is ignored for libtool libraries
> qmfuns.c: In function `ptr_hash':
> qmfuns.c:1974: warning: cast from pointer to integer of different size

More of the same. Most of this should be fairly easy to fix. Sigh. Looks 
like I'll have to buy a 64 bit machine after all. Maybe I should enable 
the "Donate" button on SF. :)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag