[Clfs-dev] CBLFS -- wxWidgets-2.8.9 -- compile problem?

[db m]

Greets,

> Date: Wed, 8 Oct 2008 08:30:43 -0400
> From: jciccone
> To: darowland   ; clfs-dev
> Subject: Re: [Clfs-dev] CBLFS -- wxWidgets-2.8.9 -- compile problem?
> 
> Andrew Rowland wrote:
> >
> >
> > But you'd still have the correct path (-L/usr/local/src/wxWidgets-2.8.9/lib)
> > as part of the LDFLAG variable so the linker should find the library.  Question 
> > is, did you start with a clean source tree after building the 32-bit version?
> >
> >
> >   
>Joe said ;
>
> Note that make clean or make distclean is not always enough. Although
> usually it removes all unwanted objects, every once and a while it leave
> stragglers that can cause these kinds of random problems. That is the
> reasoning behind why you should always remove the directory and start by
> unpacking it again. It may take a few more seconds, but you're 100%
> guaranteed to have a clean tree.
> _______________________________________________

Yeah, in a subsequent posting on this I mention the remove dir/ unpack again
method is what I always employ. That said, (and seeing as you mention it here),
I don't recall seeing any big fat warning to do this on CBLFS wiki....which might
be an oversight in practice....ie; perhaps mention of this should make it's way
into the 'Notice' section of CBLFS? 

Once upon a time (pre 64bit machines and multilib builds), I used to trust  the
make distclean command....but you're right - one cannot trust this at all any 
more, and I sometimes think this should be made more obvious to people....

Back on this wxwidgets topic though, just why the linker is failing to find the
appropriate libraries is making a mockery of my better sensibilities - what
Andrew says is correct AFAIK...it -should- find them....but I cannot argue with
what I've found -- in the makefile for wxrc, the LDFLAGS variable reads;

LDFLAGS = -pthread   -L/usr/lib64

If left like that, the linker fails to find the libraries -- removing the '-L/usr/lib64'
appendage results in everything compiling and linking without error. TBO, 
I'm not even sure -L/usr/lib64 should even appear there, because the build
of wxrc (*without* the -L/usr/lib64 LDFLAGS appendage) results in a 
correctly linked wxrc anyway ;


 ldd /usr/bin/wxrc
    linux-vdso.so.1 =>  (0x00007fff805fe000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f3a78101000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f3a77efd000)
    libwx_base_xml-2.8.so.0 => /usr/lib64/libwx_base_xml-2.8.so.0 (0x00007f3a77cf3000)
    libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f3a77ad0000)
    libwx_base-2.8.so.0 => /usr/lib64/libwx_base-2.8.so.0 (0x00007f3a77798000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f3a77519000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f3a77217000)
    libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f3a7700a000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3a76def000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f3a76aa8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f3a78317000)

{shrug}....so I'm confused. 

I'll redo all of this on a fresh build in a week or so...(once a get an RA on my
other mobo which died over the weekend)...

Regards,

Don

_________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clfs.org/pipermail/clfs-dev-clfs.org/attachments/20081009/02f8df26/attachment-0001.htm>