[yocto] RPM Packaging
Hi, I want to create custom rpm packages for the iMX6Q device (cortexa9hf-vfp-neon-mx6). I have to create two types of packages: either pre-built arm binaries to be packed or packages containing only bash scripts. There is no need of cross-compiling while packaging for my cases. I'm building the packages on my Ubuntu system. When I specify -> BuildArch: cortexa9hf-vfp-neon-mx6, and try to create a package (rpmbuild -ba SPECS/foo.spec), it complains "error: No compatible architectures found for build". For my case: rpm does not need to cross-compile but just do the packaging. How can I force rpm to believe the architecture that I'm specifying? Any inputs will be of help. Regards, Pj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RPM Packaging
Hi Prashant, This is wrong window to ask generic question. //Gaurang On Thu, Mar 26, 2015 at 12:51 PM, Prasant J wrote: > Hi, > > I want to create custom rpm packages for the iMX6Q device > (cortexa9hf-vfp-neon-mx6). I have to create two types of packages: > either pre-built arm binaries to be packed or packages containing only > bash scripts. There is no need of cross-compiling while packaging for > my cases. > > I'm building the packages on my Ubuntu system. When I specify -> > BuildArch: cortexa9hf-vfp-neon-mx6, and try to create a package > (rpmbuild -ba SPECS/foo.spec), it complains "error: No compatible > architectures found for build". > > For my case: rpm does not need to cross-compile but just do the > packaging. How can I force rpm to believe the architecture that I'm > specifying? > > Any inputs will be of help. > > > Regards, Pj > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] .rpm packaging weirdness of dynamic libraries
Hello. On the rootfs all of user added packages with dynamic libraries (/usr/lib) are missing the .so file soft link? If I check in the source folder in .libs created by libtool they are all there and links correctly. Eg. for the linx package: [git/lib/.libs]: ls -l liblinx* -rw-r--r-- 1 xxx rnd 46558 May 22 17:51 liblinx.a lrwxrwxrwx 1 xxx rnd13 May 22 17:51 liblinx.la -> ../liblinx.la -rw-r--r-- 1 xxx rnd 911 May 22 17:51 liblinx.lai lrwxrwxrwx 1 xxx rnd16 May 22 17:51 liblinx.so -> liblinx.so.0.0.0 lrwxrwxrwx 1 xxx rnd16 May 22 17:51 liblinx.so.0 -> liblinx.so.0.0.0 -rwxr-xr-x 1 xxx rnd 43883 May 22 17:51 liblinx.so.0.0.0 Also in the package folder everything looks ok [linx/1.0-r0/package]: ls -l usr/lib/liblinx* -rw-r--r-- 2 xxx rnd 46558 May 22 17:51 usr/lib/liblinx.a -rwxr-xr-x 2 xxx rnd 911 May 22 17:51 usr/lib/liblinx.la lrwxrwxrwx 1 xxx rnd16 May 22 17:51 usr/lib/liblinx.so -> liblinx.so.0.0.0 lrwxrwxrwx 1 xxx rnd16 May 22 17:51 usr/lib/liblinx.so.0 -> liblinx.so.0.0.0 -rwxr-xr-x 2 xxx rnd 10356 May 22 17:52 usr/lib/liblinx.so.0.0.0 But in the rpm, the libs are packaged incorrectly (or at least not as expected) [1.0-r0/deploy-rpms/cortexa9_vfp]: rpm -q -filesbypkg -p linx-1.0-r0.cortexa9_vfp.rpm warning: linx-1.0-r0.cortexa9_vfp.rpm: Header V4 DSA signature: NOKEY, key ID e747fcfb linx /etc linx /etc/linxdisc.conf linx /usr linx /usr/bin linx /usr/bin/linx_basic_client linx /usr/bin/linx_basic_server linx /usr/bin/linx_bmark linx /usr/bin/linxcfg linx /usr/bin/linxdisc linx /usr/bin/linxgwcmd linx /usr/bin/linxgws linx /usr/bin/linxstat linx /usr/bin/mkcmclcon linx /usr/bin/mkethcon linx /usr/bin/mkhdlccon linx /usr/bin/mklink linx /usr/bin/mkriocon linx /usr/bin/mkshmcon linx /usr/bin/mksriocon linx /usr/bin/mktcpcon linx /usr/bin/rmcmclcon linx /usr/bin/rmethcon linx /usr/bin/rmhdlccon linx /usr/bin/rmlink linx /usr/bin/rmriocon linx /usr/bin/rmshmcon linx /usr/bin/rmsriocon linx /usr/bin/rmtcpcon linx /usr/bin/uselgws linx /usr/lib linx /usr/lib/libcfg.so.0 linx /usr/lib/libcfg.so.0.0.0 linx /usr/lib/libgw.so.0 linx /usr/lib/libgw.so.0.0.0 linx /usr/lib/liblinx.so.0 linx /usr/lib/liblinx.so.0.0.0 linx /usr/lib/libusel_linx.so.0 linx /usr/lib/libusel_linx.so.0.0.0 As can be seen in the end, there are no .so files :(, only .so.0 pointing to the exact version of the library. Has this been observed before? Have we made something wrong in our .bb file that results in this abnormality? From what I know (and also from what some of our system software require) there should always be a plain .so file for dynamic library version(s) to work as expected. I am currently on poky/master, but this has been confirmed also on official danny releases. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On 23 May 2013 15:50, Hans Beckérus wrote: > But in the rpm, the libs are packaged incorrectly (or at least not as > expected) There (should) also be a linx-dev package, that contains the .so symlinks. .so symlink files are only needed at compilation time for properly versioned libraries. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 4:55 PM, Burton, Ross wrote: > On 23 May 2013 15:50, Hans Beckérus wrote: >> But in the rpm, the libs are packaged incorrectly (or at least not as >> expected) > > There (should) also be a linx-dev package, that contains the .so > symlinks. .so symlink files are only needed at compilation time for > properly versioned libraries. > > Ross Well, yes and no ;) If I look in /lib there are plenty of libraries that comes with .so files so it seems they are needed in some cases, right? Also, since part of our system software is doing loading of dynamic libraries themselves using dlopen() it is *very* hard to enforce removal of .so files since that piece of software does not know what particular version of the library it should use. It should load whatever .so points to, most commonly the latest version. So, is there some way for us to make sure .so files are also part of the .rpm? we do not wish to install the -dev variant since it also pollutes the system with a lot of other not needed stuff. Since /lib is having a lot of of .so files it must be possible, or? Actually, I have never seen a system that does not include also the .so files? Not even embedded ones. They are only soft links so flash/ram/disk space is not really an issue here. Hans On Thu, May 23, 2013 at 4:55 PM, Burton, Ross wrote: > On 23 May 2013 15:50, Hans Beckérus wrote: >> But in the rpm, the libs are packaged incorrectly (or at least not as >> expected) > > There (should) also be a linx-dev package, that contains the .so > symlinks. .so symlink files are only needed at compilation time for > properly versioned libraries. > > Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
Coming to think of it, since the .so requirement is only applicable to small subset of our libraries, I guess we could make an init script that creates the .so soft links according to what is currently the latest version on the system. Otherwise we would need to update the software doing dlopen() every time the library major version is stepped. Since that software is not under our complete control that could end up very difficult. Otherwise, I fully agree that the .so files should not really be needed if only ld is involved. Why can not things just be simple ;) Hans On Thu, May 23, 2013 at 5:25 PM, Hans Beckérus wrote: > On Thu, May 23, 2013 at 4:55 PM, Burton, Ross wrote: >> On 23 May 2013 15:50, Hans Beckérus wrote: >>> But in the rpm, the libs are packaged incorrectly (or at least not as >>> expected) >> >> There (should) also be a linx-dev package, that contains the .so >> symlinks. .so symlink files are only needed at compilation time for >> properly versioned libraries. >> >> Ross > Well, yes and no ;) If I look in /lib there are plenty of libraries > that comes with .so files so it seems they are needed in some cases, > right? Also, since part of our system software is doing loading of > dynamic libraries themselves using dlopen() it is *very* hard to > enforce removal of .so files since that piece of software does not > know what particular version of the library it should use. It should > load whatever .so points to, most commonly the latest version. So, is > there some way for us to make sure .so files are also part of the > .rpm? we do not wish to install the -dev variant since it also > pollutes the system with a lot of other not needed stuff. Since /lib > is having a lot of of .so files it must be possible, or? > Actually, I have never seen a system that does not include also the > .so files? Not even embedded ones. They are only soft links so > flash/ram/disk space is not really an issue here. > > Hans > > > On Thu, May 23, 2013 at 4:55 PM, Burton, Ross wrote: >> On 23 May 2013 15:50, Hans Beckérus wrote: >>> But in the rpm, the libs are packaged incorrectly (or at least not as >>> expected) >> >> There (should) also be a linx-dev package, that contains the .so >> symlinks. .so symlink files are only needed at compilation time for >> properly versioned libraries. >> >> Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On 23 May 2013 16:25, Hans Beckérus wrote: > Well, yes and no ;) If I look in /lib there are plenty of libraries > that comes with .so files so it seems they are needed in some cases, > right? Also, since part of our system software is doing loading of > dynamic libraries themselves using dlopen() it is *very* hard to > enforce removal of .so files since that piece of software does not > know what particular version of the library it should use. It should > load whatever .so points to, most commonly the latest version. So, is > there some way for us to make sure .so files are also part of the > .rpm? we do not wish to install the -dev variant since it also > pollutes the system with a lot of other not needed stuff. Since /lib > is having a lot of of .so files it must be possible, or? > Actually, I have never seen a system that does not include also the > .so files? Not even embedded ones. They are only soft links so > flash/ram/disk space is not really an issue here. *Every* mainstream linux distribution will not ship .so symlinks unless you've installed the development files, or they are needed for some reason (generally, the .so won't be a symlink in that case). If a particular library is designed to be unversioned and dlopen'd using a .so filename, then change the FILES as appropriate. If your package is dlopening arbitrary versioned libraries though libfoo.so filenames then you can either do more work and find the real name, or mess around with the packaging yourself. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 5:47 PM, Burton, Ross wrote: > On 23 May 2013 16:25, Hans Beckérus wrote: >> Well, yes and no ;) If I look in /lib there are plenty of libraries >> that comes with .so files so it seems they are needed in some cases, >> right? Also, since part of our system software is doing loading of >> dynamic libraries themselves using dlopen() it is *very* hard to >> enforce removal of .so files since that piece of software does not >> know what particular version of the library it should use. It should >> load whatever .so points to, most commonly the latest version. So, is >> there some way for us to make sure .so files are also part of the >> .rpm? we do not wish to install the -dev variant since it also >> pollutes the system with a lot of other not needed stuff. Since /lib >> is having a lot of of .so files it must be possible, or? >> Actually, I have never seen a system that does not include also the >> .so files? Not even embedded ones. They are only soft links so >> flash/ram/disk space is not really an issue here. > > *Every* mainstream linux distribution will not ship .so symlinks > unless you've installed the development files, or they are needed for > some reason (generally, the .so won't be a symlink in that case). If > a particular library is designed to be unversioned and dlopen'd using > a .so filename, then change the FILES as appropriate. If your package > is dlopening arbitrary versioned libraries though libfoo.so filenames > then you can either do more work and find the real name, or mess > around with the packaging yourself. > > Ross Sure. I am not questioning mainstream decision not to ship the .so symlinks. I most likely have never encountered real mainstream embedded systems before ;) Only home-brewed (we-can-do-it-ourselves) things. What I needed was some sort of pointer on how to handle the case when you do need to violate the mainstream rules :( I will play around with the FILES setting to see if it will get us were we need to be. I really do not wish to tamper with the packaging routines. It does what it does, with an obviously good reason too :P Thanks! Hans On Thu, May 23, 2013 at 5:47 PM, Burton, Ross wrote: > On 23 May 2013 16:25, Hans Beckérus wrote: >> Well, yes and no ;) If I look in /lib there are plenty of libraries >> that comes with .so files so it seems they are needed in some cases, >> right? Also, since part of our system software is doing loading of >> dynamic libraries themselves using dlopen() it is *very* hard to >> enforce removal of .so files since that piece of software does not >> know what particular version of the library it should use. It should >> load whatever .so points to, most commonly the latest version. So, is >> there some way for us to make sure .so files are also part of the >> .rpm? we do not wish to install the -dev variant since it also >> pollutes the system with a lot of other not needed stuff. Since /lib >> is having a lot of of .so files it must be possible, or? >> Actually, I have never seen a system that does not include also the >> .so files? Not even embedded ones. They are only soft links so >> flash/ram/disk space is not really an issue here. > > *Every* mainstream linux distribution will not ship .so symlinks > unless you've installed the development files, or they are needed for > some reason (generally, the .so won't be a symlink in that case). If > a particular library is designed to be unversioned and dlopen'd using > a .so filename, then change the FILES as appropriate. If your package > is dlopening arbitrary versioned libraries though libfoo.so filenames > then you can either do more work and find the real name, or mess > around with the packaging yourself. > > Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus wrote:
> On Thu, May 23, 2013 at 5:47 PM, Burton, Ross wrote:
>> On 23 May 2013 16:25, Hans Beckérus wrote:
>>> Well, yes and no ;) If I look in /lib there are plenty of libraries
>>> that comes with .so files so it seems they are needed in some cases,
>>> right? Also, since part of our system software is doing loading of
>>> dynamic libraries themselves using dlopen() it is *very* hard to
>>> enforce removal of .so files since that piece of software does not
>>> know what particular version of the library it should use. It should
>>> load whatever .so points to, most commonly the latest version. So, is
>>> there some way for us to make sure .so files are also part of the
>>> .rpm? we do not wish to install the -dev variant since it also
>>> pollutes the system with a lot of other not needed stuff. Since /lib
>>> is having a lot of of .so files it must be possible, or?
>>> Actually, I have never seen a system that does not include also the
>>> .so files? Not even embedded ones. They are only soft links so
>>> flash/ram/disk space is not really an issue here.
>>
>> *Every* mainstream linux distribution will not ship .so symlinks
>> unless you've installed the development files, or they are needed for
>> some reason (generally, the .so won't be a symlink in that case). If
>> a particular library is designed to be unversioned and dlopen'd using
>> a .so filename, then change the FILES as appropriate. If your package
>> is dlopening arbitrary versioned libraries though libfoo.so filenames
>> then you can either do more work and find the real name, or mess
>> around with the packaging yourself.
>>
>> Ross
>
> Sure. I am not questioning mainstream decision not to ship the .so
> symlinks. I most likely have never encountered real mainstream
> embedded systems before ;) Only home-brewed (we-can-do-it-ourselves)
> things. What I needed was some sort of pointer on how to handle the
> case when you do need to violate the mainstream rules :(
> I will play around with the FILES setting to see if it will get us
> were we need to be. I really do not wish to tamper with the packaging
> routines. It does what it does, with an obviously good reason too :P
>
> Thanks!
> Hans
>
>
Hmm. I tried the FILES trick, but either I am doing something wrong or
FILES does not really affect whats getting into the .rpm? This is what
I tried in our recipe
FILES_${PN} += " ${exec_prefix}/usr/lib/libelinx.so"
FILES_${PN} += " ${exec_prefix}/usr/lib/libepmq.so"
But I see now that dev RPM in addition to the normal RPM is what we
need besides the .la files but I think we we can live with that ;) Is
there some simple/clever trick to have both the standard and the dev
RPM being installed on the rootfs?
Hans
On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus wrote:
> On Thu, May 23, 2013 at 5:47 PM, Burton, Ross wrote:
>> On 23 May 2013 16:25, Hans Beckérus wrote:
>>> Well, yes and no ;) If I look in /lib there are plenty of libraries
>>> that comes with .so files so it seems they are needed in some cases,
>>> right? Also, since part of our system software is doing loading of
>>> dynamic libraries themselves using dlopen() it is *very* hard to
>>> enforce removal of .so files since that piece of software does not
>>> know what particular version of the library it should use. It should
>>> load whatever .so points to, most commonly the latest version. So, is
>>> there some way for us to make sure .so files are also part of the
>>> .rpm? we do not wish to install the -dev variant since it also
>>> pollutes the system with a lot of other not needed stuff. Since /lib
>>> is having a lot of of .so files it must be possible, or?
>>> Actually, I have never seen a system that does not include also the
>>> .so files? Not even embedded ones. They are only soft links so
>>> flash/ram/disk space is not really an issue here.
>>
>> *Every* mainstream linux distribution will not ship .so symlinks
>> unless you've installed the development files, or they are needed for
>> some reason (generally, the .so won't be a symlink in that case). If
>> a particular library is designed to be unversioned and dlopen'd using
>> a .so filename, then change the FILES as appropriate. If your package
>> is dlopening arbitrary versioned libraries though libfoo.so filenames
>> then you can either do more work and find the real name, or mess
>> around with the packaging yourself.
>>
>> Ross
>
> Sure. I am not questioning mainstream decision not to ship the .so
> symlinks. I most likely have never encountered real mainstream
> embedded systems before ;) Only home-brewed (we-can-do-it-ourselves)
> things. What I needed was some sort of pointer on how to handle the
> case when you do need to violate the mainstream rules :(
> I will play around with the FILES setting to see if it will get us
> were we need to be. I really do not wish to tamper with the packaging
> routines. It does what it does, with an obviously good reason too :
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 7:16 PM, Hans Beckérus wrote:
> On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus
> wrote:
>> On Thu, May 23, 2013 at 5:47 PM, Burton, Ross wrote:
>>> On 23 May 2013 16:25, Hans Beckérus wrote:
Well, yes and no ;) If I look in /lib there are plenty of libraries
that comes with .so files so it seems they are needed in some cases,
right? Also, since part of our system software is doing loading of
dynamic libraries themselves using dlopen() it is *very* hard to
enforce removal of .so files since that piece of software does not
know what particular version of the library it should use. It should
load whatever .so points to, most commonly the latest version. So, is
there some way for us to make sure .so files are also part of the
.rpm? we do not wish to install the -dev variant since it also
pollutes the system with a lot of other not needed stuff. Since /lib
is having a lot of of .so files it must be possible, or?
Actually, I have never seen a system that does not include also the
.so files? Not even embedded ones. They are only soft links so
flash/ram/disk space is not really an issue here.
>>>
>>> *Every* mainstream linux distribution will not ship .so symlinks
>>> unless you've installed the development files, or they are needed for
>>> some reason (generally, the .so won't be a symlink in that case). If
>>> a particular library is designed to be unversioned and dlopen'd using
>>> a .so filename, then change the FILES as appropriate. If your package
>>> is dlopening arbitrary versioned libraries though libfoo.so filenames
>>> then you can either do more work and find the real name, or mess
>>> around with the packaging yourself.
>>>
>>> Ross
>>
>> Sure. I am not questioning mainstream decision not to ship the .so
>> symlinks. I most likely have never encountered real mainstream
>> embedded systems before ;) Only home-brewed (we-can-do-it-ourselves)
>> things. What I needed was some sort of pointer on how to handle the
>> case when you do need to violate the mainstream rules :(
>> I will play around with the FILES setting to see if it will get us
>> were we need to be. I really do not wish to tamper with the packaging
>> routines. It does what it does, with an obviously good reason too :P
>>
>> Thanks!
>> Hans
>>
>>
> Hmm. I tried the FILES trick, but either I am doing something wrong or
> FILES does not really affect whats getting into the .rpm? This is what
> I tried in our recipe
>
> FILES_${PN} += " ${exec_prefix}/usr/lib/libelinx.so"
> FILES_${PN} += " ${exec_prefix}/usr/lib/libepmq.so"
>
> But I see now that dev RPM in addition to the normal RPM is what we
> need besides the .la files but I think we we can live with that ;) Is
> there some simple/clever trick to have both the standard and the dev
> RPM being installed on the rootfs?
>
Oops! Already spotted my typo there. It should of course be
FILES_${PN} += " ${exec_prefix}/lib/libelinx.so"
FILES_${PN} += " ${exec_prefix}/lib/libepmq.so"
But unfortunately I did not make any difference to the .rpm file :(
Hans
On Thu, May 23, 2013 at 7:16 PM, Hans Beckérus wrote:
> On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus
> wrote:
>> On Thu, May 23, 2013 at 5:47 PM, Burton, Ross wrote:
>>> On 23 May 2013 16:25, Hans Beckérus wrote:
Well, yes and no ;) If I look in /lib there are plenty of libraries
that comes with .so files so it seems they are needed in some cases,
right? Also, since part of our system software is doing loading of
dynamic libraries themselves using dlopen() it is *very* hard to
enforce removal of .so files since that piece of software does not
know what particular version of the library it should use. It should
load whatever .so points to, most commonly the latest version. So, is
there some way for us to make sure .so files are also part of the
.rpm? we do not wish to install the -dev variant since it also
pollutes the system with a lot of other not needed stuff. Since /lib
is having a lot of of .so files it must be possible, or?
Actually, I have never seen a system that does not include also the
.so files? Not even embedded ones. They are only soft links so
flash/ram/disk space is not really an issue here.
>>>
>>> *Every* mainstream linux distribution will not ship .so symlinks
>>> unless you've installed the development files, or they are needed for
>>> some reason (generally, the .so won't be a symlink in that case). If
>>> a particular library is designed to be unversioned and dlopen'd using
>>> a .so filename, then change the FILES as appropriate. If your package
>>> is dlopening arbitrary versioned libraries though libfoo.so filenames
>>> then you can either do more work and find the real name, or mess
>>> around with the packaging yourself.
>>>
>>> Ross
>>
>> Sure. I am not questioning mainstream decision not to ship the .so
>> symlinks. I most likely have neve
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On 23 May 2013 18:16, Hans Beckérus wrote:
> Hmm. I tried the FILES trick, but either I am doing something wrong or
> FILES does not really affect whats getting into the .rpm? This is what
> I tried in our recipe
>
> FILES_${PN} += " ${exec_prefix}/usr/lib/libelinx.so"
> FILES_${PN} += " ${exec_prefix}/usr/lib/libepmq.so"
Use ${libdir} instead of exec_prefix/usr/lib, and I guess the default
FILES_${PN}-dev is taking the files first. Try setting that to "".
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On Thu, May 23, 2013 at 8:31 PM, Burton, Ross wrote:
> On 23 May 2013 18:16, Hans Beckérus wrote:
>> Hmm. I tried the FILES trick, but either I am doing something wrong or
>> FILES does not really affect whats getting into the .rpm? This is what
>> I tried in our recipe
>>
>> FILES_${PN} += " ${exec_prefix}/usr/lib/libelinx.so"
>> FILES_${PN} += " ${exec_prefix}/usr/lib/libepmq.so"
>
> Use ${libdir} instead of exec_prefix/usr/lib, and I guess the default
> FILES_${PN}-dev is taking the files first. Try setting that to "".
>
Thanks. I will certainly try that.
However, I have completely changed path now ;) I think the root cause
of this entire problem is that the package is constructed wrong. Since
these .so files are modules, we need to tell libtool so it does not
create the regular versioned lib file structure. What we want is a .so
file and no links. Maybe then all of this is a no issue anymore?
elinx_drv_la_LDFLAGS = -module -avoid-version -shared
This might do the trick.
Hans
On Thu, May 23, 2013 at 8:31 PM, Burton, Ross wrote:
> On 23 May 2013 18:16, Hans Beckérus wrote:
>> Hmm. I tried the FILES trick, but either I am doing something wrong or
>> FILES does not really affect whats getting into the .rpm? This is what
>> I tried in our recipe
>>
>> FILES_${PN} += " ${exec_prefix}/usr/lib/libelinx.so"
>> FILES_${PN} += " ${exec_prefix}/usr/lib/libepmq.so"
>
> Use ${libdir} instead of exec_prefix/usr/lib, and I guess the default
> FILES_${PN}-dev is taking the files first. Try setting that to "".
>
> Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .rpm packaging weirdness of dynamic libraries
On 23 May 2013 19:51, Hans Beckérus wrote: > However, I have completely changed path now ;) I think the root cause > of this entire problem is that the package is constructed wrong. Since > these .so files are modules, we need to tell libtool so it does not > create the regular versioned lib file structure. What we want is a .so > file and no links. Maybe then all of this is a no issue anymore? > > elinx_drv_la_LDFLAGS = -module -avoid-version -shared Oh, if you've created modules and not libraries, then yes. Use those options and generally people put them in a subdirectory under libdir. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
