jackd/jackdmp switch layer to test

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

jackd/jackdmp switch layer to test

Stéphane Letz
Hi all,

The layer wrapper so that users can easily switch between jackd and  
jackdmp can be tested using latest SVN version of jackd SVN and  
jackdmp SVN. The general idea is to provide a "wrapper" library jack  
clients will link to and that will redirect to the real libjack.so or  
libjackmp.so library depending of which of jackd or jackdmp server is  
currently running.

To test:

1) build and install jack SVN

2) build jackdmp SVN, use the "make installwrapper"  to install the  
layer library

3) start jackd, in a terminal or using qjackctl, then all jack clients  
should see the jackd server running and connect to it.

4) or start jackdmp, in a terminal or using qjackctl, then all jack  
clients should see the jackdmp server running and connect to it.

Automatic server launching is implemented but has not been tested yet.

Feedback, bug report welcomed!

Stephane

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Wed, 2008-03-12 at 15:52 +0100, Stéphane Letz wrote:
> Hi all,
>
> The layer wrapper so that users can easily switch between jackd and  
> jackdmp can be tested using latest SVN version of jackd SVN and  
> jackdmp SVN. The general idea is to provide a "wrapper" library jack  
> clients will link to and that will redirect to the real libjack.so or  
> libjackmp.so library depending of which of jackd or jackdmp server is  
> currently running.

Great news!!!

> To test:
>
> 1) build and install jack SVN

Current jack svn fails to build with:
(last successfull build was 0.109.2 svn checkout, same build options)


 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../config -I.. -I.. -D_REENTRANT
-D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -DJACK_LOCATION=\"/usr/bin\" -I../config
-I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -MT libjackserver_la-simd.lo -MD -MP
-MF .deps/libjackserver_la-simd.Tpo -c ../libjack/simd.c  -fPIC -DPIC
-o .libs/libjackserver_la-simd.o
../libjack/simd.c: In function 'x86_3dnow_copyf':
../libjack/simd.c:133: error: unknown register name 'mm0' in 'asm'
../libjack/simd.c:135: error: unknown register name 'mm1' in 'asm'
../libjack/simd.c:137: error: unknown register name 'mm2' in 'asm'
../libjack/simd.c:139: error: unknown register name 'mm3' in 'asm'
../libjack/simd.c:141: error: unknown register name 'mm4' in 'asm'
../libjack/simd.c:143: error: unknown register name 'mm5' in 'asm'
../libjack/simd.c:145: error: unknown register name 'mm6' in 'asm'
../libjack/simd.c:147: error: unknown register name 'xmm7' in 'asm'
../libjack/simd.c:150: error: unknown register name 'mm0' in 'asm'
../libjack/simd.c:152: error: unknown register name 'mm1' in 'asm'
../libjack/simd.c:154: error: unknown register name 'mm2' in 'asm'
../libjack/simd.c:156: error: unknown register name 'mm3' in 'asm'
../libjack/simd.c:158: error: unknown register name 'mm4' in 'asm'
../libjack/simd.c:160: error: unknown register name 'mm5' in 'asm'
../libjack/simd.c:162: error: unknown register name 'mm6' in 'asm'
../libjack/simd.c:164: error: unknown register name 'mm7' in 'asm'
../libjack/simd.c:169: error: unknown register name 'mm0' in 'asm'
../libjack/simd.c:178: error: unknown register name 'mm0' in 'asm'
../libjack/simd.c: In function 'x86_3dnow_add2f':
../libjack/simd.c:200: error: unknown register name 'mm0' in 'asm'
../libjack/simd.c:211: error: unknown register name 'mm1' in 'asm'
../libjack/simd.c:211: error: unknown register name 'mm0' in 'asm'
../libjack/simd.c: In function 'x86_sse_copyf':
../libjack/simd.c:238: error: unknown register name 'xmm0' in 'asm'
../libjack/simd.c:240: error: unknown register name 'xmm1' in 'asm'
../libjack/simd.c:242: error: unknown register name 'xmm2' in 'asm'
../libjack/simd.c:244: error: unknown register name 'xmm3' in 'asm'
../libjack/simd.c:246: error: unknown register name 'xmm4' in 'asm'
../libjack/simd.c:248: error: unknown register name 'xmm5' in 'asm'
../libjack/simd.c:250: error: unknown register name 'xmm6' in 'asm'
../libjack/simd.c:252: error: unknown register name 'xmm7' in 'asm'
../libjack/simd.c:255: error: unknown register name 'xmm0' in 'asm'
../libjack/simd.c:257: error: unknown register name 'xmm1' in 'asm'
../libjack/simd.c:259: error: unknown register name 'xmm2' in 'asm'
../libjack/simd.c:261: error: unknown register name 'xmm3' in 'asm'
../libjack/simd.c:263: error: unknown register name 'xmm4' in 'asm'
../libjack/simd.c:265: error: unknown register name 'xmm5' in 'asm'
../libjack/simd.c:267: error: unknown register name 'xmm6' in 'asm'
../libjack/simd.c:269: error: unknown register name 'xmm7' in 'asm'
../libjack/simd.c:274: error: unknown register name 'xmm0' in 'asm'
../libjack/simd.c:283: error: unknown register name 'xmm0' in 'asm'
../libjack/simd.c: In function 'x86_sse_add2f':
../libjack/simd.c:309: error: unknown register name 'xmm0' in 'asm'
../libjack/simd.c:321: error: unknown register name 'xmm0' in 'asm'
make[2]: *** [libjackserver_la-simd.lo] Error 1
make[2]: Leaving directory
`/usr/src/rpm/BUILD/jack-audio-connection-kit-0.109.10/jackd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/usr/src/rpm/BUILD/jack-audio-connection-kit-0.109.10'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.60834 (%build)

Configured with:
----
./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
--libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info --enable-static --enable-stripped-jackd
--enable-dynsimd=yes --with-default-tmpdir=/dev/shm
----

-- Fernando


> 2) build jackdmp SVN, use the "make installwrapper"  to install the  
> layer library
>
> 3) start jackd, in a terminal or using qjackctl, then all jack clients  
> should see the jackd server running and connect to it.
>
> 4) or start jackdmp, in a terminal or using qjackctl, then all jack  
> clients should see the jackdmp server running and connect to it.
>
> Automatic server launching is implemented but has not been tested yet.
>
> Feedback, bug report welcomed!
>
> Stephane



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Thu, 2008-03-13 at 10:46 -0700, Fernando Lopez-Lezcano wrote:

> On Wed, 2008-03-12 at 15:52 +0100, Stéphane Letz wrote:
> > Hi all,
> >
> > The layer wrapper so that users can easily switch between jackd and  
> > jackdmp can be tested using latest SVN version of jackd SVN and  
> > jackdmp SVN. The general idea is to provide a "wrapper" library jack  
> > clients will link to and that will redirect to the real libjack.so or  
> > libjackmp.so library depending of which of jackd or jackdmp server is  
> > currently running.
>
> Great news!!!
>
> > To test:
> >
> > 1) build and install jack SVN
>
> Current jack svn fails to build with:
> (last successfull build was 0.109.2 svn checkout, same build options)

Looks like missing sse/etc flags in the jackd Makefile (they are there
in the libjack Makefile).

-- Fernando


>  gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../config -I.. -I.. -D_REENTRANT
> -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
> -fasynchronous-unwind-tables -DJACK_LOCATION=\"/usr/bin\" -I../config
> -I.. -I.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -g -pipe
> -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
> -fasynchronous-unwind-tables -MT libjackserver_la-simd.lo -MD -MP
> -MF .deps/libjackserver_la-simd.Tpo -c ../libjack/simd.c  -fPIC -DPIC
> -o .libs/libjackserver_la-simd.o
> ../libjack/simd.c: In function 'x86_3dnow_copyf':
> ../libjack/simd.c:133: error: unknown register name 'mm0' in 'asm'
> ../libjack/simd.c:135: error: unknown register name 'mm1' in 'asm'
> ../libjack/simd.c:137: error: unknown register name 'mm2' in 'asm'
> ../libjack/simd.c:139: error: unknown register name 'mm3' in 'asm'
> ../libjack/simd.c:141: error: unknown register name 'mm4' in 'asm'
> ../libjack/simd.c:143: error: unknown register name 'mm5' in 'asm'
> ../libjack/simd.c:145: error: unknown register name 'mm6' in 'asm'
> ../libjack/simd.c:147: error: unknown register name 'xmm7' in 'asm'
> ../libjack/simd.c:150: error: unknown register name 'mm0' in 'asm'
> ../libjack/simd.c:152: error: unknown register name 'mm1' in 'asm'
> ../libjack/simd.c:154: error: unknown register name 'mm2' in 'asm'
> ../libjack/simd.c:156: error: unknown register name 'mm3' in 'asm'
> ../libjack/simd.c:158: error: unknown register name 'mm4' in 'asm'
> ../libjack/simd.c:160: error: unknown register name 'mm5' in 'asm'
> ../libjack/simd.c:162: error: unknown register name 'mm6' in 'asm'
> ../libjack/simd.c:164: error: unknown register name 'mm7' in 'asm'
> ../libjack/simd.c:169: error: unknown register name 'mm0' in 'asm'
> ../libjack/simd.c:178: error: unknown register name 'mm0' in 'asm'
> ../libjack/simd.c: In function 'x86_3dnow_add2f':
> ../libjack/simd.c:200: error: unknown register name 'mm0' in 'asm'
> ../libjack/simd.c:211: error: unknown register name 'mm1' in 'asm'
> ../libjack/simd.c:211: error: unknown register name 'mm0' in 'asm'
> ../libjack/simd.c: In function 'x86_sse_copyf':
> ../libjack/simd.c:238: error: unknown register name 'xmm0' in 'asm'
> ../libjack/simd.c:240: error: unknown register name 'xmm1' in 'asm'
> ../libjack/simd.c:242: error: unknown register name 'xmm2' in 'asm'
> ../libjack/simd.c:244: error: unknown register name 'xmm3' in 'asm'
> ../libjack/simd.c:246: error: unknown register name 'xmm4' in 'asm'
> ../libjack/simd.c:248: error: unknown register name 'xmm5' in 'asm'
> ../libjack/simd.c:250: error: unknown register name 'xmm6' in 'asm'
> ../libjack/simd.c:252: error: unknown register name 'xmm7' in 'asm'
> ../libjack/simd.c:255: error: unknown register name 'xmm0' in 'asm'
> ../libjack/simd.c:257: error: unknown register name 'xmm1' in 'asm'
> ../libjack/simd.c:259: error: unknown register name 'xmm2' in 'asm'
> ../libjack/simd.c:261: error: unknown register name 'xmm3' in 'asm'
> ../libjack/simd.c:263: error: unknown register name 'xmm4' in 'asm'
> ../libjack/simd.c:265: error: unknown register name 'xmm5' in 'asm'
> ../libjack/simd.c:267: error: unknown register name 'xmm6' in 'asm'
> ../libjack/simd.c:269: error: unknown register name 'xmm7' in 'asm'
> ../libjack/simd.c:274: error: unknown register name 'xmm0' in 'asm'
> ../libjack/simd.c:283: error: unknown register name 'xmm0' in 'asm'
> ../libjack/simd.c: In function 'x86_sse_add2f':
> ../libjack/simd.c:309: error: unknown register name 'xmm0' in 'asm'
> ../libjack/simd.c:321: error: unknown register name 'xmm0' in 'asm'
> make[2]: *** [libjackserver_la-simd.lo] Error 1
> make[2]: Leaving directory
> `/usr/src/rpm/BUILD/jack-audio-connection-kit-0.109.10/jackd'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/usr/src/rpm/BUILD/jack-audio-connection-kit-0.109.10'
> make: *** [all] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.60834 (%build)
>
> Configured with:
> ----
> ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu
> --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
> --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include
> --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var
> --sharedstatedir=/usr/com --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-static --enable-stripped-jackd
> --enable-dynsimd=yes --with-default-tmpdir=/dev/shm
> ----
>
> -- Fernando
>
>
> > 2) build jackdmp SVN, use the "make installwrapper"  to install the  
> > layer library
> >
> > 3) start jackd, in a terminal or using qjackctl, then all jack clients  
> > should see the jackd server running and connect to it.
> >
> > 4) or start jackdmp, in a terminal or using qjackctl, then all jack  
> > clients should see the jackdmp server running and connect to it.
> >
> > Automatic server launching is implemented but has not been tested yet.
> >
> > Feedback, bug report welcomed!



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Thu, 2008-03-13 at 12:02 -0700, Fernando Lopez-Lezcano wrote:

> On Thu, 2008-03-13 at 10:46 -0700, Fernando Lopez-Lezcano wrote:
> > On Wed, 2008-03-12 at 15:52 +0100, Stéphane Letz wrote:
> > > Hi all,
> > >
> > > The layer wrapper so that users can easily switch between jackd and  
> > > jackdmp can be tested using latest SVN version of jackd SVN and  
> > > jackdmp SVN. The general idea is to provide a "wrapper" library jack  
> > > clients will link to and that will redirect to the real libjack.so or  
> > > libjackmp.so library depending of which of jackd or jackdmp server is  
> > > currently running.
> >
> > Great news!!!
> >
> > > To test:
> > >
> > > 1) build and install jack SVN
> >
> > Current jack svn fails to build with:
> > (last successfull build was 0.109.2 svn checkout, same build options)
>
> Looks like missing sse/etc flags in the jackd Makefile (they are there
> in the libjack Makefile).

Plus the example programs need to also link with the ncurses libraries
(at least in Fedora) - see below.

-- Fernando


--- example-clients/SConscript~ 2008-03-13 18:48:01.000000000 -0400
+++ example-clients/SConscript 2008-03-13 20:57:30.274746028 -0400
@@ -59,6 +59,7 @@
 if env['HAS_READLINE']:
     example_programs['jack_transport'] = 'transport.c'
     extra_libs['jack_transport'] = ['readline', env['CLIENTLIB']]
+    extra_libs['jack_transport'] += ['ncurses', env['CLIENTLIB']]
 
 #
 # Build/install section



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Stéphane Letz

Le 14 mars 08 à 18:27, Fernando Lopez-Lezcano a écrit :

> On Thu, 2008-03-13 at 12:02 -0700, Fernando Lopez-Lezcano wrote:
>> On Thu, 2008-03-13 at 10:46 -0700, Fernando Lopez-Lezcano wrote:
>>> On Wed, 2008-03-12 at 15:52 +0100, Stéphane Letz wrote:
>>>> Hi all,
>>>>
>>>> The layer wrapper so that users can easily switch between jackd and
>>>> jackdmp can be tested using latest SVN version of jackd SVN and
>>>> jackdmp SVN. The general idea is to provide a "wrapper" library  
>>>> jack
>>>> clients will link to and that will redirect to the real  
>>>> libjack.so or
>>>> libjackmp.so library depending of which of jackd or jackdmp  
>>>> server is
>>>> currently running.
>>>
>>> Great news!!!
>>>
>>>> To test:
>>>>
>>>> 1) build and install jack SVN
>>>
>>> Current jack svn fails to build with:
>>> (last successfull build was 0.109.2 svn checkout, same build  
>>> options)
>>
>> Looks like missing sse/etc flags in the jackd Makefile (they are  
>> there
>> in the libjack Makefile).

Still did not have the time yet to look at that.

Basically the compilation process was reorganized to produce a new  
"libjackserver" shared library that contains the server side of the  
code. Then the "jackd" exe just link to this library. I guess  
something was forgotten during this process.

>
> Plus the example programs need to also link with the ncurses libraries
> (at least in Fedora) - see below.
>
> -- Fernando
>
>
> --- example-clients/SConscript~ 2008-03-13 18:48:01.000000000 -0400
> +++ example-clients/SConscript 2008-03-13 20:57:30.274746028 -0400
> @@ -59,6 +59,7 @@
>  if env['HAS_READLINE']:
>      example_programs['jack_transport'] = 'transport.c'
>      extra_libs['jack_transport'] = ['readline', env['CLIENTLIB']]
> +    extra_libs['jack_transport'] += ['ncurses', env['CLIENTLIB']]
>
>  #
>  # Build/install section
>
>
Applied thanks!

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Fri, 2008-03-14 at 18:51 +0100, Stéphane Letz wrote:

> Le 14 mars 08 à 18:27, Fernando Lopez-Lezcano a écrit :
> >> Looks like missing sse/etc flags in the jackd Makefile (they are  
> >> there
> >> in the libjack Makefile).
>
> Still did not have the time yet to look at that.
>
> Basically the compilation process was reorganized to produce a new  
> "libjackserver" shared library that contains the server side of the  
> code. Then the "jackd" exe just link to this library. I guess  
> something was forgotten during this process.

I worked around it with a patch (it compiles).

> > Plus the example programs need to also link with the ncurses libraries
> > (at least in Fedora) - see below.
> >
> > --- example-clients/SConscript~ 2008-03-13 18:48:01.000000000 -0400
> > +++ example-clients/SConscript 2008-03-13 20:57:30.274746028 -0400
> > @@ -59,6 +59,7 @@
> >  if env['HAS_READLINE']:
> >      example_programs['jack_transport'] = 'transport.c'
> >      extra_libs['jack_transport'] = ['readline', env['CLIENTLIB']]
> > +    extra_libs['jack_transport'] += ['ncurses', env['CLIENTLIB']]
> >
> >  #
> >  # Build/install section
> >
> >
> Applied thanks!

May not be the proper fix. Probably the correct one is to query
pkgconfig for the list of required link libraries.

Also, the linux/Makefile installwrapper does not seem to work as is. It
assumes libjackmp.so & friends are in the same dir, whereas they are
in ../common/ (at least in my case), etc, etc. I'm reworking things to
do what I think is the right think just to make a package to test...

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Stéphane Letz

Le 14 mars 08 à 19:31, Fernando Lopez-Lezcano a écrit :

> On Fri, 2008-03-14 at 18:51 +0100, Stéphane Letz wrote:
>> Le 14 mars 08 à 18:27, Fernando Lopez-Lezcano a écrit :
>>>> Looks like missing sse/etc flags in the jackd Makefile (they are
>>>> there
>>>> in the libjack Makefile).
>>
>> Still did not have the time yet to look at that.
>>
>> Basically the compilation process was reorganized to produce a new
>> "libjackserver" shared library that contains the server side of the
>> code. Then the "jackd" exe just link to this library. I guess
>> something was forgotten during this process.
>
> I worked around it with a patch (it compiles).
>
>>> Plus the example programs need to also link with the ncurses  
>>> libraries
>>> (at least in Fedora) - see below.
>>>
>>> --- example-clients/SConscript~ 2008-03-13 18:48:01.000000000 -0400
>>> +++ example-clients/SConscript 2008-03-13 20:57:30.274746028 -0400
>>> @@ -59,6 +59,7 @@
>>>  if env['HAS_READLINE']:
>>>      example_programs['jack_transport'] = 'transport.c'
>>>      extra_libs['jack_transport'] = ['readline', env['CLIENTLIB']]
>>> +    extra_libs['jack_transport'] += ['ncurses', env['CLIENTLIB']]
>>>
>>>  #
>>>  # Build/install section
>>>
>>>
>> Applied thanks!
>
> May not be the proper fix. Probably the correct one is to query
> pkgconfig for the list of required link libraries.

Marc-Olivier Barre is more on the scons thing actually. There is also  
an issue correctly detecting that "readline" is actually installed  
(Marc if you hear me...)

>
> Also, the linux/Makefile installwrapper does not seem to work as  
> is. It
> assumes libjackmp.so & friends are in the same dir, whereas they are
> in ../common/ (at least in my case), etc, etc.

We are in a transition period when the Makefile is still used but  
Marc is actively working on the much cleaner scons based  
build&install system. Not even sure the wrapper layer will work with  
the library naming convention that is used by scons..

> I'm reworking things to
> do what I think is the right think just to make a package to test...
>
> -- Fernando
OK.

Stephane


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Stéphane Letz
In reply to this post by Fernando Lopez-Lezcano
> in ../common/ (at least in my case), etc, etc. I'm reworking things to
> do what I think is the right think just to make a package to test...
>

Another point: how will the package system would work? Does the  
following would make sense?

- jackd package install as before

-if jackdmp if installed on a system where jackd is already  
installed, then the "wrapper" library should be used

- otherwise if jackdmp is installed on a fresh system, then real  
libjackmp library should be used and the libjack.so link created  
accordingly.

Stephane

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Fri, 2008-03-14 at 19:51 +0100, Stéphane Letz wrote:

> > in ../common/ (at least in my case), etc, etc. I'm reworking things to
> > do what I think is the right think just to make a package to test...
> >
>
> Another point: how will the package system would work? Does the  
> following would make sense?
>
> - jackd package install as before
>
> -if jackdmp if installed on a system where jackd is already  
> installed, then the "wrapper" library should be used
>
> - otherwise if jackdmp is installed on a fresh system, then real  
> libjackmp library should be used and the libjack.so link created  
> accordingly.

Right now I'm trying to build a package that includes both of them. It
is the easiest approach.

The problem is a package should not modify files that are part of
another package (including libraries :-) and that's what would happen if
you have to use the libwrapper library. It would be possible I guess to
play with links at install time, etc, but it complicates things at this
early stage.

I imagine the best system would be to have a "jack-libwrapper" package
that is required by both the "jack-audio-connection-kit" and the
"jackdmp" packages. Ie: installing either will automatically install
jack-libwrapper and no package modifies files owned by another package.
So, both normal jackd and jackdmp go through libwrapper all the time.

First try a moment ago:

----
$ jackdmp -d alsa -d hw
could not open driver directory /usr/local/lib/jackmp: No such file or
directory

jackdmp: no drivers found; exiting
----

so there is a hardwired /usr/local assumption somewhere I have to hunt
for (I think I'm telling all build programs and scripts I want /usr
instead of /usr/local)

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Fri, 2008-03-14 at 12:24 -0700, Fernando Lopez-Lezcano wrote:

> On Fri, 2008-03-14 at 19:51 +0100, Stéphane Letz wrote:
> > > in ../common/ (at least in my case), etc, etc. I'm reworking things to
> > > do what I think is the right think just to make a package to test...
> > >
> >
> > Another point: how will the package system would work? Does the  
> > following would make sense?
> >
> > - jackd package install as before
> >
> > -if jackdmp if installed on a system where jackd is already  
> > installed, then the "wrapper" library should be used
> >
> > - otherwise if jackdmp is installed on a fresh system, then real  
> > libjackmp library should be used and the libjack.so link created  
> > accordingly.
>
> Right now I'm trying to build a package that includes both of them. It
> is the easiest approach.

Finally works! (jackd / jackdmp in one package that includes the wrapper
library). I had to ignore some of the stuff in the wrapper install
target in the makefile[*].

I can start either jackd or jackdmp and the clients don't seem to mind
(not while a client is running, of course :-)

Very good news...
-- Fernando

[*] this what I did in the spec file install script, this is after a cd
to the linux subdirectory, %buildroot is in /var/tmp and is a "virtual
install root that is not /":

# do the installwrapper install by hand, the script is just wrong...
cp jackdmp %{buildroot}%{_prefix}/bin
cp ../common/libjackmp.so %{buildroot}%{_libdir}
cp ../common/libjackservermp.so %{buildroot}%{_libdir}
cp ../common/libjackwrapper.so %{buildroot}%{_libdir}
# install the jackmp libraries
install -d %{buildroot}%{_libdir}/jackmp/
cp libjack_alsa.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_alsa.so
cp libjack_dummy.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_dummy.so
cp libjack_freebob.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_freebob.so
# (re)install the headers
rm -rf %{buildroot}%{_includedir}/jack
install -d %{buildroot}%{_includedir}/jack/
cp ../common/jack/*.h %{buildroot}%{_includedir}/jack/
# relink the libraries to the wrapper, symbolic links will not do
# as the .so.0 link is recreated by ldoconfig to point to the
# original jackd library and clients can't connect
rm -f %{buildroot}%{_libdir}/libjack.so
rm -f %{buildroot}%{_libdir}/libjack.so.0
pushd %{buildroot}%{_libdir}
ln -f libjackwrapper.so libjack.so
ln -f libjackwrapper.so libjack.so.0
popd



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Fri, 2008-03-14 at 17:05 -0700, Fernando Lopez-Lezcano wrote:

> On Fri, 2008-03-14 at 12:24 -0700, Fernando Lopez-Lezcano wrote:
> > On Fri, 2008-03-14 at 19:51 +0100, Stéphane Letz wrote:
> > > > in ../common/ (at least in my case), etc, etc. I'm reworking things to
> > > > do what I think is the right think just to make a package to test...
> > >
> > > Another point: how will the package system would work? Does the  
> > > following would make sense?
> > >
> > > - jackd package install as before
> > >
> > > -if jackdmp if installed on a system where jackd is already  
> > > installed, then the "wrapper" library should be used
> > >
> > > - otherwise if jackdmp is installed on a fresh system, then real  
> > > libjackmp library should be used and the libjack.so link created  
> > > accordingly.
> >
> > Right now I'm trying to build a package that includes both of them. It
> > is the easiest approach.
>
> Finally works! (jackd / jackdmp in one package that includes the wrapper
> library). I had to ignore some of the stuff in the wrapper install
> target in the makefile.
>
> this what I did in the spec file install script, this is after a cd
> to the linux subdirectory, %buildroot is in /var/tmp and is a "virtual
> install root that is not /":
>
> # do the installwrapper install by hand, the script is just wrong...
> cp jackdmp %{buildroot}%{_prefix}/bin
> cp ../common/libjackmp.so %{buildroot}%{_libdir}
> cp ../common/libjackservermp.so %{buildroot}%{_libdir}
> cp ../common/libjackwrapper.so %{buildroot}%{_libdir}
> # install the jackmp libraries
> install -d %{buildroot}%{_libdir}/jackmp/
> cp libjack_alsa.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_alsa.so
> cp libjack_dummy.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_dummy.so
> cp libjack_freebob.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_freebob.so
> # (re)install the headers
> rm -rf %{buildroot}%{_includedir}/jack
> install -d %{buildroot}%{_includedir}/jack/
> cp ../common/jack/*.h %{buildroot}%{_includedir}/jack/
> # relink the libraries to the wrapper, symbolic links will not do
> # as the .so.0 link is recreated by ldoconfig to point to the
> # original jackd library and clients can't connect
> rm -f %{buildroot}%{_libdir}/libjack.so
> rm -f %{buildroot}%{_libdir}/libjack.so.0
> pushd %{buildroot}%{_libdir}
> ln -f libjackwrapper.so libjack.so
> ln -f libjackwrapper.so libjack.so.0

This does not really work, at least not in all cases. Most probably
something needs to be changed in the jack build and/or install process.
This is what happens:

On Fedora 6 things work fine with the hard links (probably because of an
older ldconfig).

On Fedora 7 if I create hard links for the wrapper library as above,
ldconfig complains when run that libjack.so.0 is a hard link. It is
(apparently) just a warning, but I think there should not be any
warnings. If I change the link (from libjack.so.0 to the wrapper) to be
a symbolic link ldconfig does not complain any more, but it silently
switches the link back to libjack.so.0.0.28 when run, and breaks all
jack clients.

Any suggestions on how to fix this??

I imagine this is something that needs to be changed when the original
jack is installed (what knows that the link should point to libjack?)

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Sun, 2008-03-16 at 18:30 -0700, Fernando Lopez-Lezcano wrote:

> On Fri, 2008-03-14 at 17:05 -0700, Fernando Lopez-Lezcano wrote:
> > On Fri, 2008-03-14 at 12:24 -0700, Fernando Lopez-Lezcano wrote:
> > > On Fri, 2008-03-14 at 19:51 +0100, Stéphane Letz wrote:
> > > > > in ../common/ (at least in my case), etc, etc. I'm reworking things to
> > > > > do what I think is the right think just to make a package to test...
> > > >
> > > > Another point: how will the package system would work? Does the  
> > > > following would make sense?
> > > >
> > > > - jackd package install as before
> > > >
> > > > -if jackdmp if installed on a system where jackd is already  
> > > > installed, then the "wrapper" library should be used
> > > >
> > > > - otherwise if jackdmp is installed on a fresh system, then real  
> > > > libjackmp library should be used and the libjack.so link created  
> > > > accordingly.
> > >
> > > Right now I'm trying to build a package that includes both of them. It
> > > is the easiest approach.
> >
> > Finally works! (jackd / jackdmp in one package that includes the wrapper
> > library). I had to ignore some of the stuff in the wrapper install
> > target in the makefile.
> >
> > this what I did in the spec file install script, this is after a cd
> > to the linux subdirectory, %buildroot is in /var/tmp and is a "virtual
> > install root that is not /":
> >
> > # do the installwrapper install by hand, the script is just wrong...
> > cp jackdmp %{buildroot}%{_prefix}/bin
> > cp ../common/libjackmp.so %{buildroot}%{_libdir}
> > cp ../common/libjackservermp.so %{buildroot}%{_libdir}
> > cp ../common/libjackwrapper.so %{buildroot}%{_libdir}
> > # install the jackmp libraries
> > install -d %{buildroot}%{_libdir}/jackmp/
> > cp libjack_alsa.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_alsa.so
> > cp libjack_dummy.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_dummy.so
> > cp libjack_freebob.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_freebob.so
> > # (re)install the headers
> > rm -rf %{buildroot}%{_includedir}/jack
> > install -d %{buildroot}%{_includedir}/jack/
> > cp ../common/jack/*.h %{buildroot}%{_includedir}/jack/
> > # relink the libraries to the wrapper, symbolic links will not do
> > # as the .so.0 link is recreated by ldoconfig to point to the
> > # original jackd library and clients can't connect
> > rm -f %{buildroot}%{_libdir}/libjack.so
> > rm -f %{buildroot}%{_libdir}/libjack.so.0
> > pushd %{buildroot}%{_libdir}
> > ln -f libjackwrapper.so libjack.so
> > ln -f libjackwrapper.so libjack.so.0
>
> This does not really work, at least not in all cases. Most probably
> something needs to be changed in the jack build and/or install process.
> This is what happens:
>
> On Fedora 6 things work fine with the hard links (probably because of an
> older ldconfig).
>
> On Fedora 7 if I create hard links for the wrapper library as above,
> ldconfig complains when run that libjack.so.0 is a hard link. It is
> (apparently) just a warning, but I think there should not be any
> warnings. If I change the link (from libjack.so.0 to the wrapper) to be
> a symbolic link ldconfig does not complain any more, but it silently
> switches the link back to libjack.so.0.0.28 when run, and breaks all
> jack clients.

Looks like libtool is the one setting this at compile time (with the
"soname" option). Don't see how to work around the problem, but then I
don't know much about the lib* tools.

It would seem to me that the original jack library (owned by the jack
package) needs its name to be changed - unless there is some werird
libtool workaround, of course. Then libwrapper can then be named
libjack.* directly and will reference the real libjack with its new
name.

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Sun, 2008-03-16 at 19:51 -0700, Fernando Lopez-Lezcano wrote:

> On Sun, 2008-03-16 at 18:30 -0700, Fernando Lopez-Lezcano wrote:
> > On Fri, 2008-03-14 at 17:05 -0700, Fernando Lopez-Lezcano wrote:
> > > On Fri, 2008-03-14 at 12:24 -0700, Fernando Lopez-Lezcano wrote:
> > > > On Fri, 2008-03-14 at 19:51 +0100, Stéphane Letz wrote:
> > > > > > in ../common/ (at least in my case), etc, etc. I'm reworking things to
> > > > > > do what I think is the right think just to make a package to test...
> > > > >
> > > > > Another point: how will the package system would work? Does the  
> > > > > following would make sense?
> > > > >
> > > > > - jackd package install as before
> > > > >
> > > > > -if jackdmp if installed on a system where jackd is already  
> > > > > installed, then the "wrapper" library should be used
> > > > >
> > > > > - otherwise if jackdmp is installed on a fresh system, then real  
> > > > > libjackmp library should be used and the libjack.so link created  
> > > > > accordingly.
> > > >
> > > > Right now I'm trying to build a package that includes both of them. It
> > > > is the easiest approach.
> > >
> > > Finally works! (jackd / jackdmp in one package that includes the wrapper
> > > library). I had to ignore some of the stuff in the wrapper install
> > > target in the makefile.
> > >
> > > this what I did in the spec file install script, this is after a cd
> > > to the linux subdirectory, %buildroot is in /var/tmp and is a "virtual
> > > install root that is not /":
> > >
> > > # do the installwrapper install by hand, the script is just wrong...
> > > cp jackdmp %{buildroot}%{_prefix}/bin
> > > cp ../common/libjackmp.so %{buildroot}%{_libdir}
> > > cp ../common/libjackservermp.so %{buildroot}%{_libdir}
> > > cp ../common/libjackwrapper.so %{buildroot}%{_libdir}
> > > # install the jackmp libraries
> > > install -d %{buildroot}%{_libdir}/jackmp/
> > > cp libjack_alsa.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_alsa.so
> > > cp libjack_dummy.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_dummy.so
> > > cp libjack_freebob.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_freebob.so
> > > # (re)install the headers
> > > rm -rf %{buildroot}%{_includedir}/jack
> > > install -d %{buildroot}%{_includedir}/jack/
> > > cp ../common/jack/*.h %{buildroot}%{_includedir}/jack/
> > > # relink the libraries to the wrapper, symbolic links will not do
> > > # as the .so.0 link is recreated by ldoconfig to point to the
> > > # original jackd library and clients can't connect
> > > rm -f %{buildroot}%{_libdir}/libjack.so
> > > rm -f %{buildroot}%{_libdir}/libjack.so.0
> > > pushd %{buildroot}%{_libdir}
> > > ln -f libjackwrapper.so libjack.so
> > > ln -f libjackwrapper.so libjack.so.0
> >
> > This does not really work, at least not in all cases. Most probably
> > something needs to be changed in the jack build and/or install process.
> > This is what happens:
> >
> > On Fedora 6 things work fine with the hard links (probably because of an
> > older ldconfig).
> >
> > On Fedora 7 if I create hard links for the wrapper library as above,
> > ldconfig complains when run that libjack.so.0 is a hard link. It is
> > (apparently) just a warning, but I think there should not be any
> > warnings. If I change the link (from libjack.so.0 to the wrapper) to be
> > a symbolic link ldconfig does not complain any more, but it silently
> > switches the link back to libjack.so.0.0.28 when run, and breaks all
> > jack clients.
>
> Looks like libtool is the one setting this at compile time (with the
> "soname" option). Don't see how to work around the problem, but then I
> don't know much about the lib* tools.

One hack that seems to work is to change (force) soname_spec in the
libtool script that is used to link libjack to point to
libjackwrapper.so (making a copy of the original libtool to libjack/ and
replacing soname_spec there before the make call).

With that ugly hack I get packages that seem to install and work fine
using the proper symbolic links from libjack to libjackwrapper.

Surely somebody else has a nice and neat solution to this problem...
Please? :-)
-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Stéphane Letz

Le 17 mars 08 à 20:33, Fernando Lopez-Lezcano a écrit :

> On Sun, 2008-03-16 at 19:51 -0700, Fernando Lopez-Lezcano wrote:
>> On Sun, 2008-03-16 at 18:30 -0700, Fernando Lopez-Lezcano wrote:
>>> On Fri, 2008-03-14 at 17:05 -0700, Fernando Lopez-Lezcano wrote:
>>>> On Fri, 2008-03-14 at 12:24 -0700, Fernando Lopez-Lezcano wrote:
>>>>> On Fri, 2008-03-14 at 19:51 +0100, Stéphane Letz wrote:
>>>>>>> in ../common/ (at least in my case), etc, etc. I'm reworking  
>>>>>>> things to
>>>>>>> do what I think is the right think just to make a package to  
>>>>>>> test...
>>>>>>
>>>>>> Another point: how will the package system would work? Does the
>>>>>> following would make sense?
>>>>>>
>>>>>> - jackd package install as before
>>>>>>
>>>>>> -if jackdmp if installed on a system where jackd is already
>>>>>> installed, then the "wrapper" library should be used
>>>>>>
>>>>>> - otherwise if jackdmp is installed on a fresh system, then real
>>>>>> libjackmp library should be used and the libjack.so link created
>>>>>> accordingly.
>>>>>
>>>>> Right now I'm trying to build a package that includes both of  
>>>>> them. It
>>>>> is the easiest approach.
>>>>
>>>> Finally works! (jackd / jackdmp in one package that includes the  
>>>> wrapper
>>>> library). I had to ignore some of the stuff in the wrapper install
>>>> target in the makefile.
>>>>
>>>> this what I did in the spec file install script, this is after a cd
>>>> to the linux subdirectory, %buildroot is in /var/tmp and is a  
>>>> "virtual
>>>> install root that is not /":
>>>>
>>>> # do the installwrapper install by hand, the script is just  
>>>> wrong...
>>>> cp jackdmp %{buildroot}%{_prefix}/bin
>>>> cp ../common/libjackmp.so %{buildroot}%{_libdir}
>>>> cp ../common/libjackservermp.so %{buildroot}%{_libdir}
>>>> cp ../common/libjackwrapper.so %{buildroot}%{_libdir}
>>>> # install the jackmp libraries
>>>> install -d %{buildroot}%{_libdir}/jackmp/
>>>> cp libjack_alsa.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_alsa.so
>>>> cp libjack_dummy.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_dummy.so
>>>> cp libjack_freebob.so.0.0 %{buildroot}%{_libdir}/jackmp/
>>>> jack_freebob.so
>>>> # (re)install the headers
>>>> rm -rf %{buildroot}%{_includedir}/jack
>>>> install -d %{buildroot}%{_includedir}/jack/
>>>> cp ../common/jack/*.h %{buildroot}%{_includedir}/jack/
>>>> # relink the libraries to the wrapper, symbolic links will not do
>>>> # as the .so.0 link is recreated by ldoconfig to point to the
>>>> # original jackd library and clients can't connect
>>>> rm -f %{buildroot}%{_libdir}/libjack.so
>>>> rm -f %{buildroot}%{_libdir}/libjack.so.0
>>>> pushd %{buildroot}%{_libdir}
>>>> ln -f libjackwrapper.so libjack.so
>>>> ln -f libjackwrapper.so libjack.so.0
>>>
>>> This does not really work, at least not in all cases. Most probably
>>> something needs to be changed in the jack build and/or install  
>>> process.
>>> This is what happens:
>>>
>>> On Fedora 6 things work fine with the hard links (probably because  
>>> of an
>>> older ldconfig).
>>>
>>> On Fedora 7 if I create hard links for the wrapper library as above,
>>> ldconfig complains when run that libjack.so.0 is a hard link. It is
>>> (apparently) just a warning, but I think there should not be any
>>> warnings. If I change the link (from libjack.so.0 to the wrapper)  
>>> to be
>>> a symbolic link ldconfig does not complain any more, but it silently
>>> switches the link back to libjack.so.0.0.28 when run, and breaks all
>>> jack clients.
>>
>> Looks like libtool is the one setting this at compile time (with the
>> "soname" option). Don't see how to work around the problem, but  
>> then I
>> don't know much about the lib* tools.
>
> One hack that seems to work is to change (force) soname_spec in the
> libtool script that is used to link libjack to point to
> libjackwrapper.so (making a copy of the original libtool to libjack/  
> and
> replacing soname_spec there before the make call).
>
> With that ugly hack I get packages that seem to install and work fine
> using the proper symbolic links from libjack to libjackwrapper.

Could you send me a patch so that I can test?
>
>
> Surely somebody else has a nice and neat solution to this problem...
> Please? :-)
> -- Fernando

The thing is that my experience in autotools stuff is quite poor....

Stephane


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Tue, 2008-03-18 at 08:56 +0100, Stéphane Letz wrote:

> Le 17 mars 08 à 20:33, Fernando Lopez-Lezcano a écrit :
> > On Sun, 2008-03-16 at 19:51 -0700, Fernando Lopez-Lezcano wrote:
> >> On Sun, 2008-03-16 at 18:30 -0700, Fernando Lopez-Lezcano wrote:
> >>> On Fri, 2008-03-14 at 17:05 -0700, Fernando Lopez-Lezcano wrote:
> >>>> On Fri, 2008-03-14 at 12:24 -0700, Fernando Lopez-Lezcano wrote:
> >>>>> On Fri, 2008-03-14 at 19:51 +0100, Stéphane Letz wrote:
> >>>>>>> in ../common/ (at least in my case), etc, etc. I'm reworking  
> >>>>>>> things to
> >>>>>>> do what I think is the right think just to make a package to  
> >>>>>>> test...
> >>>>>>
> >>>>>> Another point: how will the package system would work? Does the
> >>>>>> following would make sense?
> >>>>>>
> >>>>>> - jackd package install as before
> >>>>>>
> >>>>>> -if jackdmp if installed on a system where jackd is already
> >>>>>> installed, then the "wrapper" library should be used
> >>>>>>
> >>>>>> - otherwise if jackdmp is installed on a fresh system, then real
> >>>>>> libjackmp library should be used and the libjack.so link created
> >>>>>> accordingly.
> >>>>>
> >>>>> Right now I'm trying to build a package that includes both of  
> >>>>> them. It
> >>>>> is the easiest approach.
> >>>>
> >>>> Finally works! (jackd / jackdmp in one package that includes the  
> >>>> wrapper
> >>>> library). I had to ignore some of the stuff in the wrapper install
> >>>> target in the makefile.
> >>>>
> >>>> this what I did in the spec file install script, this is after a cd
> >>>> to the linux subdirectory, %buildroot is in /var/tmp and is a  
> >>>> "virtual
> >>>> install root that is not /":
> >>>>
> >>>> # do the installwrapper install by hand, the script is just  
> >>>> wrong...
> >>>> cp jackdmp %{buildroot}%{_prefix}/bin
> >>>> cp ../common/libjackmp.so %{buildroot}%{_libdir}
> >>>> cp ../common/libjackservermp.so %{buildroot}%{_libdir}
> >>>> cp ../common/libjackwrapper.so %{buildroot}%{_libdir}
> >>>> # install the jackmp libraries
> >>>> install -d %{buildroot}%{_libdir}/jackmp/
> >>>> cp libjack_alsa.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_alsa.so
> >>>> cp libjack_dummy.so.0.0 %{buildroot}%{_libdir}/jackmp/jack_dummy.so
> >>>> cp libjack_freebob.so.0.0 %{buildroot}%{_libdir}/jackmp/
> >>>> jack_freebob.so
> >>>> # (re)install the headers
> >>>> rm -rf %{buildroot}%{_includedir}/jack
> >>>> install -d %{buildroot}%{_includedir}/jack/
> >>>> cp ../common/jack/*.h %{buildroot}%{_includedir}/jack/
> >>>> # relink the libraries to the wrapper, symbolic links will not do
> >>>> # as the .so.0 link is recreated by ldoconfig to point to the
> >>>> # original jackd library and clients can't connect
> >>>> rm -f %{buildroot}%{_libdir}/libjack.so
> >>>> rm -f %{buildroot}%{_libdir}/libjack.so.0
> >>>> pushd %{buildroot}%{_libdir}
> >>>> ln -f libjackwrapper.so libjack.so
> >>>> ln -f libjackwrapper.so libjack.so.0
> >>>
> >>> This does not really work, at least not in all cases. Most probably
> >>> something needs to be changed in the jack build and/or install  
> >>> process.
> >>> This is what happens:
> >>>
> >>> On Fedora 6 things work fine with the hard links (probably because  
> >>> of an
> >>> older ldconfig).
> >>>
> >>> On Fedora 7 if I create hard links for the wrapper library as above,
> >>> ldconfig complains when run that libjack.so.0 is a hard link. It is
> >>> (apparently) just a warning, but I think there should not be any
> >>> warnings. If I change the link (from libjack.so.0 to the wrapper)  
> >>> to be
> >>> a symbolic link ldconfig does not complain any more, but it silently
> >>> switches the link back to libjack.so.0.0.28 when run, and breaks all
> >>> jack clients.
> >>
> >> Looks like libtool is the one setting this at compile time (with the
> >> "soname" option). Don't see how to work around the problem, but  
> >> then I
> >> don't know much about the lib* tools.
> >
> > One hack that seems to work is to change (force) soname_spec in the
> > libtool script that is used to link libjack to point to
> > libjackwrapper.so (making a copy of the original libtool to libjack/  
> > and replacing soname_spec there before the make call).
> >
> > With that ugly hack I get packages that seem to install and work fine
> > using the proper symbolic links from libjack to libjackwrapper.
>
> Could you send me a patch so that I can test?

It is not really a patch but this is what I am using in my test packages
(this is done just after the configure call and before the make - it
also includes the fix I'm using for building with dynamic cpu
detection):

--------
# add sse flags only to the simd compilation incantation
perl -p -i -e "s|-MT libjack_la-simd.lo|-msse -msse2 -m3dnow -MT
libjack_la-simd.lo|g" libjack/Makefile
perl -p -i -e "s|-MT libjackserver_la-simd.lo|-msse -msse2 -m3dnow -MT
libjackserver_la-simd.lo|g" jackd/Makefile

# really ugly hack to avoid relinking problems with ldconfig we don't
# want the libjack soname mentioned in the link process just for the
# alsa client library, so we just hack it out of the libtool script and
# replace it with libjackwrapper.
cp -p libtool libjack/libtool
perl -p -i -e 's|\$\(top_builddir\)/libtool|./libtool|g'
libjack/Makefile
perl -p -i -e 's|soname_spec=\"\\\${libname}\\\${release}\\\
${shared_ext}\\\$major\"|soname_spec=\"libjackwrapper.so\"|g'
libjack/libtool
--------

as I said, I should not be posting such bad fixes but well, experts can
later do the right thing :-) This copies the generated libtool and hacks
it only for linking libjack, all other libraries are left alone.

I'll probably release "testing" packages so that more Planet CCRMA users
can try this out, even with the hack (which does not seem to have any
undesirable side effects I can detect).

-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test : SMID code compilation issue

Stéphane Letz
>>>
>>
>> Could you send me a patch so that I can test?
>
> It is not really a patch but this is what I am using in my test  
> packages
> (this is done just after the configure call and before the make - it
> also includes the fix I'm using for building with dynamic cpu
> detection):
>
> --------
> # add sse flags only to the simd compilation incantation
> perl -p -i -e "s|-MT libjack_la-simd.lo|-msse -msse2 -m3dnow -MT
> libjack_la-simd.lo|g" libjack/Makefile
> perl -p -i -e "s|-MT libjackserver_la-simd.lo|-msse -msse2 -m3dnow -MT
> libjackserver_la-simd.lo|g" jackd/Makefile


Concerning SIMD code, it seems that it has been broken since several  
versions:
the ./configure --enable-dynsimd  && make also fails on 0.100.7 and  
0.109.2  ))):

Is the person who did that still on the list??

>
>
> # really ugly hack to avoid relinking problems with ldconfig we don't
> # want the libjack soname mentioned in the link process just for the
> # alsa client library, so we just hack it out of the libtool script  
> and
> # replace it with libjackwrapper.
> cp -p libtool libjack/libtool
> perl -p -i -e 's|\$\(top_builddir\)/libtool|./libtool|g'
> libjack/Makefile
> perl -p -i -e 's|soname_spec=\"\\\${libname}\\\${release}\\\
> ${shared_ext}\\\$major\"|soname_spec=\"libjackwrapper.so\"|g'
> libjack/libtool
> --------
>
> as I said, I should not be posting such bad fixes but well, experts  
> can
> later do the right thing :-) This copies the generated libtool and  
> hacks
> it only for linking libjack, all other libraries are left alone.

Hopefully yes!

>
>
> I'll probably release "testing" packages so that more Planet CCRMA  
> users
> can try this out, even with the hack (which does not seem to have any
> undesirable side effects I can detect).
>
> -- Fernando
>
>

I recently added the midi API code in the wrapper library. It was just  
missing... bot not tested.

Stephane


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test : SMID code compilation issue

j4nKy
On Wed, Mar 19, 2008 at 10:54:17AM +0100, St?phane Letz wrote:

> >>>
> >>
> >> Could you send me a patch so that I can test?
> >
> > It is not really a patch but this is what I am using in my test  
> > packages
> > (this is done just after the configure call and before the make - it
> > also includes the fix I'm using for building with dynamic cpu
> > detection):
> >
> > --------
> > # add sse flags only to the simd compilation incantation
> > perl -p -i -e "s|-MT libjack_la-simd.lo|-msse -msse2 -m3dnow -MT
> > libjack_la-simd.lo|g" libjack/Makefile
> > perl -p -i -e "s|-MT libjackserver_la-simd.lo|-msse -msse2 -m3dnow -MT
> > libjackserver_la-simd.lo|g" jackd/Makefile

I just ran into a similar problem with configure.  one problem is that
--enable-optimization-by-cpu sets a variable name
$enable_optimization_by_cpu, but the tests check a variable called
$optimization_by_cpu (enable_ is missing from the name, same with
--enable-optimization-by-compiler, but that option doesn't do anything
at all).  the other problem is that the --enable-sse option tries to
be clever and use $enable_mmx as it's default value.  however, that
doesn't work, because $enable_mmx doesn't always have a value!

also, $JACK_CFLAGS gets added to $CFLAGS, and then both $JACK_CFLAGS
and $CFLAGS are used t compile.  not really a problem, but it is
definitely redundant and sorta confusing.

inlined part of a patch for these things (patch is hand edited, so
may not apply.  should point out the problems though), hopefully it will
help you.

> Concerning SIMD code, it seems that it has been broken since several  
> versions:
> the ./configure --enable-dynsimd  && make also fails on 0.100.7 and  
> 0.109.2  ))):

hmm, works for me in a current svn build.


--
[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org

--- configure.ac.orig Fri Mar 14 09:02:59 2008
+++ configure.ac Tue Mar 18 03:42:20 2008
@@ -216,9 +226,8 @@ AM_CONDITIONAL(USE_POSIX_SHM, $USE_POSIX_SHM)
 
 JACK_CORE_CFLAGS="-I\$(top_srcdir)/config -I\$(top_srcdir) \
 -I\$(top_srcdir) -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g"
-JACK_OPT_CFLAGS="$JACK_CORE_CFLAGS -march=pentium2 -mcpu=pentium4 -O3 \
--ffast-math -funroll-loops -fprefetch-loop-arrays"
-JACK_CFLAGS="$JACK_CORE_CFLAGS $CFLAGS"
+JACK_OPT_CFLAGS="-ffast-math -funroll-loops -fprefetch-loop-arrays"
+CFLAGS="$JACK_CORE_CFLAGS $CFLAGS"
 
 dnl
 dnl figure out how best to optimize
@@ -273,13 +286,13 @@ elif echo $target_cpu | egrep '(i.86|x86_64)' >/dev/nu
     fi
     
     AC_ARG_ENABLE(optimization-by-compiler,
- [  --enable-optimization-by-compiler  use compiler (NOT processor) capabilities to determine optimization flags],,
- optimization_by_compiler=no
+ [  --enable-optimization-by-compiler  use compiler (NOT processor) capabilities to determine optimization flags],[],
+ enable_optimization_by_compiler=no
     )
     
     AC_ARG_ENABLE(optimization-by-cpu,
- [  --enable-optimization-by-cpu  use processor capabilities to determine optimization flags],,
- optimization_by_cpu=yes
+ [  --enable-optimization-by-cpu  use processor capabilities to determine optimization flags],[],
+ enable_optimization_by_cpu=yes
     )
     
     AC_ARG_ENABLE(mmx,
@@ -302,7 +327,7 @@ elif echo $target_cpu | egrep '(i.86|x86_64)' >/dev/nu
     AC_DEFINE(USE_MMX, 1, [Define to 1 if MMX assembly is available.])
     AC_MSG_RESULT(yes)
     
-    if test x$optimization_by_cpu = xyes ; then
+    if test x$enable_optimization_by_cpu = xyes ; then
  if test x$cpu_supports_mmx = xyes ; then
     MMX_FLAGS="-mmmx"
  fi
@@ -326,7 +351,7 @@ elif echo $target_cpu | egrep '(i.86|x86_64)' >/dev/nu
     AC_DEFINE(USE_SSE, 1,
  [Define to 1 if SSE assembly is available.])
     
-    if test x$optimization_by_cpu = xyes ; then
+    if test x$enable_optimization_by_cpu = xyes ; then
  if test x$cpu_supports_sse = xyes ; then
     SSE_FLAGS="-msse -mfpmath=sse"
  fi
@@ -373,7 +398,7 @@ AC_ARG_ENABLE(optimize,
     AC_HELP_STRING([--enable-optimize],
  [ask the compiler for its best optimizations]),
     [ if test x$enable_optimize != xno ; then
- JACK_CFLAGS="$JACK_CORE_CFLAGS $JACK_OPT_CFLAGS"
+ CFLAGS="$CFLAGS $JACK_OPT_CFLAGS"
  AC_MSG_WARN([optimization in use.........................])
       else
  JACK_OPT_CFLAGS=""
@@ -382,13 +407,13 @@ AC_ARG_ENABLE(optimize,
     ]
 )
 
-AC_SUBST(JACK_CFLAGS)
+dnl AC_SUBST(JACK_CFLAGS)
 
 dnl
 dnl use JACK_CFLAGS for jackd compilation
 dnl
 
-CFLAGS=$JACK_CFLAGS
+dnl CFLAGS=$JACK_CFLAGS
 
 # allow buffer resizing unless --disable-resize specified
 buffer_resizing=yes

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
In reply to this post by Fernando Lopez-Lezcano
On Tue, 2008-03-18 at 10:43 -0700, Fernando Lopez-Lezcano wrote:

> On Tue, 2008-03-18 at 08:56 +0100, Stéphane Letz wrote:
> > Le 17 mars 08 à 20:33, Fernando Lopez-Lezcano a écrit :
> > With that ugly hack I get packages that seem to install and work fine
> > > using the proper symbolic links from libjack to libjackwrapper.
> >
> > Could you send me a patch so that I can test?
>
> It is not really a patch but this is what I am using in my test packages
> (this is done just after the configure call and before the make - it
> also includes the fix I'm using for building with dynamic cpu
> detection):
>
> --------
> # really ugly hack to avoid relinking problems with ldconfig we don't
> # want the libjack soname mentioned in the link process just for the
> # alsa client library, so we just hack it out of the libtool script and
> # replace it with libjackwrapper.
> cp -p libtool libjack/libtool
> perl -p -i -e 's|\$\(top_builddir\)/libtool|./libtool|g'
> libjack/Makefile
> perl -p -i -e 's|soname_spec=\"\\\${libname}\\\${release}\\\
> ${shared_ext}\\\$major\"|soname_spec=\"libjackwrapper.so\"|g'
> libjack/libtool
> --------
>
> as I said, I should not be posting such bad fixes but well, experts can
> later do the right thing :-) This copies the generated libtool and hacks
> it only for linking libjack, all other libraries are left alone.
>
> I'll probably release "testing" packages so that more Planet CCRMA users
> can try this out, even with the hack (which does not seem to have any
> undesirable side effects I can detect).

Well, I managed to build testing packages, but I had to work around
another packaging related side effect. As libjack.so and libjack.so.0
are now somehow only links they are not automatically detected by the
package build process as "libraries" and are not "provided" by the
package - I can work around that by providing them manually, but it is
yet another hack.

This is all indicating that this approach is not really working well.

I feel strongly that this is what needs to happen:

"libjack" needs to be what "libwrapper" is now. I mean, the _name_ of
the wrapper library has to be "libjack", not "libwrapper" with a couple
of ad hoc links. The _real_ jack library has to be renamed to something
else, like "libjackup" :-), so it does not conflict with the wrapper, in
much the same way that jackmp's library is named differently. And the
wrapper libjack will know both names so no problem there.

If that is done then all the hacks and contortions I had to do to get
this packaged dissapear.

Comments?
-- Fernando



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

juuso.alasuutari (Bugzilla)
Fernando Lopez-Lezcano wrote:

> This is all indicating that this approach is not really working well.
>
> I feel strongly that this is what needs to happen:
>
> "libjack" needs to be what "libwrapper" is now. I mean, the _name_ of
> the wrapper library has to be "libjack", not "libwrapper" with a couple
> of ad hoc links. The _real_ jack library has to be renamed to something
> else, like "libjackup" :-), so it does not conflict with the wrapper, in
> much the same way that jackmp's library is named differently. And the
> wrapper libjack will know both names so no problem there.
>
> If that is done then all the hacks and contortions I had to do to get
> this packaged dissapear.
>
> Comments?
> -- Fernando

I think this idea of renaming the real JACK library to "libjackass"
(lib-JACK-associate ;)) could work.

BTW, is the jackwrapper lib supposed to be only included in jackdmp?
Perhaps it would be good to create a separate libjackwrapper package
which would be required for any JACK install. (Or is this not a new idea?)

Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd/jackdmp switch layer to test

Fernando Lopez-Lezcano
On Wed, 2008-03-19 at 20:45 +0200, Juuso Alasuutari wrote:

> Fernando Lopez-Lezcano wrote:
> > This is all indicating that this approach is not really working well.
> >
> > I feel strongly that this is what needs to happen:
> >
> > "libjack" needs to be what "libwrapper" is now. I mean, the _name_ of
> > the wrapper library has to be "libjack", not "libwrapper" with a couple
> > of ad hoc links. The _real_ jack library has to be renamed to something
> > else, like "libjackup" :-), so it does not conflict with the wrapper, in
> > much the same way that jackmp's library is named differently. And the
> > wrapper libjack will know both names so no problem there.
> >
> > If that is done then all the hacks and contortions I had to do to get
> > this packaged dissapear.
> >
> > Comments?
>
> I think this idea of renaming the real JACK library to "libjackass"
> (lib-JACK-associate ;)) could work.
>
> BTW, is the jackwrapper lib supposed to be only included in jackdmp?
> Perhaps it would be good to create a separate libjackwrapper package
> which would be required for any JACK install. (Or is this not a new idea?)

Yes, that is exactly what should happen (or something similar).

-- Fernando

PS: earlier on this thread, but at the time I was not dealing yet with
the hacks I'm referring to:

On Fri, 2008-03-14 at 12:24 -0700, Fernando Lopez-Lezcano wrote:
> I imagine the best system would be to have a "jack-libwrapper" package
> that is required by both the "jack-audio-connection-kit" and the
> "jackdmp" packages. Ie: installing either will automatically install
> jack-libwrapper and no package modifies files owned by another package.
> So, both normal jackd and jackdmp go through libwrapper all the time.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
12