autoconf/configure-based linkage/include paths.

[Keith Kyzivat]

Keith Kyzivat wrote:

> Ok, this is driving me nuts.
>
> I've got a package (Konq/E) that I've been working on, fixed or 
> stubbed all the current bugs, and now I'm down at the linking stage.
> I get errors trying to link to the host's libraries (/usr/lib/...), 
> that they aren't the right endianness, etc... typical 
> couldn't-find-target-libraries error.
>
> I've done this quite a few times before with other packages, and know 
> that there is some finagling to let configure know what include and 
> library paths to use.
>
> 1.) prefix refers to a place in which $prefix/lib has libraries for 
> the target platform
> 2.) ditto for buildprefix
> 3.) I also pass --with-extra-libs pointing to a place with the 
> libraries for the target platform reside.
>
> What am I doing wrong?
> Can someone give me a list of all the various ways,places, etc that 
> autoconf/configure looks for using include paths?
>
> Oh, and I do indeed see a correct -L argument to the failing g++ 
> command...  Someone mentioned that it might have something to do with 
> the libtool archive files.  Can someone explain this to me? 


Ok.  I have fixed the problem.  It has to do with libtool having a 
hardwired lib search path of /lib /usr/lib and /usr/local/lib,
which in the cross-compile case, is incorrect.  I modified the generated 
libtool script contained in the project dir,
modifying the sys_lib_search_path_spec so it contained *only* the 
target's lib dirs.  note that this gets defined twice in the library
for some reason. 

To top things off, and make sure there weren't any collisions, I took 
out all the *.la files in lib folders around my system (I stored them in 
a backup heirarchy).

Cleaned and rebuilt, and voila, things link properly.

~Keith Kyzivat


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com