<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Greets,<br><br>> Date: Wed, 8 Oct 2008 08:30:43 -0400<br>> From: jciccone<br>> To: darowland ; clfs-dev<br>> Subject: Re: [Clfs-dev] CBLFS -- wxWidgets-2.8.9 -- compile problem?<br>> <br>> Andrew Rowland wrote:<br>> ><br>> ><br>> > But you'd still have the correct path (-L/usr/local/src/wxWidgets-2.8.9/lib)<br>> > as part of the LDFLAG variable so the linker should find the library. Question <br>> > is, did you start with a clean source tree after building the 32-bit version?<br>> ><br>> ><br>> > <br>>Joe said ;<br>><br>> Note that make clean or make distclean is not always enough. Although<br>> usually it removes all unwanted objects, every once and a while it leave<br>> stragglers that can cause these kinds of random problems. That is the<br>> reasoning behind why you should always remove the directory and start by<br>> unpacking it again. It may take a few more seconds, but you're 100%<br>> guaranteed to have a clean tree.<br>> _______________________________________________<br><br>Yeah, in a subsequent posting on this I mention the remove dir/ unpack again<br>method is what I always employ. That said, (and seeing as you mention it here),<br>I don't recall seeing any big fat warning to do this on CBLFS wiki....which might<br>be an oversight in practice....ie; perhaps mention of this should make it's way<br>into the 'Notice' section of CBLFS? <br><br>Once upon a time (pre 64bit machines and multilib builds), I used to trust the<br>make distclean command....but you're right - one cannot trust this at all any <br>more, and I sometimes think this should be made more obvious to people....<br><br>Back on this wxwidgets topic though, just why the linker is failing to find the<br>appropriate libraries is making a mockery of my better sensibilities - what<br>Andrew says is correct AFAIK...it -should- find them....but I cannot argue with<br>what I've found -- in the makefile for wxrc, the LDFLAGS variable reads;<br><br>LDFLAGS = -pthread -L/usr/lib64<br><br>If left like that, the linker fails to find the libraries -- removing the '-L/usr/lib64'<br>appendage results in everything compiling and linking without error. TBO, <br>I'm not even sure -L/usr/lib64 should even appear there, because the build<br>of wxrc (*without* the -L/usr/lib64 LDFLAGS appendage) results in a <br>correctly linked wxrc anyway ;<br><br><br> ldd /usr/bin/wxrc<br> linux-vdso.so.1 => (0x00007fff805fe000)<br> libz.so.1 => /lib64/libz.so.1 (0x00007f3a78101000)<br> libdl.so.2 => /lib64/libdl.so.2 (0x00007f3a77efd000)<br> libwx_base_xml-2.8.so.0 => /usr/lib64/libwx_base_xml-2.8.so.0 (0x00007f3a77cf3000)<br> libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f3a77ad0000)<br> libwx_base-2.8.so.0 => /usr/lib64/libwx_base-2.8.so.0 (0x00007f3a77798000)<br> libm.so.6 => /lib64/libm.so.6 (0x00007f3a77519000)<br> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f3a77217000)<br> libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f3a7700a000)<br> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3a76def000)<br> libc.so.6 => /lib64/libc.so.6 (0x00007f3a76aa8000)<br> /lib64/ld-linux-x86-64.so.2 (0x00007f3a78317000)<br><br>{shrug}....so I'm confused. <br><br>I'll redo all of this on a fresh build in a week or so...(once a get an RA on my<br>other mobo which died over the weekend)...<br><br>Regards,<br><br>Don<br><br /><hr /> <a href='' target='_new'></a></body>
</html>