Re: [yocto] unpacking poky-dora-10.0.4.tar.bz2
On 03/20/15 11:06, Flanagan, Elizabeth wrote: > The directory name should be poky-dora-10.0.4. I'll fix the tarball > ASAP. -b Great, thanks. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] unpacking poky-dora-10.0.4.tar.bz2
On 20 March 2015 at 14:53, Trevor Woerner wrote: > Hi, > > When I download and unpack poky-dora-10.0.4.tar.bz2 from > http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/poky-dora-10.0.4.tar.bz2 > I end up with a directory called > poky-de14d21bc6633ddeb810cef051b91ee322276496 instead of (the expected?) > poky-dora-10.0.4. > > Is this expected? > No, it's not. It's an old bug that has crept back into the release process. The directory name should be poky-dora-10.0.4. I'll fix the tarball ASAP. -b > Best regards, > Trevor > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] unpacking poky-dora-10.0.4.tar.bz2
Hi, When I download and unpack poky-dora-10.0.4.tar.bz2 from http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/poky-dora-10.0.4.tar.bz2 I end up with a directory called poky-de14d21bc6633ddeb810cef051b91ee322276496 instead of (the expected?) poky-dora-10.0.4. Is this expected? Best regards, Trevor -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] PublishArtifacts.py: respect TMP_DIR if it's set
If TMP_DIR is set look there for artifacts to publish, rather than a tmp
directory which is a child of basedir.
Signed-off-by: Joshua Lock
---
.../autobuilder/buildsteps/PublishArtifacts.py | 39 --
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
index e636fe5..aee3d1f 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
@@ -47,6 +47,9 @@ class PublishArtifacts(ShellCommand):
self.basedir=os.path.join(os.path.join(
self.workerdir, buildername),
"build/build/")
+self.tmpdir = os.environ.get("TMP_DIR")
+if self.tmpdir is None:
+self.tmpdir = os.path.join(self.basedir, "tmp")
command=""
DATESTAMP=datetime.datetime.now().strftime("%Y%m%d")
if str(os.environ.get('PUBLISH_BUILDS')) == "True":
@@ -72,17 +75,17 @@ class PublishArtifacts(ShellCommand):
if artifact == "adt-installer":
command=command+"mkdir -p " + os.path.join(DEST,
ADT_INST_PUBLISH_DIR) + ";"
command=command+"cp -R --no-dereference --preserve=links "
+ \
-os.path.join(self.basedir,
"tmp/deploy/sdk/") + \
+os.path.join(self.tmpdir, "deploy/sdk/") +
\
"*adt* " + os.path.join(DEST,
ADT_INST_PUBLISH_DIR) + ";"
elif artifact == "adt-installer-QA":
command=command+"mkdir -p " + os.path.join(DEST,
ADTQA_INST_PUBLISH_DIR) + ";"
command=command+"cp -R --no-dereference --preserve=links "
+ \
-os.path.join(self.basedir,
"tmp/deploy/sdk/") + \
+os.path.join(self.tmpdir, "deploy/sdk/") +
\
"*adt* " + os.path.join(DEST,
ADTQA_INST_PUBLISH_DIR)+ ";"
elif artifact == "adtrepo-dev":
adt_dev_dest= os.environ.get("ADTREPO_DEV_PATH") + "/" +
distroversion + "-" + got_revision_poky + '-' + self.getProperty("branch_poky")
command=command+"mkdir -p " + adt_dev_dest + "/adt-ipk;"
-command=command+"rsync -av " + os.path.join(self.basedir,
"tmp/deploy/ipk/") + " " + adt_dev_dest + "/adt-ipk;"
+command=command+"rsync -av " + os.path.join(self.tmpdir,
"deploy/ipk/") + " " + adt_dev_dest + "/adt-ipk;"
command=command+"rm -rf " + adt_dev_dest + "/rootfs; mkdir
-p " + adt_dev_dest + "/rootfs;"
command=command+"for x in `ls " + DEST +
"/machines/qemu/|grep -v tiny`; do ln -s " + DEST + "/machines/qemu/$x " +
adt_dev_dest + "/rootfs/$x; done;"
if self.layerversion_yocto is not None and
int(self.layerversion_yocto) < 2:
@@ -98,49 +101,49 @@ class PublishArtifacts(ShellCommand):
command=command+"mkdir -p " + DEST + "/" + BA_PUBLISH_DIR
+ ";"
if self.layerversion_core is not None and
int(self.layerversion_core) > 2:
command=command+"cp -R --no-dereference
--preserve=links " + \
-os.path.join(self.basedir,
"tmp/deploy/images/qemux86-64/*.zip") + \
+os.path.join(self.tmpdir,
"deploy/images/qemux86-64/*.zip") + \
" " + DEST + "/" + BA_PUBLISH_DIR + ";"
else:
command=command+"cp -R --no-dereference
--preserve=links " + \
-os.path.join(self.basedir,
"tmp/deploy/images/*.zip") + \
+os.path.join(self.tmpdir,
"deploy/images/*.zip") + \
" " + DEST + "/" + BA_PUBLISH_DIR + ";"
elif artifact == "buildtools-tarball":
command=command+"mkdir -p " + DEST + "/buildtools;"
command=command+"cp -R --no-dereference --preserve=links "
+ \
-os.path.join(self.basedir,
"tmp/deploy/sdk/*.sh") + \
+os.path.join(self.tmpdir,
"deploy/sdk/*.sh") + \
" " + DEST + "/buildtools;"
elif artifact == "rpm":
command=command+"mkdir -p " + os.path.join(DEST,
RPM_PUBLISH_DIR) + ";"
command=command+"cp -R --no-dereference --preserve=links "
+ \
-os.path.join(self.basedir,
"tmp/deploy/rpm/* ") + \
+os.path.join(self.tmpdir, "deploy/rpm/
[yocto] [PATCH 2/2] PublishArtifacts: enable publishing of sstate
The PUBLISH_SSTATE variable in config/autobuilder.conf didnt' appear to be
wired up anywhere so I've forced it into PublishArtifacts here.
I consider this patch an RFC because a) it required both the PUBLISH_SSTATE
variable to be set and b) an sstate parameter to be passed to the
PublishArtifacts step. Having to turn things on twice is "not good".
Signed-off-by: Joshua Lock
---
.../site-packages/autobuilder/buildsteps/PublishArtifacts.py | 12
1 file changed, 12 insertions(+)
diff --git
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
index aee3d1f..58add14 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
@@ -127,6 +127,18 @@ class PublishArtifacts(ShellCommand):
command=command+"cp -R --no-dereference --preserve=links "
+ \
os.path.join(self.tmpdir, "deploy/ipk/* ")
+ \
os.path.join(DEST, IPK_PUBLISH_DIR) + ";"
+elif artifact == "sstate":
+if str(os.environ.get("PUBLISH_SSTATE")) == "True":
+sstate_dir = os.environ.get("SSTATE_DIR")
+pub_dir = os.environ.get("SSTATE_PUBLISH_DIR")
+if sstate_dir is not None and pub_dir is not None:
+command=command+"mkdir -p " + pub_dir + ";"
+command=command+"cp -R --no-dereference
--preserve=links " + \
+ sstate_dir + "/* " + pub_dir + ";"
+else:
+command=command+"echo 'Skipping copy of sstate,
directories not configured.';"
+else:
+command=command+"echo 'Skipping copy of sstate,
PUBLISH_SSTATE not set.';"
elif artifact == "toolchain":
command=command+"mkdir -p " + os.path.join(DEST,
X86TC_PUBLISH_DIR) + ";"
command=command+"cp -R --no-dereference --preserve=links "
+ \
--
2.1.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2][autobuilder] Some fixes for PublishArtifacts
When deploying an autobuilder today I had to make a couple of changes to for variables I'd set in config/autobuilder.conf to work. The first patch for TMP_DIR seems good enough but the second for publishing sstate I'm more than a little wary of, mainly because you have to enable sharing sstate in two places (which is twice as many chances it'll be misconfigured)... Joshua Lock (2): PublishArtifacts.py: respect TMP_DIR if it's set PublishArtifacts: enable publishing of sstate .../autobuilder/buildsteps/PublishArtifacts.py | 51 ++ 1 file changed, 33 insertions(+), 18 deletions(-) -- 2.1.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On Friday 20 March 2015 11:10:39 Paul Eggleton wrote: > On Friday 20 March 2015 11:26:43 Alex J Lennon wrote: > > On 20/03/2015 11:15, Prasant J wrote: > > > On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon > > > > > > wrote: > > >> On 20/03/2015 09:34, Prasant J wrote: > > >> > > >> Hi, > > >> > > >> I'm looking for package management for my embedded linux systems > > >> (yocto on armv7 iMX6Q) > > >> > > >> > > >> I'm looking for the following features: > > >> > > >> (a) Install & remove a package > > >> (b) Install packages and its dependencies > > >> (c) Install a package with conflicts, such that the conflicting > > >> package is force removed > > >> (d) A local location with packages should serve as a package source > > >> (e) Remote server package (http file server based) > > >> (f) List of my packages installed > > >> (g) List of my packages not installed but available on the http file > > >> server > > >> (h) List of my packages that have updates (new version) > > >> (i) To be able to manage packages for multiple architectures (eg. rpm > > >> can produce packages for multiple architectures using one spec file) > > >> > > >> > > >> The above features will be invoked by the application GUI. > > >> Any suggestions: which package management solution would answer all > > >> the above use cases? > > >> > > >> > > >> > > >> (e) I use smart + RPM. I have a remote package server setup via this in > > >> local.conf > > >> > > >> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"; > > >> > > >> Then I'm rsyncing the files up to the server after a bitbake > > >> package-index. > > >> > > >> Then smart update / search / install > > >> > > >> That seems to work well in my testing. > > > > > > Hi Alex, > > > > > > Thanks for inputs! > > > > > > Is smart development stopped? > > > > > > When I look at their mailing list it, the last posts were in Nov 2014. > > > It looks like no more development for smart package manager. I would > > > then tend to say that it will not be a right way for me. > > > > I don't know. To me the question would be does it do want I need it to > > do as well as I need it to do it, > > rather than asking whether there is a lot of activity. One might take > > the view that if it is doing its job, > > a lack of activity is a sign that it's a mature piece of software that > > needs little further development. > > > > You'll have to make that decision yourself. > > > > My understanding is that smart is the recommended way to do things (at > > least it was what was > > recommended to me) - https://wiki.yoctoproject.org/wiki/Smart > > FYI, here is some of the thinking that led to the decision to use smart: > > https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html > > Of course that was a few years ago now - we probably ought to look at the > RPM landscape again (e.g. DNF) and see if any change is warranted. I forgot to mention, we do have some basic documentation here on setting up a feed if you hadn't already seen it: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On Friday 20 March 2015 11:26:43 Alex J Lennon wrote: > On 20/03/2015 11:15, Prasant J wrote: > > On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon > > > > wrote: > >> On 20/03/2015 09:34, Prasant J wrote: > >> > >> Hi, > >> > >> I'm looking for package management for my embedded linux systems > >> (yocto on armv7 iMX6Q) > >> > >> > >> I'm looking for the following features: > >> > >> (a) Install & remove a package > >> (b) Install packages and its dependencies > >> (c) Install a package with conflicts, such that the conflicting > >> package is force removed > >> (d) A local location with packages should serve as a package source > >> (e) Remote server package (http file server based) > >> (f) List of my packages installed > >> (g) List of my packages not installed but available on the http file > >> server > >> (h) List of my packages that have updates (new version) > >> (i) To be able to manage packages for multiple architectures (eg. rpm > >> can produce packages for multiple architectures using one spec file) > >> > >> > >> The above features will be invoked by the application GUI. > >> Any suggestions: which package management solution would answer all > >> the above use cases? > >> > >> > >> > >> (e) I use smart + RPM. I have a remote package server setup via this in > >> local.conf > >> > >> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"; > >> > >> Then I'm rsyncing the files up to the server after a bitbake > >> package-index. > >> > >> Then smart update / search / install > >> > >> That seems to work well in my testing. > > > > Hi Alex, > > > > Thanks for inputs! > > > > Is smart development stopped? > > > > When I look at their mailing list it, the last posts were in Nov 2014. > > It looks like no more development for smart package manager. I would > > then tend to say that it will not be a right way for me. > > I don't know. To me the question would be does it do want I need it to > do as well as I need it to do it, > rather than asking whether there is a lot of activity. One might take > the view that if it is doing its job, > a lack of activity is a sign that it's a mature piece of software that > needs little further development. > > You'll have to make that decision yourself. > > My understanding is that smart is the recommended way to do things (at > least it was what was > recommended to me) - https://wiki.yoctoproject.org/wiki/Smart FYI, here is some of the thinking that led to the decision to use smart: https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html Of course that was a few years ago now - we probably ought to look at the RPM landscape again (e.g. DNF) and see if any change is warranted. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] customising root file system by removing the unwanted commands and libraries
Hi Dilip, On Wednesday 18 March 2015 03:00:37 Dilip Basavaraju wrote: > I want to build an RFS, which I need to customize it by > removing the unwanted packages and particular commands which is not used by > me. > > Please suggest me how to customize, or refer me for > documents where I can read and understand completely all the details about > customization. > > For example: > > /bin will have cat, ls, cd, lsmod, wc . > > I want to remove wc and lsmod and minimize my RFS as much as > possible. We have a general guide that might be useful here: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-a-tiny-system (Whether you actually need to use poky-tiny itself is a separate question, but it does explain some of the techniques used to generate it.) Ultimately, removing things comes down to figuring out how they got there in the first place. The Toaster Web UI, or the graphs produced by buildhistory for the image and bitbake -g may be useful in that process - but note that not everything can be removed easily. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On 20/03/2015 11:15, Prasant J wrote: > On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon > wrote: >> >> On 20/03/2015 09:34, Prasant J wrote: >> >> Hi, >> >> I'm looking for package management for my embedded linux systems >> (yocto on armv7 iMX6Q) >> >> >> I'm looking for the following features: >> >> (a) Install & remove a package >> (b) Install packages and its dependencies >> (c) Install a package with conflicts, such that the conflicting >> package is force removed >> (d) A local location with packages should serve as a package source >> (e) Remote server package (http file server based) >> (f) List of my packages installed >> (g) List of my packages not installed but available on the http file server >> (h) List of my packages that have updates (new version) >> (i) To be able to manage packages for multiple architectures (eg. rpm >> can produce packages for multiple architectures using one spec file) >> >> >> The above features will be invoked by the application GUI. >> Any suggestions: which package management solution would answer all >> the above use cases? >> >> >> >> (e) I use smart + RPM. I have a remote package server setup via this in >> local.conf >> >> FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"; >> >> Then I'm rsyncing the files up to the server after a bitbake package-index. >> >> Then smart update / search / install >> >> That seems to work well in my testing. >> > > Hi Alex, > > Thanks for inputs! > > Is smart development stopped? > > When I look at their mailing list it, the last posts were in Nov 2014. > It looks like no more development for smart package manager. I would > then tend to say that it will not be a right way for me. > I don't know. To me the question would be does it do want I need it to do as well as I need it to do it, rather than asking whether there is a lot of activity. One might take the view that if it is doing its job, a lack of activity is a sign that it's a mature piece of software that needs little further development. You'll have to make that decision yourself. My understanding is that smart is the recommended way to do things (at least it was what was recommended to me) - https://wiki.yoctoproject.org/wiki/Smart Regards, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon wrote: > > > On 20/03/2015 09:34, Prasant J wrote: > > Hi, > > I'm looking for package management for my embedded linux systems > (yocto on armv7 iMX6Q) > > > I'm looking for the following features: > > (a) Install & remove a package > (b) Install packages and its dependencies > (c) Install a package with conflicts, such that the conflicting > package is force removed > (d) A local location with packages should serve as a package source > (e) Remote server package (http file server based) > (f) List of my packages installed > (g) List of my packages not installed but available on the http file server > (h) List of my packages that have updates (new version) > (i) To be able to manage packages for multiple architectures (eg. rpm > can produce packages for multiple architectures using one spec file) > > > The above features will be invoked by the application GUI. > Any suggestions: which package management solution would answer all > the above use cases? > > > > (e) I use smart + RPM. I have a remote package server setup via this in > local.conf > > FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"; > > Then I'm rsyncing the files up to the server after a bitbake package-index. > > Then smart update / search / install > > That seems to work well in my testing. > Hi Alex, Thanks for inputs! Is smart development stopped? When I look at their mailing list it, the last posts were in Nov 2014. It looks like no more development for smart package manager. I would then tend to say that it will not be a right way for me. Regards, Pj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On 20/03/2015 09:34, Prasant J wrote: > Hi, > > I'm looking for package management for my embedded linux systems > (yocto on armv7 iMX6Q) > > > I'm looking for the following features: > > (a) Install & remove a package > (b) Install packages and its dependencies > (c) Install a package with conflicts, such that the conflicting > package is force removed > (d) A local location with packages should serve as a package source > (e) Remote server package (http file server based) > (f) List of my packages installed > (g) List of my packages not installed but available on the http file server > (h) List of my packages that have updates (new version) > (i) To be able to manage packages for multiple architectures (eg. rpm > can produce packages for multiple architectures using one spec file) > > > The above features will be invoked by the application GUI. > Any suggestions: which package management solution would answer all > the above use cases? > > (e) I use smart + RPM. I have a remote package server setup via this in local.conf FEED_DEPLOYDIR_BASE_URI = "http://packages.foo.bar"; Then I'm rsyncing the files up to the server after a bitbake package-index. Then smart update / search / install That seems to work well in my testing. Regards, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Embedded Linux Package Management
Hi, I'm looking for package management for my embedded linux systems (yocto on armv7 iMX6Q) I'm looking for the following features: (a) Install & remove a package (b) Install packages and its dependencies (c) Install a package with conflicts, such that the conflicting package is force removed (d) A local location with packages should serve as a package source (e) Remote server package (http file server based) (f) List of my packages installed (g) List of my packages not installed but available on the http file server (h) List of my packages that have updates (new version) (i) To be able to manage packages for multiple architectures (eg. rpm can produce packages for multiple architectures using one spec file) The above features will be invoked by the application GUI. Any suggestions: which package management solution would answer all the above use cases? I have tried smart + rpm, but from my preliminary research suggests that smart is no longer developed (Am I correct?). Also I failed to setup remote repository [case (e)] and also case (h) failed. I am currently trying out yum + rpm, but it fails to answer case (f). It can lists all my packages but does not tell me if it is installed or available on the repo. I could make it work by additional steps (work around), but it will be good if the tool itself supports these features. It also fails case (c), does not force remove conflicting package. I also looked at opkg, but the last stable release seems to be v0.2.4 (v0.3.0-rc2 is current). Is it mature enough to be used? Does ipk packages support all features as rpm packages would support (dependencies, conflicts, groups) ? Sorry for asking a lot of questions. It would be very helpful if someone who has worked with package management on linux systems can give some inputs. Thanks in advance! Regards, Pj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-freescale] Including Static Libraries from sysroot in an autotools based package
> On Mar 20, 2015, at 1:09 AM, Priya Agarwal
> wrote:
>
> Hello,
>
> Sorry to ask this question but I am unable to find any answer in reference
> manuals.
> ${CC} is a c compiler. For c++ is it ${CXX} or something else.
Yes, you can always do bitbake -e | grep -e “^CXX=“
and figure out various variables that you want to evaluate
>
> Thanks.
>
> On Fri, Mar 20, 2015 at 9:07 AM, Priya Agarwal
> > wrote:
> I have edited the Makefile.am as well in this way:
>
> squid_LDADD += -lusdpaa_of
>
> Then I just retarred squid code and build it again.
>
> And The libraries are shown in the compile command as well, when I see the
> log.do_compile generated during the build.
> Check Line number 403 in this pastebin link. (ctrl+F 'usdpaa_of' could show
> where all it occurs). http://pastebin.com/LpaymTQa
>
> So how is it possible they are not actually linked.
> I even checked the OVERRIDE variable in bitbake.conf which is set correctly.
> I really need to link this library. :/
>
> On Fri, Mar 20, 2015 at 8:43 AM, Khem Raj > wrote:
>
>> On Mar 19, 2015, at 2:07 AM, Priya Agarwal
>> > > wrote:
>>
>> Hi,
>>
>> I need to link some libraries which are in sysroot into my source code.
>> These are usdpaa libraries.
>>
>> I added DEPENDS += "usdpaa" in .bb file.
>> Apart from that also changed the Makefile.am of my source to include the
>> following:
>> area_LDADD = -lusdpaa_of
>> Then I ran aclocal, autoconf, automake --add-missing and retarred my package.
>>
>> When the package is being built from recipe, do_compile fails. It shows
>> "undefined reference to" error.
>> So this means that libraries are not getting linked by just doing the above
>> changes. What else I need to change?
>
> I think you need to specify them in Makefile.am using LDADD since it is using
> auto tools. Please take a look at Automake documentation
> http://www.gnu.org/software/automake/manual/html_node/Linking.html
>
> might be helpful.
>
>>
>> I think this problem is specific to autotools based projects as when I
>> include the libraries during the gcc command they are easily included.
>>
>> do_compile() {
>> ${CC} check.c -o check -lusdpaa_of
>> }
>> link to area.bb --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
> --
> ___
> meta-freescale mailing list
> meta-freesc...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
>
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-freescale] Including Static Libraries from sysroot in an autotools based package
Hello,
Sorry to ask this question but I am unable to find any answer in reference
manuals.
${CC} is a c compiler. For c++ is it ${CXX} or something else.
Thanks.
On Fri, Mar 20, 2015 at 9:07 AM, Priya Agarwal <
priya_agar...@students.iitmandi.ac.in> wrote:
> I have edited the Makefile.am as well in this way:
>
> squid_LDADD += -lusdpaa_of
>
> Then I just retarred squid code and build it again.
>
> And The libraries are shown in the compile command as well, when I see the
> log.do_compile generated during the build.
> Check Line number 403 in this pastebin link. (ctrl+F 'usdpaa_of' could
> show where all it occurs). http://pastebin.com/LpaymTQa
> So how is it possible they are not actually linked.
> I even checked the OVERRIDE variable in bitbake.conf which is set
> correctly.
> I really need to link this library. :/
>
> On Fri, Mar 20, 2015 at 8:43 AM, Khem Raj wrote:
>
>>
>> On Mar 19, 2015, at 2:07 AM, Priya Agarwal <
>> priya_agar...@students.iitmandi.ac.in> wrote:
>>
>> Hi,
>>
>> I need to link some libraries which are in sysroot into my source code.
>> These are usdpaa libraries.
>>
>> I added DEPENDS += "usdpaa" in .bb file.
>> Apart from that also changed the Makefile.am of my source to include the
>> following:
>> area_LDADD = -lusdpaa_of
>> Then I ran aclocal, autoconf, automake --add-missing and retarred my
>> package.
>>
>> When the package is being built from recipe, do_compile fails. It shows
>> "undefined reference to" error.
>> So this means that libraries are not getting linked by just doing the
>> above changes. What else I need to change?
>>
>>
>> I think you need to specify them in Makefile.am using LDADD since it is
>> using auto tools. Please take a look at Automake documentation
>> http://www.gnu.org/software/automake/manual/html_node/Linking.html
>> might be helpful.
>>
>>
>> I think this problem is specific to autotools based projects as when I
>> include the libraries during the gcc command they are easily included.
>>
>> do_compile() {
>> ${CC} check.c -o check -lusdpaa_of
>> }
>> link to area.bb
>> http://pastebin.com/Bef2C7nX
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>> --
>> ___
>> meta-freescale mailing list
>> meta-freesc...@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale
>>
>>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
