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

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

Thomas Pasch wrote:
> I'm willing to help. Try to fix what I can. (Do you just
> know that AMD has abolished production of AthlonXPs?)

That's great! I could really use a helping hand with that 64 bit port. 
:) If you have any diffs please send them to me at Dr.Graef (at) 
t-online.de. I think that the best thing would be to first take care of 
those pointer-related warning messages, maybe then some of the 
misbehaviour you reported (wrong module name, error loading an external 
module etc.) would go away.

No, I didn't know that the Athlon XP is discontinued. What kind of cpu 
is this anyway? The Athlon seems to be the main line of AMD processors, no?

>  > Warning: 248 unresolved external symbols
>  > ! Value mismatch in definition
> 
> What do this 2 lines say???

That's the way the interpreter complains when it can't dl-load an 
external C module, that is, a shared library with additional "primitive" 
functions, see Appendix C in the manual. Because the module couldn't be 
loaded, the external C functions in the module can't be "resolved", thus 
the error message. Actually it should display the name of the offending 
module right above this message, but the pointer to that name seems to 
be incorrect, as it's pointing to the "def" symbol, which is in the 
bytecode's static string area (all static string data in the source 
script and the standard library is stored there, including the names of 
predefined function and variable symbols, identifiers and filenames of 
modules, etc.).

If you get this when starting up the Q interpreter as is, i.e. without a 
script, then it's probably the clib module which the interpreter tries 
to load there (which is the only external module imported by the 
standard prelude), so there could be some problem with the dynamic 
module loader (libltdl, from libtool), or, more likely, the module 
filename is thrashed (which is quite probable, as the Q identifier of 
the module is wrong as well). I believe that this is related to some 
wrong pointer conversions, either in the bytecode compiler (qc) or in 
the interpreter. If *all* pointers to static strings in the bytecode 
just point to the first entry "def" (or to some other random entries), 
then the interpreter will surely be in deep trouble. ;-)

Try commenting out the "import clib;" line in prelude.q and see whether 
that message goes away. (It will then most likely bomb immediately 
afterwards, but it's a cheap way to find out whether that module 
filename in the bytecode is wrong.)

> libtool: link: `/usr/lib/libXm.la' is not a valid libtool archive
> 
> Hm, '/usr/lib/libXm.la' does NOT exist at all.

That's ok, there shouldn't be one.

> OpenDx is split in debian. Shared libs are in package libdx4:
> 
> $ dpkg -L libdx4
> [...]
> /usr/lib/libDX.so.4.0.32
> /usr/lib/libDXcallm.so.4.0.32
> /usr/lib/libDXL.so.4.0.32
> /usr/lib/libDXlite.so.4.0.32
> [...]
> /usr/lib/libDX.so.4
> /usr/lib/libDXcallm.so.4
> /usr/lib/libDXL.so.4
> /usr/lib/libDXlite.so.4
> /usr/lib/dx/lib_linux/libDX.so.4
> /usr/lib/dx/lib_linux/libDX.so.4.0.32
> /usr/lib/dx/lib_linux/libDXL.so.4
> /usr/lib/dx/lib_linux/libDXL.so.4.0.32
> /usr/lib/dx/lib_linux/libDXcallm.so.4
> /usr/lib/dx/lib_linux/libDXcallm.so.4.0.32
> /usr/lib/dx/lib_linux/libDXlite.so.4
> /usr/lib/dx/lib_linux/libDXlite.so.4.0.32
> 
> No *.la libtool stuff is part of the installation
> in debian. IMHO, libtool is doomed, and
> should never look for *.la of installed libs.

No libDXL*.la, that's ok.

But no libDXL.a? Even if you have a shared DXL library (on my system 
it's just a static one, IIRC), then there should be an import lib to 
link against. Maybe there is something like an opendx-devel package 
which needs to be installed too?

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