I am running 64 bit Fedora Rawhide.  64 bit systems keep their
64 bit libraries in /usr/lib64.  /lib64 is a symbolic link to /usr/lib64.
This change was made to better suit SSDs as I recall.

The 4133 configure.ac refuses to generate a Makefile unless 32 bit
versions of portaudio et al. are installed.  Once installed the linker
tries to use these 32 bit libs to link the 64 bit object.  Major fail.

At least with the previous version a Makefile was generated which
could be corrected to result in a working program.

On 05/14/2014 01:08 AM, ki7mt wrote:
> Hi Chuck,
>
> I found a couple things that was probably contributing to your issues. I
> didn't see them locally until I uninstalled the dependencies, then
> tested each one separately, Samplerate, FFTW and Portaudio. I also added
> /usr/lib64 to the non-standard search path section. If you have further
> issues, zip up the config.log and send it over so I can have a look at it.
>
> You should do a full clean then build:
>
> make clean
> make distclean
> svn update
> ./autogen.sh
> make  <== assuming no errors
>
> If configure fails to find the libs (samplerate, fftw or portaudio), it
> should exit before creating a new Makefile.
>
> Let me know ho things progress.
>
> 73's
> Greg, KI7MT
>
> On 05/13/2014 05:09 PM, ki7mt wrote:
>> Hi Chuck,
>> On 05/13/2014 04:17 PM, Chuck Forsberg WA7KGX wrote:
>>> It is getting strange.  I download a fresh wspr and then sh au*sh
>>> then  ./configure --libdir=/usr/lib64
>>> --with-portaudio-include-dir=/usr/include
>>> --with-portaudio-lib-dir=/usr/lib64
>>>
>>> Configure failed to choose f2py3 and did not put anything into LIBS=
>>> I had to manually add -lportaudio -lfftw3f to compile a copy that works
>>> with python3 -O wspr.py
>> Configure wont put anything into LIBS = if it doesn't find them. All
>> three lib checks are setup the same way, Samplerate, FFTW3f and
>> Portaudio, with the exception of FFTW3F header check. Adding --libdir
>> may be affecting things. You should not need
>> --with-portaudio-include-dir=/usr/include as that path is checked.
>> However /usr/lib64 is not.
>>
>> It's odd that Samplerate (headers and lib)  are found, or at least
>> your not stating that it needs to be added manually.
>>
>> The F2py check is fiarly straight forward, if f2py -v returns
>> positive, then t sets it, same for f2py3 -v.  So if they are not in
>> your system paths, it not going to find / set either one.
>>
>>
>>> B ut this time the generated .so filename had to periods
>>> in it so the MV instruction worked as written.
>>>
>>>
>>> On 05/13/2014 01:15 PM, ki7mt wrote:
>>>> Hi Chuck,
>>>>
>>>> Thanks for the feedback.
>>>>
>>>> On 05/13/2014 05:47 AM, Chuck Forsberg WA7KGX wrote:
>>>>> Python3 version 3.3.2
>>>>> f2py3 version 2
>>>>> f2py version 2
>>>> Cpython produces different outputs of w* based on the
>>>> /usr/include/pythonx.xx. For example, on my Python3.4 system the output
>>>> file is:
>>>>
>>>> w.cpython34m.so
>>>>
>>>> whereas on the same system, using Python3.2, it was producing
>>>> w.cpython-32mu.so.
>>>>
>>>>> MVSO    := ${MV} w.*.so WsprMod/w.so
>>>>> had to be changed to
>>>>> MVSO    := ${MV} w*.so WsprMod/w.so
>>>>>         note:  globbing != regex
>>>> That's interesting, !=  I wasn't aware of that combination. In the end,
>>>> I suppose it doesn't matter if it's w*.so or w.*.so as three aren't any
>>>> other files that match that combination in the source tree, but there
>>>> could be, which was why I added w.* v.s. w*.so
>>>>
>>>>> 4130 now recognizes f2py3
>>>>>
>>>>> I added -lportaudio -lfftw3f to LIBS=
>>>>>
>>>>> and now wspr 4130 compiles and runs.
>>>> In your final Makefile, after running autogen.sh,  are ( -lportaudio )
>>>> and ( -lfftw3f ) not listed on the LIBS= line? If not, they should be,
>>>> if configure found them. You should also get a warning messages if they
>>>> were not found / included in LIBS. My line shows (after running
>>>> autogen.sh or autoconf -f -i && ./configure:
>>>>
>>>> LIBS        :=     -lsamplerate -lfftw3f -lportaudio
>>>>
>>>>> On 05/13/2014 02:37 AM, ki7mt wrote:
>>>>>> Hi Chuck,
>>>>>>
>>>>>> I looked over potential causes for the issue you have. I found one
>>>>>> thing
>>>>>> that may be related, but a new checkout would have failed right at
>>>>>> the
>>>>>> beginning of make, so not sure that will resolve your problem.
>>>>>>
>>>>>> I still need the info from my previous post, in addition to that,
>>>>>> could
>>>>>> you tell us what Python & Numpy version your using?
>>>> 73's
>>>> Greg, KI7MT
>>>>
>>>>>> 73's
>>>>>> Greg, KI7MT
>>>>>>
>>>>>> On 05/13/2014 02:02 AM, Chuck Forsberg WA7KGX wrote:
>>>>>>> I get the following error when I compile and run wspr 4129
>>>>>>>
>>>>>>> [caf@omen3 wspr]$ python3 -O wspr.py
>>>>>>> Traceback (most recent call last):
>>>>>>>          File "wspr.py", line 45, in <module>
>>>>>>>            from WsprMod import w
>>>>>>> ImportError: dynamic module does not define init function (PyInit_w)
>>>>>>>
>>>>>>> Also the Makefile line
>>>>>>>
>>>>>>>            MVSO    := ${MV} w.*.so WsprMod/w.so
>>>>>>>
>>>>>>> doesn't work
>>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For
>>>>>> FREE
>>>>>> Instantly run your Selenium tests across 300+ browser/OS combos.
>>>>>> Get unparalleled scalability from the best Selenium testing
>>>>>> platform available
>>>>>> Simple to use. Nothing to install. Get started now for free."
>>>>>> http://p.sf.net/sfu/SauceLabs
>>>>>> _______________________________________________
>>>>>> wsjt-devel mailing list
>>>>>> wsjt-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>>> Instantly run your Selenium tests across 300+ browser/OS combos.
>>>> Get unparalleled scalability from the best Selenium testing platform
>>>> available
>>>> Simple to use. Nothing to install. Get started now for free."
>>>> http://p.sf.net/sfu/SauceLabs
>>>> _______________________________________________
>>>> wsjt-devel mailing list
>>>> wsjt-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

-- 
      Chuck Forsberg WA7KGX   c...@omen.com   www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
   Omen Technology Inc      "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to