Re: [Linrad] OS X

[Leif Asbrink]

Hello Elwood,


> Two of these (libportaudio, libusb) are in the ports area in /opt/local,
> and libX11 is in /usr/X11R6/lib so I tried giving configure this
> information:
>
> air2: ./configure --libdir=/opt/local --includedir=/opt/local
> --libdir=/usr/X11R6/lib
>
> but the output remains exactly the same.

When I started to use a configure script, the standard tools
did not work properly so I wrote my own for Linrad. I think you
ase the first one to try Linrad on a 64 bit OS X Mountain Lion.

Linrad does search the directories where you have the files.
The libraries are in another format than expected or there
is a bug in Linrad.

To investigate, start with these commands:
gcc libfind1.c -o libfind1 -lm
gcc libfind1.c -o libfind1 -lm

They should run silently and produce the executables libfind1
and libfind2.Then run:
./libfind1 libportaudio.dylib
The output on my 32 bit PC is like this (using .so rather than .dylib of course):
/usr/local/lib/libportaudio.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

You should get
/opt/local/libportaudio.dylib: xxxxxxxxxxxxxxxxxxxxxxxxxxx

Then run ./libfind2 0 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

The result should be 1 if the library is a 32 bit library,
2 if it is a 64 bit library or 3 if it is a library for
32 as well as 64 bit.

Presumably libfind2 returns 0 because your dylib is written
in a format that you are the first Linrad user to encounter.

libfind2 looks for x86_64 and i386 in the string.
Maybe your system uses something else?

libfind1 uses this command :
lipo -info /opt/local/libportaudio.dylib

That should tell what is inside the library.

73

Leif / SM5BSZ

[pidloop]

On Friday, March 22, 2013 3:07:33 AM UTC-7, SM5BSZ wrote:

Hello Elwood,

Hello Leif,

I know OS X is not supported, I appreciate your willingness to explore this together.

To investigate, start with these commands:
gcc libfind1.c -o libfind1 -lm
gcc libfind1.c -o libfind1 -lm

They should run silently and produce the executables libfind1 
and libfind2

I assume you mean 2 for the second, so:

air2: gcc libfind1.c -o libfind1 -lm 

air2: gcc libfind2.c -o libfind2 -lm 

Yes, they both work silently.

Then run: 

./libfind1 libportaudio.dylib
The output on my 32 bit PC is like this (using .so rather than .dylib of course):
/usr/local/lib/libportaudio.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

You should get
/opt/local/libportaudio.dylib: xxxxxxxxxxxxxxxxxxxxxxxxxxx

Yes, that works:

air2: ./libfind1 libportaudio.dylib 

/opt/local/lib/libportaudio.dylib: Mach-O 64-bit dynamically linked shared library x86_64

 

Then run ./libfind2 0 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

The result should be 1 if the library is a 32 bit library,
2 if it is a 64 bit library or 3 if it is a library for
32 as well as 64 bit.

Presumably libfind2 returns 0 because your dylib is written
in a format that you are the first Linrad user to encounter.

libfind2 looks for x86_64 and i386 in the string.
Maybe your system uses something else?

I hope I understand what you want here, the second arg ro libfind2 is the description text reported by libfind1:

air2: ./libfind2 0 'Mach-O 64-bit dynamically linked shared library x86_64'

0

x86_64 is in the string, and yet it reports 0. Is that expected?

 

libfind1 uses this command :
lipo -info /opt/local/libportaudio.dylib

That should tell what is inside the library.

73, Elwood, WB0OEW

 

[Leif Asbrink]

Hi Elwood,

> Yes, that works:
>
> air2: ./libfind1 libportaudio.dylib
> /opt/local/lib/libportaudio.dylib: Mach-O 64-bit dynamically linked shared
> library x86_64

Fine:-)

> > Then run ./libfind2 0 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
> >

> I hope I understand what you want here, the second arg ro libfind2 is the
> description text reported by libfind1:

No, the output of libfind1.

> air2: ./libfind2 0 'Mach-O 64-bit dynamically linked shared library x86_64'
> 0
>
>
> x86_64 is in the string, and yet it reports 0. Is that expected?

NO!!!

P4:/home/dsp# ./libfind2 0 '/opt/local/lib/libportaudio.dylib: Mach-O 64-bit dynamically linked shared library x86_64'
2P4:/home/dsp#

It seems libfind2 works fine, it returns 2 on my system and it
should do so on your system as well. (given the full input)

The next test is to verify portaudio:

gcc -o verify_portaudio verify_portaudio.ol /opt/local/lib/libportaudio.dylib

If this gives an error something is wrong.


Actually yo should run ./configure --with-help first because
such problems are perhaps already taken care of.
In case
uoutr portaudio version is too old you would have to get a more
recent one.

73

Leif

[pidloop]

Hi Lief,

Ok, I see, just to make sure about libfind2, I ran it again using the `` technique to set argument from libfind1. It still reports 0:

air2: ./libfind2 0 ` ./libfind1 libportaudio.dylib `

0

But portaudio seems to verify ok:

air2: gcc -o verify_portaudio verify_portaudio.c /opt/local/lib/libportaudio.dylib

air2: ./verify_portaudio 

PortAudio ver 1899 

PortAudio V19-devel (built Nov 18 2012 07:27:25)

What next?

Thanks,

Elwood

[w3sz]

Given the recently rekindled interest in OS X and Linrad I decided to
see how things were working here in that regard.

I had gotten Linrad-03.28 working on both my iMac and MacPro back in Dec
2011. I didn't try it on the MacBook Air.

What I found today was that an OS X upgrade done since that time has
broken the installation, and I can't reconfigure/recompile due to
multiple missing symlinks. I suspect that this is due to the OS X
upgrade destroying all user-installed symlinks. I recall that
previously an OS X upgrade here destroyed all user-installed symlinks
and either MacPorts or Fink on one of my Macs...I don't recall which Mac
or which OS X upgrade that was, but I wouldn't be surprised if that has
happened again. At that time I had to start from ground zero and
re-create my entire unix environment [thank you Apple!!].

Apple is a pretty closed universe, and they "get away" with things like
this that would never be tolerated in the Microsoft world for 2
reasons: [1] the Mac world really is cult-like (I say this as the owner
of multiple Mac computers and Apple devices) and [2] only a small
fraction of Mac users stray from the prepackaged software offerings, so
when all user-installed symlinks disappear as the result of a software
upgrade, it is not a big deal in terms of number of affected users, even
though it is a major problem for the small number of affected users. So
Apple doesn't care.

I don't have time due to other projects to sort things out further here,
and don't plan to try to sort it out at this point as I have no need to
do so, but wanted to mention this in case anyone is trying to "get back
in the game" with Linrad on OS X as a result of the recent thread on
this subject. If you have upgraded your OS X since you last played with
Linrad, you may find that you have some major work to do. Here, I think
I would need to totally recreate my MacPorts installation to get things
working.

Just to be clear, none of this is a "Linrad" problem. The problem is
that OS X updates can absolutely trash user-installed symlinks as well
as other user-installed items that are essential for using unix on the
Mac. And when I say "user-installed", I don't mean only things that the
user did himself; I am also including symlinks that were installed by a
program such as MacPorts or Fink or other non-Apple program that Apple
didn't see fit to "protect" when it wrote the upgrade. Linrad just
happens to need a functioning unix-based system to configure, compile,
and run correctly, and so is caught in this web as an innocent bystander.

There was a brief thead on Linrad and OS X on this reflector back in
Dec. 2011. The URL for that should be something like:
http://groups.google.com/group/linrad/browse_thread/thread/55bf1a6e509f688d/2c09b3e49a795033?lnk=gst&q=os+x#2c09b3e49a795033

It didn't contain a lot of info that would be currently helpful, but it
does document that Linrad on OS X was in fact functioning at that time.

Have a great week all, and

73,

Roger Rehr
W3SZ

[Leif Asbrink]

Hello Elwood,

First of all, what does the configure script
write about portaudio when you run it with the
option --with-help ?

> Ok, I see, just to make sure about libfind2, I ran it again using the ``
> technique to set argument from libfind1. It still reports 0:
>
> air2: ./libfind2 0 ` ./libfind1 libportaudio.dylib `
> 0

Yes, but you have to run it with the full output from libfind1 like this:

./libfind2 0 '/opt/local/lib/libportaudio.dylib: Mach-O 64-bit dynamically linked shared library x86_64'

> But portaudio seems to verify ok:
>
> air2: gcc -o verify_portaudio verify_portaudio.c
> /opt/local/lib/libportaudio.dylib
> air2: ./verify_portaudio
>
> PortAudio ver 1899
> PortAudio V19-devel (built Nov 18 2012 07:27:25)

Try the attached configure script which will print
the values of the variables used in the configure script.
(Things that control the output with the --with-help option.)

It is clear that OS X changes from time to time, Linux is also
doing that, but since I run Linux myself it is not a problem
because I can add whatever required to the configure script
before users notice any problems. I would like Linrad
to run on all the OS X verisons released after the one
in which Linrad was first running ok.

73

Leif

[pidloop]

On Sunday, March 24, 2013 2:42:15 PM UTC-7, SM5BSZ wrote:

Hello Elwood,

First of all, what does the configure script
write about portaudio when you run it with the
option --with-help ?

It says ALOT about many things. I've cut out the part about portaudio:

air2: ./configure --with-help

<snip>

MISSING: libportaudio.dylib (32bit)

Portaudio may have to be installed from source code.

The purpose of installing Portaudio is to be able to use Jack.

The versions included in the distributions may not support Jack

Make sure to remove any old non-working version first.

Copy from a 32 bit installation with Jack support

To install the distribution version use one of these commands:

SuSE zypper install portaudio-devel

SuSE zypper install portaudio-32bit

Mandriva: urpmi libportaudio2

Fedora: yum install portaudio-devel.i686

old Fedora: yum install portaudio-devel.i586, portaudio-devel

A symbolic link may be needed:

ln -s ..../lib/libportaudio.dylib.2 libportaudio.dylib

<snip>

 

Yes, but you have to run it with the full output from libfind1 like this:

./libfind2 0 '/opt/local/lib/libportaudio.dylib: Mach-O 64-bit dynamically linked shared library x86_64'

Ok, doing it that way now it reports 2:

air2: ./libfind2 0 '/opt/local/lib/libportaudio.dylib: Mach-O 64-bit dynamically linked shared library x86_64' 

2

 

Try the attached configure script which will print
the values of the variables used in the configure script.
(Things that control the output with the --with-help option.)

Sorry, how do I get your attached file?

BTW, regarding the post by W3SZ, this is my first attempt to try linrad on OS X, so I have no prior symlinks to loose. Besides, you (Lief) said you didn't want users doing that, you would prefer your installation kit run on a clean system. That is my goal also.

Lief, if at any time this is getting to be too much time and trouble for you, please just say so, I will understand.

73, Elwood 

[Leif Asbrink]

> > Hello Elwood,

> > First of all, what does the configure script
> > write about portaudio when you run it with the
> > option --with-help ?
> >
> >
> It says ALOT about many things. I've cut out the part about portaudio:
>
> air2: ./configure --with-help
> <snip>
>
> MISSING: libportaudio.dylib (32bit)

> .
> .
That is the message saying that the 32 bit version of
Portaudio is missing on your system. That is no error,
you do not have a 32 bit version, but you do have a 64 bit
version as indicated by libfind2 so I wonder what is the
message after:
MISSING: libportaudio.dylib (64bit)

> > Try the attached configure script which will print
> > the values of the variables used in the configure script.
> > (Things that control the output with the --with-help option.)
> >
> >
> Sorry, how do I get your attached file?

I have attached a new version of configure. It is for Linrad-03.48
because that is the version I am putting all the changes into.

I have no idea how the mail client works on your system.
Maybe you should right-click whereever "configure" appears
somewhere outside the body of this mail to get a menu
on which you would select "save" to save the attachment on your
hard disk.

Run the file --with-help and send the full output to me off-list.

> BTW, regarding the post by W3SZ, this is my first attempt to try linrad on
> OS X, so I have no prior symlinks to loose. Besides, you (Lief) said you
> didn't want users doing that, you would prefer your installation kit run on
> a clean system. That is my goal also.

Very good:-)

> Lief, if at any time this is getting to be too much time and trouble for
> you, please just say so, I will understand.

No, this will not be too much for me. I just hope it will
not be too much for you:-)

73

Leif