Re: [yocto] prelink-cross with -fno-plt

2019-05-25 Thread Shane Peelar
Patch is attached.  Thank you!

On Sat, May 25, 2019 at 2:30 AM Khem Raj  wrote:

> On Fri, May 24, 2019 at 6:58 PM Shane Peelar 
> wrote:
> >
> > Great!  Would you be willing to accept a patch that makes arch-x86_64.c
> handle that condition like the other arches?
> >
>
> yes certainly.
>
> > -Shane
> >
> > On Fri, May 24, 2019 at 12:27 PM Khem Raj  wrote:
> >>
> >>
> >>
> >> On 5/24/19 8:10 AM, Shane Peelar wrote:
> >> > I did some reading into the sources in other architectures.  The
> closest
> >> > match, arch_i386.c, makes the write conditional as you say.
> >> > So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c,
> >> > |arch-s390.c, |arch-s390x.c, and |arch-ia64.c.||
> >> > ||
> >> > ||
> >> > Notably, |||arch-cris.c||| has the same assert as
> >> > |||arch-x86_64.c||| instead of the conditional.
> >> >
> >> > The code roughly looks like follows:||
> >> > ||
> >> > |||
> >> > |||
> >> > 1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
> >> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
> >> > 3. Look for the section named ".plt" in the ELF.
> >> > 4. If the section cannot be found, return 0
> >> > 5. Otherwise, write the address of .plt + constant (dependent on arch)
> >> > to got[1]||
> >> > ||
> >> > |||
> >> > |||
> >> > In |||arch-x86_64.c and arch-cris.c|||, step (4) above is an
> >> > assert:|||
> >> >
> >> > |||1. Check for dso->info[DT_PLTGOT].  If it does not exist,
> return 0
> >> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
> >> > 3. Look for the section named ".plt" in the ELF.
> >> > 4. Assert that the section was found
> >> > 5. Write the address of .plt + constant (dependent on arch) to got[1]
> >> >
> >> > I tested out making the assert conditional and nothing seemed to break
> >> > at least.
> >> > |||
> >> > |||
> >>
> >> It seems ok to me.
> >>
> >> >
> >> > On Fri, May 24, 2019 at 12:08 AM Khem Raj  >> > > wrote:
> >> >
> >> >
> >> >
> >> > On 5/23/19 7:53 PM, Shane Peelar wrote:
> >> >  > Any of them on the system pretty much, and yes they are also
> >> > built with
> >> >  > -fno-plt.
> >> >
> >> > OK, I think its better to them conditionally check for .plt
> section,
> >> > can you describe more of whats going on when sections are checked.
> >> >
> >> >  >
> >> >  > On Thu, May 23, 2019 at 9:59 PM Khem Raj  >> > 
> >> >  > >>
> wrote:
> >> >  >
> >> >  >
> >> >  >
> >> >  > On 5/23/19 8:05 AM, Shane Peelar wrote:
> >> >  >  > Hi Everyone @ the Yocto project,
> >> >  >  >
> >> >  >  > I'm Shane Peelar, a PhD Candidate at the University of
> >> > Windsor.
> >> >  >  > I'm writing to you about prelink-cross, as part of the
> >> > Yocto project.
> >> >  >  > Specifically, I'm looking at using it with executables
> >> > built using
> >> >  >  > `-fno-plt` under GCC.
> >> >  >  > I wasn't quite sure where to send this email to, so I
> >> > figured I'd
> >> >  > try
> >> >  >  > here.  If there's a better place to send this, please
> let
> >> > me know.
> >> >  >  >
> >> >  >  > Right now, prelink-cross seems to fail an assertion in
> >> >  > arch-x86_64.c,
> >> >  >  > line 421, when
> >> >  >  > using it with an executable built with `-fno-plt`:
> >> >  >  >
> >> >  >  > ...
> >> >  >  > assert (i < dso->ehdr.e_shnum)
> >> >  >  > ...
> >> >  >  >
> >> >  >  > This snippet seems to be looking for the ".plt" section
> and,
> >> >  > since it
> >> >  >  > can't find it, the assertion fires.  This makes sense
> >> > because in
> >> >  >  > `-fno-plt` executables, the `.plt` section is missing
> >> > entirely.
> >> >  >  > I'm not an expert on ELF stuff, although I am learning
> >> > quickly.  It
> >> >  >  > looks like
> >> >  >  > this code wants to write into GOT[1] the address of
> ".plt"
> >> > + 0x16 --
> >> >  >  > since ".plt" doesn't
> >> >  >  > exist, does it make sense to just change this assert to
> an if
> >> >  > statement
> >> >  >  > like so:
> >> >  >  >
> >> >  >  > ...
> >> >  >  >if (i < dso->ehdr.e_shnum)
> >> >  >  >{ ... }
> >> >  >  > ...
> >> >  >  >
> >> >  >  > and skip over that part?  Or is this a real error
> >> > condition for
> >> >  >  > prelink-cross and it really should not continue?  The
> >> > executable in
> >> >  >  > question is also non-PIE, if that makes a difference.
> >> >  >  >
> >> >  >
> >> >  > what sh

[yocto] Difference between DEPENDS and BUILD-DEPENDS

2019-05-25 Thread Archana Polampalli
Hi all,

i am working on one open source project,for this i have to add some
debian packages as yocto recipies.
i am trying to add "audit" recipe,so iam trying to understand the audit
debian package ,i got struck between "depends" and "build-depends"

audit contaings many packages like 
auditd
libaudit-common
libaudit-dev
libauparse0  etc...

if i click on individual packages in https://packages.debian.org it is
giving "depends" list,if i click on source it is giving "build-
depends".

now my confusion is what i have to prefer either "depends" or "build-
depends" for writing "audit" recipe and what is the difference between
thes "depend" and "build-depends".

Thanks in advance.


Regards
Archana
The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] PN is uppercase

2019-05-25 Thread Ralf Spiwoks

Hi guys,

The warnings were definitely not on when I started using Yocto more than two 
years ago.
I have not been using debian packages, and didn't notice. I thought I was still 
not
using debian and that's why I am surprised about those warnings. But as I 
wrote, if I
ignore the warnings, nothing bad happens ...

And Tim, thank you for writing "Debian" and "OpenEmbedded" in that way ... it 
reassured
me ;-)

Have a good weekend. Cheers,

Ralf.

On 5/24/19 6:23 AM, Tim Orling wrote:



On Thu, May 23, 2019 at 4:55 PM Khem Raj mailto:raj.k...@gmail.com>> wrote:



On 5/21/19 12:50 AM, Ralf Spiwoks wrote:
 > Hi Ross,
 >
 > Thanks for your email. I am realising that I have not replied to your
 > email earlier. Sorry. I guess it was partly because your answer put
 > me slightly off. On the one hand, I thought that as a general approach,
 > Linux was case sensitive, unlike its big rival Windows, and I was not
 > aware  of package managers which would explicitly forbid uppercase
 > package names. I find the approach of allowing only lowercase package
 > names quite limiting, and frankly a drawback for using Yocto
 >
 > On the other hand I have a few tens of packages to maintain, which
 > have uppercase letters in the package names and which did work with
 > Yocto in previous versions. So, because of a new convention we would
 > have to rework some of the packages or ignore the warning messages.
 > And until we find the effort for reworking those package recipes we
 > will stay with the latter option.

The package name rules are not new, they have been with OE/YP forever
so it should have failed always. Similar to debian see


https://www.debian.org/doc/debian-policy/ch-controlfields.html#list-of-fields


We had to pick a convention. Debian is well documented, conservative and well thought out. My first contributions to OpenEmbedded many years ago 
didn’t follow Debian naming, were rejected on V1 and I embarked on a new learning curve. I’ve embraced it and never looked back.



 >
 > Thanks for your patience and your explanations. Cheers,
 >
 > Ralf.
 >
 > On 4/2/19 1:54 PM, Burton, Ross wrote:
 >> On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks mailto:spiw...@cern.ch>> wrote:
 >>> TWO questions:
 >>>
 >>> 1) Are those two issues related?
 >>
 >> Probably not, unless you're trying to use a mixed-case override.
 >>
 >>> 2) What is the logic behind allowing only lower case package names?
 >>> This is to me
 >>>  a serious restriction on the use of Yocto.
 >>
 >> Two reasons: some package managers forbid packages with uppercase
 >> names; and for performance reasons overrides are lowercase and as
 >> package names are often embedded in overrides this implies that
 >> package names need to be lowercase.
 >>
 >> What's the problem with using lowercase names?
 >>
 >> Ross
 >>
-- 
___

yocto mailing list
yocto@yoctoproject.org 
https://lists.yoctoproject.org/listinfo/yocto


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Difference between DEPENDS and BUILD-DEPENDS

2019-05-25 Thread Burton, Ross
On Sat, 25 May 2019 at 14:28, Archana Polampalli
 wrote:
> i am working on one open source project,for this i have to add some
> debian packages as yocto recipies.
> i am trying to add "audit" recipe,so iam trying to understand the audit
> debian package ,i got struck between "depends" and "build-depends"

Debian Build-Depends == OpenEmbedded DEPENDS
Debian Depends == OpenEmbedded RDEPENDS

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] PN is uppercase

2019-05-25 Thread Burton, Ross
The check was added in August 2017 and appeared first in Rocko, so
it's possible that you stuck with an earlier release until recently.

Ross

On Fri, 24 May 2019 at 15:26, Ralf Spiwoks  wrote:
>
> Hi guys,
>
> The warnings were definitely not on when I started using Yocto more than two 
> years ago.
> I have not been using debian packages, and didn't notice. I thought I was 
> still not
> using debian and that's why I am surprised about those warnings. But as I 
> wrote, if I
> ignore the warnings, nothing bad happens ...
>
> And Tim, thank you for writing "Debian" and "OpenEmbedded" in that way ... it 
> reassured
> me ;-)
>
> Have a good weekend. Cheers,
>
> Ralf.
>
> On 5/24/19 6:23 AM, Tim Orling wrote:
> >
> >
> > On Thu, May 23, 2019 at 4:55 PM Khem Raj  > > wrote:
> >
> >
> >
> > On 5/21/19 12:50 AM, Ralf Spiwoks wrote:
> >  > Hi Ross,
> >  >
> >  > Thanks for your email. I am realising that I have not replied to your
> >  > email earlier. Sorry. I guess it was partly because your answer put
> >  > me slightly off. On the one hand, I thought that as a general 
> > approach,
> >  > Linux was case sensitive, unlike its big rival Windows, and I was not
> >  > aware  of package managers which would explicitly forbid uppercase
> >  > package names. I find the approach of allowing only lowercase package
> >  > names quite limiting, and frankly a drawback for using Yocto
> >  >
> >  > On the other hand I have a few tens of packages to maintain, which
> >  > have uppercase letters in the package names and which did work with
> >  > Yocto in previous versions. So, because of a new convention we would
> >  > have to rework some of the packages or ignore the warning messages.
> >  > And until we find the effort for reworking those package recipes we
> >  > will stay with the latter option.
> >
> > The package name rules are not new, they have been with OE/YP forever
> > so it should have failed always. Similar to debian see
> >
> > 
> > https://www.debian.org/doc/debian-policy/ch-controlfields.html#list-of-fields
> >
> >
> > We had to pick a convention. Debian is well documented, conservative and 
> > well thought out. My first contributions to OpenEmbedded many years ago
> > didn’t follow Debian naming, were rejected on V1 and I embarked on a new 
> > learning curve. I’ve embraced it and never looked back.
> >
> >
> >  >
> >  > Thanks for your patience and your explanations. Cheers,
> >  >
> >  > Ralf.
> >  >
> >  > On 4/2/19 1:54 PM, Burton, Ross wrote:
> >  >> On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks  > > wrote:
> >  >>> TWO questions:
> >  >>>
> >  >>> 1) Are those two issues related?
> >  >>
> >  >> Probably not, unless you're trying to use a mixed-case override.
> >  >>
> >  >>> 2) What is the logic behind allowing only lower case package names?
> >  >>> This is to me
> >  >>>  a serious restriction on the use of Yocto.
> >  >>
> >  >> Two reasons: some package managers forbid packages with uppercase
> >  >> names; and for performance reasons overrides are lowercase and as
> >  >> package names are often embedded in overrides this implies that
> >  >> package names need to be lowercase.
> >  >>
> >  >> What's the problem with using lowercase names?
> >  >>
> >  >> Ross
> >  >>
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org 
> > https://lists.yoctoproject.org/listinfo/yocto
> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto