[yocto] Provide sftp-client support in yocto
I am new to OpenEmbedded Yocto project and have a requirement to provide sftp-client support on my target board. Sftp-server bins are already packed into final image and is installed at tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/sftp-server Now ,same way Do I have to install stfp client bins also or is there any other way to go about it?? Thanks Amit ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Provide sftp-client support in yocto
El 01/10/2013 9:52, Amit Tomer escribió: I am new to OpenEmbedded Yocto project and have a requirement to provide sftp-client support on my target board. Sftp-server bins are already packed into final image and is installed at tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/sftp-server Now ,same way Do I have to install stfp client bins also or is there any other way to go about it?? Thanks Amit ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto I had the same problem and I posted this solution: https://lists.yoctoproject.org/pipermail/yocto/2013-September/018477.html Regards -- Diego González González Dpto. de Control Industrial HORUS HARDWARE S.A. diego.gonza...@horus.es ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Provide sftp-client support in yocto
* Amit Tomer [131001 09:53]: > I am new to OpenEmbedded Yocto project and have a requirement to provide > sftp-client support on my target board. > Sftp-server bins are already packed into final image and is installed at > tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/ > sftp-server Yes, that's correct. The server should be installable by adding openssh-sftp-server to your image. (Though, I guess you already figured this one out). > Now ,same way Do I have to install stfp client bins also or is there any other > way to go about it?? It's already being installed to a package named openssh-sftp. Thus, it should be enough to add openssh-sftp to your image. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to add /sys and /proc filesystems to image?
Hello, I have custom board with core-image-minimal and boot goes fine. Problem is that image has /sys and /proc directories but they are empty. I tried also core-image-sato but boot hangs on Starting udev... Is there a way to add these directories to image? Or should I bitbake other Yocto image more suitable for my board, which do not have display and console interface is OK? jv ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH 2/2] Bastille: Remove dependency on lib-perl
Sure thing. Updated patch coming soon.
-J.
On Wed, Sep 25, 2013 at 6:01 PM, mulhern wrote:
> Hi!
>
> Thanks for the patch.
>
> Could you amend it in the following way:
> 1) Omit the changes to the Bastille code.
> 2) According to the CPAN documentation the Lib module has been part of perl
> core since 5.001. So, you should definitely remove that lib-perl recipe from
> meta-security as you are doing. You'll still need to make the Bastille
> recipe dependent on the Lib module, but you'll find that among the standard
> perl modules elsewhere in the Yocto distribution.
>
> - mulhern
>
>
> On Fri, Sep 20, 2013 at 12:20 AM, Joe MacDonald wrote:
>>
>> Bastille never uses more than the minimal functionality provided by the
>> 'lib' module, just pre-pending a named directory to @INC (and, optionally,
>> the directory with a ${archname}/auto appended to it). Lighten this a bit
>> by updating the Bastille code base and remove lib-perl from meta-security
>> entirely since it no longer serves any purpose.
>>
>> Signed-off-by: Joe MacDonald
>> ---
>> recipes-security/bastille/bastille_3.2.1.bb|3 +-
>> ...-lib-remove-dependency-on-lib-perl-module.patch | 495
>>
>> recipes-security/perl/lib-perl_0.63.bb | 28 --
>> 3 files changed, 497 insertions(+), 29 deletions(-)
>> create mode 100644
>> recipes-security/bastille/files/0001-lib-remove-dependency-on-lib-perl-module.patch
>> delete mode 100644 recipes-security/perl/lib-perl_0.63.bb
>>
>> diff --git a/recipes-security/bastille/bastille_3.2.1.bb
>> b/recipes-security/bastille/bastille_3.2.1.bb
>> index d506399..20a331a 100644
>> --- a/recipes-security/bastille/bastille_3.2.1.bb
>> +++ b/recipes-security/bastille/bastille_3.2.1.bb
>> @@ -6,7 +6,7 @@ LICENSE = "GPLv2"
>> LIC_FILES_CHKSUM =
>> "file://${S}/COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b"
>> # Bash is needed for set +o privileged (check busybox), might also need
>> ncurses
>> DEPENDS = "virtual/kernel"
>> -RDEPENDS_${PN} = "perl bash tcl perl-module-getopt-long
>> perl-module-text-wrap lib-perl perl-module-file-path perl-module-mime-base64
>> perl-module-file-find perl-module-errno perl-module-file-glob
>> perl-module-tie-hash-namedcapture perl-module-file-copy perl-module-english
>> perl-module-exporter perl-module-cwd libcurses-perl coreutils"
>> +RDEPENDS_${PN} = "perl bash tcl perl-module-getopt-long
>> perl-module-text-wrap perl-module-file-path perl-module-mime-base64
>> perl-module-file-find perl-module-errno perl-module-file-glob
>> perl-module-tie-hash-namedcapture perl-module-file-copy perl-module-english
>> perl-module-exporter perl-module-cwd libcurses-perl coreutils"
>> FILES_${PN} += "/run/lock/subsys/bastille"
>>
>> inherit allarch module-base
>> @@ -32,6 +32,7 @@ SRC_URI =
>> "http://sourceforge.net/projects/bastille-linux/files/bastille-linux/3
>> file://edit_usage_message.patch \
>> file://organize_distro_discovery.patch \
>> file://do_not_apply_config.patch \
>> + file://0001-lib-remove-dependency-on-lib-perl-module.patch \
>> "
>>
>> SRC_URI[md5sum] = "df803f7e38085aa5da79f85d0539f91b"
>> diff --git
>> a/recipes-security/bastille/files/0001-lib-remove-dependency-on-lib-perl-module.patch
>> b/recipes-security/bastille/files/0001-lib-remove-dependency-on-lib-perl-module.patch
>> new file mode 100644
>> index 000..a3ec88d
>> --- /dev/null
>> +++
>> b/recipes-security/bastille/files/0001-lib-remove-dependency-on-lib-perl-module.patch
>> @@ -0,0 +1,495 @@
>> +From 23126d70d69251b735bd8f0e43c3b7c299e7ab0f Mon Sep 17 00:00:00 2001
>> +From: Joe MacDonald
>> +Date: Thu, 19 Sep 2013 10:16:53 -0400
>> +Subject: [PATCH] lib: remove dependency on lib-perl module
>> +
>> +The perl 'lib' module isn't really necessary based on the usage pattern
>> in
>> +Bastille, so remove the dependency on it.
>> +
>> +Upstream-Status: Submitted [SourceForge project:
>> https://sourceforge.net/p/bastille-linux/bugs/160/]
>> +
>> +Signed-off-by: Joe MacDonald
>> +---
>> + Bastille/AccountSecurity.pm |8 +++-
>> + Bastille/Apache.pm |8 +++-
>> + Bastille/BootSecurity.pm |8 +++-
>> + Bastille/ConfigureMiscPAM.pm |8 +++-
>> + Bastille/DNS.pm |8 +++-
>> + Bastille/DisableUserTools.pm |8 +++-
>> + Bastille/FTP.pm |8 +++-
>> + Bastille/FilePermissions.pm |8 +++-
>> + Bastille/IOLoader.pm |8 +++-
>> + Bastille/Logging.pm |8 +++-
>> + Bastille/MiscellaneousDaemons.pm |8 +++-
>> + Bastille/OSXFirewall.pm |8 +++-
>> + Bastille/PSAD.pm |8 +++-
>> + Bastille/Printing.pm |8 +++-
>> + Bastille/RemoteAccess.pm |8 +++-
>> + Bastille/SecureInetd.pm |8 +++-
>> + Bastille/Sendmail.pm |8 +++-
>> + Bastille/TMPDIR.pm
[yocto] [psplash][PATCH] Add option to read message from file
Add an option to read the displayed message from a file.
Additionally the maximum length for the read string can be defined.
The string will then be cut after the given number of chars.
It is also possible to define a prefix which is displayed in front
of the read file content.
If no file is defined a hardcoded message (using MSG like before)
can be displayed.
For these changes the following defines were introduced:
MSG_FILE_PATH .. path to the file
MSG_FILE_MAX_LEN ... number of chars read from file
MSG_FILE_PREFIX text displayed in front of the file content
Signed-off-by: Richard Leitner
---
psplash.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/psplash.c b/psplash.c
index 09cf0d0..093a99a 100644
--- a/psplash.c
+++ b/psplash.c
@@ -23,6 +23,20 @@
#include "psplash-bar-img.h"
#include "radeon-font.h"
+/* Here you can define a message which will be displayed above the
+ * progress bar.
+ * The message can be either read from a file:
+ *Set MSG_FILE_PATH (and if needed MSG_FILE_{MAX_LEN,PREFIX})
+ *to display the first MSG_FILE_MAX_LEN characters
+ *of the first line from MSG_FILE_PATH as message.
+ *Additionally the content of MSG_FILE_PREFIX will be displayed
+ *before the read message. */
+#define MSG_FILE_PATH ""
+#define MSG_FILE_MAX_LEN 32
+#define MSG_FILE_PREFIX ""
+/* Or a fixed string can be used:
+ *If MSG_FILE is not set or not readable
+ *the content of MSG will be used as message. */
#define MSG ""
void
@@ -204,6 +218,8 @@ main (int argc, char** argv)
intpipe_fd, i = 0, angle = 0, ret = 0;
PSplashFB *fb;
bool disable_console_switch = FALSE;
+ FILE *fd_msg;
+ char *str_msg;
signal(SIGHUP, psplash_exit);
signal(SIGINT, psplash_exit);
@@ -287,7 +303,30 @@ main (int argc, char** argv)
psplash_draw_progress (fb, 0);
- psplash_draw_msg (fb, MSG);
+ /* Draw message from file or defined MSG */
+ fd_msg = fopen (MSG_FILE_PATH, "r");
+ if (fd_msg==NULL) {
+psplash_draw_msg (fb, MSG);
+ } else {
+str_msg = (char*) malloc (
+ (MSG_FILE_MAX_LEN + strlen(MSG_FILE_PREFIX) + 1)*sizeof(char));
+if (str_msg != NULL && fgets (str_msg, MSG_FILE_MAX_LEN, fd_msg)!=NULL) {
+ if (strlen (MSG_FILE_PREFIX) > 0) {
+/* if MSG_FILE_PREFIX is set, prepend it to str_msg */
+memmove (str_msg + strlen(MSG_FILE_PREFIX) + 1, str_msg,
strlen(str_msg));
+strcpy (str_msg, MSG_FILE_PREFIX);
+ /* replace \0 after MSG_FILE_PREFIX with a space */
+str_msg[strlen(MSG_FILE_PREFIX)] = ' ';
+ }
+ psplash_draw_msg (fb, str_msg);
+ free (str_msg);
+} else {
+ /* MSG_FILE_PATH is empty (or malloc failed)
+ *so display MSG_FILE_PREFIX only */
+ psplash_draw_msg (fb, MSG_FILE_PREFIX);
+}
+fclose (fd_msg);
+ }
psplash_main (fb, pipe_fd, 0);
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH] Add option to read message from file
Hi everybody,
I recently sent a patch for psplash to add the ability to read the displayed
message from a file.
I'd appreciate any comments on it!
Thanks and best regards,
Richard Leitner
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On
> Behalf Of Richard Leitner - SKIDATA
> Sent: Tuesday, October 01, 2013 2:51 PM
> To: Yocto Project Discussion ML (yocto@yoctoproject.org)
> Subject: [yocto] [psplash][PATCH] Add option to read message from file
>
> Add an option to read the displayed message from a file.
> Additionally the maximum length for the read string can be defined.
> The string will then be cut after the given number of chars.
> It is also possible to define a prefix which is displayed in front of the
> read file content.
>
> If no file is defined a hardcoded message (using MSG like before) can be
> displayed.
>
> For these changes the following defines were introduced:
> MSG_FILE_PATH .. path to the file
> MSG_FILE_MAX_LEN ... number of chars read from file MSG_FILE_PREFIX text
> displayed in front of the file content
>
> Signed-off-by: Richard Leitner
> ---
> psplash.c | 41 -
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/psplash.c b/psplash.c
> index 09cf0d0..093a99a 100644
> --- a/psplash.c
> +++ b/psplash.c
> @@ -23,6 +23,20 @@
> #include "psplash-bar-img.h"
> #include "radeon-font.h"
>
> +/* Here you can define a message which will be displayed above the
> + * progress bar.
> + * The message can be either read from a file:
> + *Set MSG_FILE_PATH (and if needed MSG_FILE_{MAX_LEN,PREFIX})
> + *to display the first MSG_FILE_MAX_LEN characters
> + *of the first line from MSG_FILE_PATH as message.
> + *Additionally the content of MSG_FILE_PREFIX will be displayed
> + *before the read message. */
> +#define MSG_FILE_PATH ""
> +#define MSG_FILE_MAX_LEN 32
> +#define MSG_FILE_PREFIX ""
> +/* Or a fixed string can be used:
> + *If MSG_FILE is not set or not readable
> + *the content of MSG will be used as message. */
> #define MSG ""
>
> void
> @@ -204,6 +218,8 @@ main (int argc, char** argv)
>intpipe_fd, i = 0, angle = 0, ret = 0;
>PSplashFB *fb;
>bool disable_console_switch = FALSE;
> + FILE *fd_msg;
> + char *str_msg;
>
>signal(SIGHUP, psplash_exit);
>signal(SIGINT, psplash_exit);
> @@ -287,7 +303,30 @@ main (int argc, char** argv)
>
>psplash_draw_progress (fb, 0);
>
> - psplash_draw_msg (fb, MSG);
> + /* Draw message from file or defined MSG */
> + fd_msg = fopen (MSG_FILE_PATH, "r");
> + if (fd_msg==NULL) {
> +psplash_draw_msg (fb, MSG);
> + } else {
> +str_msg = (char*) malloc (
> + (MSG_FILE_MAX_LEN + strlen(MSG_FILE_PREFIX) + 1)*sizeof(char));
> +if (str_msg != NULL && fgets (str_msg, MSG_FILE_MAX_LEN, fd_msg)!=NULL) {
> + if (strlen (MSG_FILE_PREFIX) > 0) {
> +/* if MSG_FILE_PREFIX is set, prepend it to str_msg */
> +memmove (str_msg + strlen(MSG_FILE_PREFIX) + 1, str_msg,
> strlen(str_msg));
> +strcpy (str_msg, MSG_FILE_PREFIX);
> + /* replace \0 after MSG_FILE_PREFIX with a space */
> +str_msg[strlen(MSG_FILE_PREFIX)] = ' ';
> + }
> + psplash_draw_msg (fb, str_msg);
> + free (str_msg);
> +} else {
> + /* MSG_FILE_PATH is empty (or malloc failed)
> +*so display MSG_FILE_PREFIX only */
> + psplash_draw_msg (fb, MSG_FILE_PREFIX);
> +}
> +fclose (fd_msg);
> + }
>
>psplash_main (fb, pipe_fd, 0);
>
> --
> 1.7.10.4
>
> ___
> 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] Fwd: FW: Creating BSP without using git
On Tue, 2013-10-01 at 11:48 +0530, Dilip Kumar wrote: > > > > > > > > > > > Hi, > > > > I need to create a local BSP layer using Yocto-bsp > create command without the use of Git. > > > > > > > > > > > > yocto-bsp create mylayers qemu -s > > > > Which qemu architecture would you like to use? [default: i386] > > > > 1) i386(32-bit) > > > > 2) x86_64 (64-bit) > > > > 3) ARM (32-bit) > > > > 4) PowerPC (32-bit) > > > > 5) MIPS(32-bit) > > > > 3 > > > > Would you like to use the default (3.8) kernel? (y/n) [default: y] y > > > > Do you need a new machine branch for this BSP (the alternative is to > re-use an existing branch)? [y/n] [default: y] n > > > > Getting branches from remote repo > git://git.yoctoproject.org/linux-yocto-3.8.git... > > > > You can use the -i param with JSON to feed it the answers you want to give it, and then it won't try to generate and display a branch list, etc. >From the help: yocto-bsp create [-o | --outdir ] [-i | --infile ] The BSP-specific properties that define the values that will be used to generate a particular BSP can be specified on the command-line using the -i option and supplying a JSON object consisting of the set of name:value pairs needed by the BSP. If the -i option is not used, the user will be interactively prompted for each of the required property values, which will then be used as values for BSP generation. The set of properties available for a given architecture can be listed using the 'yocto-bsp list' command. > > > > > > > > Thanks with Regards > > > > > - > > Dilip Kumar b > > > > > > > > > > > > > > > The contents of this e-mail and any attachment(s) may contain > confidential or privileged information for the intended recipient(s). > Unintended recipients are prohibited from taking action on the basis > of information in this e-mail and using or disseminating the > information, and must notify the sender and delete it from their > system. L&T Infotech will not accept responsibility or liability for > the accuracy or completeness of, or the presence of any virus or > disabling code in this e-mail" > > > ___ > 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] Problem finding -lgcc when using SDK toolchain
Hello. We have stumbled into a problem when using ld directly instead
of going through the gcc frontend.
A simple operation like this fails:
>${CC} -c hello_world.c
>${LD} hello_world.o -lgcc
arm-poky-linux-gnueabi-ld: cannot find -lgcc
And yes, I know -lgcc is not required in this case to compile this
one, but this is only a simple reproducer.
The real issue was discovered when trying to build U-Boot from the SDK.
To resolve this problem we are forced to provide
-L/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
But that should not be needed, should it? Anyone else bumped into this
problem? Are there any "real" solutions.
I am starting to think it has to do with the hardcoded installation
path in the binaries maybe? If you choose not to install
the SDK where Yocto assumes it to be installed things break, even if
--sysroot is used.
Thanks.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Provide sftp-client support in yocto
Amit Tomer wrote: >Thansk Anders for your kind response > > >Yes we are created our image and can see there are some IMAGE_INSTALL >already used Good. >But when I add IMAGE_INSTALL += "openssh-sftp" > > >Getting below error > > >Error: openssh-sftp not found in the base feeds (fzm_lsp_k2 >cortexa15hf-vfp-neon cortexa15hf-vfp armv7ahf-vfp-neon armv7ahf-vfp >armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all). > > >Do we need to do something more here That should have been enough. If you look in tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/packages-split, do you see openssh-sftp there, or which packages do you have there? Which version of Yocto / Poky are you using? What layers do you have enabled? Cheers, Anders >Thanks > >Amit > > > > > >On Tue, Oct 1, 2013 at 6:56 PM, Anders Darander >wrote: > >* Amit Tomer [131001 14:57]: > >> Just now I have seen your responses ,didn't get any notification of >your >> responses on my mail-id. > >> Let me present my problem again to you guys. > >> We have stfp-server running fine on put target machine and is running >as part >> of sshd daemon. > >Ok, that sounds good. Then the server is apparantly no problem for you. > > >> But when we try to connect to other machine from target board, sftp >is not >> working becaue our borad is set to run as sftp -client. > >> An SFTP client program called sftp is already insatlled to tmp/work/ >> fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/bin. > >The build process built sftp (the client) as a part of building >openssh. >The client was packaged into a separate package, called openssh-sftp. > > >> But on Target I could not find this sftp .bins. > >Now you need to install that package, openssh-sftp, to your image. > >If you have created your own image, just add openssh-sftp to >IMAGE_INSTALL. > >If you're not creating your own images, I'd strongly suggest that you >do >that. (It'll make all your customizations a lot easier in the end). See >http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage-custombb >for more information. > >I hope this answers your question. > >Cheers, >Anders > > >> Now we want this stfp run as some daemon or part of sshd daemon >itself. > >> Anders: It's already being installed to a package named openssh-sftp > >> We don't have package named openssh-sftp ,we have package named with >openssh >> only > >> Thanks >> Amit > > > > > > > >> On Tue, Oct 1, 2013 at 1:22 PM, Amit Tomer >wrote: > >> I am new to OpenEmbedded Yocto project and have a requirement to >provide >> sftp-client support on my target board. > >> Sftp-server bins are already packed into final image and is >installed at > >> >tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/ >> sftp-server > >> Now ,same way Do I have to install stfp client bins also or is >there any >> other way to go about it?? > >> Thanks >> Amit > > > > > > > >-- >Anders Darander >ChargeStorm AB / eStorm AB -- Anders Darander ChargeStorm AB Tel: +46 702 44 84 36 Laxholmstorget 3 Email: and...@chargestorm.se 602 21 Norrköping Web: www.chargestorm.se Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] "Kernel access of bad area" in kernel module
Hi,
I want to set/reset GPIO registers in freescale p1022 processor. I saw a
hello-mod kernel module in yocto and I added it to my image and it worked.
According to hello-mod kernel module, I created GPIO module like hello-mod.
But it GPIO module failed when I run it in kernel level. I checked several
times addresses of registers and it seems accurate.
My code is here :
#include
int init_module(void)
{
volatile uint32_t * Guts_Pmuxcr;
volatile uint32_t * Gpio3_Gpdir;
volatile uint32_t * Gpio3_Gpdat;
// e500 Core View To Power Architecture CCSR: 0x0_FF70_
// GUTS_PMUXCR:Alternate Function Signal Multiplex Control Register
Guts_Pmuxcr = (volatile uint32_t *)(0xFF7E0060);
// GPIO3_GPDIR: GPIO3 direction register
Gpio3_Gpdir = (volatile uint32_t *)(0xFF70F200);
// GPIO3_GPDAT: GPIO3 data register
Gpio3_Gpdat = (volatile uint32_t *)(0xFF70F208);
// Enable GPIO3[10]: IRQ_DEBUG1_GPIO FIELD [BIT 26] set to "1"
*(Guts_Pmuxcr) = 0x0010;
// Set Direction for GPIO3[10] to Output: FIELD DR10 [BIT 10] set to '1'
*(Gpio3_Gpdir) = 0x0020;
// Set GPIO3[10] to '0': FIELD D10 [BIT 10] set to '0'
*(Gpio3_Gpdat) = 0x;
printk("Hello World!\n");
return 0;
}
void cleanup_module(void)
{
printk("Goodbye Cruel World!\n");
}
MODULE_LICENSE("GPL");
When I write insmod GPIO.ko in the terminal I get error these errors:
Unable to handle kernel paging request for data at address 0xff7e0060
faulting instruction address: 0xf107e05c
Oops: Kernel access of bad area, sig: 11 [#1]
..
.
How can I solve this problem?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Provide sftp-client support in yocto
Amit Tomer wrote: >Yes Anders, I can see openssh-sftp folder inside >"tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/packages-split".But >its empty one. Ok, then the sftp binary should have been packaged into openssh-sftp. The question is then why your package is being empty. You said that the sftp binary was available in tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/bin, cab you so find out there? Do you get any clue from the packaging log as to why openssh-sftp is empty? If you run 'bitbake openssh -e' and search for FILES_openssh-sftp, what does it tell you? In which directory under packages-split can you find sftp? > >DISTRO= "poky" > >DISTRO_VERSION= "1.4.2" It should work. Unless there something that overrides the packaging (and splitting) step in any other layer you might have configured. I won't be able to run any tests on my own until early next week. If necessary, I hope that someone else might be able to help you until then. Cheers, Anders > >This is taken from build confriguation. > > >Thanks > >Amit. > > > >On Tue, Oct 1, 2013 at 7:37 PM, Anders Darander >wrote: > > > >Amit Tomer wrote: >>Thansk Anders for your kind response >> >> >>Yes we are created our image and can see there are some IMAGE_INSTALL >>already used > >Good. > > >>But when I add IMAGE_INSTALL += "openssh-sftp" >> >> >>Getting below error >> >> >>Error: openssh-sftp not found in the base feeds (fzm_lsp_k2 >>cortexa15hf-vfp-neon cortexa15hf-vfp armv7ahf-vfp-neon armv7ahf-vfp >>armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all). >> >> >>Do we need to do something more here > >That should have been enough. > >If you look in >tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/packages-split, do you >see openssh-sftp there, or which packages do you have there? > >Which version of Yocto / Poky are you using? What layers do you have >enabled? > >Cheers, >Anders > > >>Thanks >> >>Amit >> >> >> >> >> >>On Tue, Oct 1, 2013 at 6:56 PM, Anders Darander > >>wrote: >> >>* Amit Tomer [131001 14:57]: >> >>> Just now I have seen your responses ,didn't get any notification of >>your >>> responses on my mail-id. >> >>> Let me present my problem again to you guys. >> >>> We have stfp-server running fine on put target machine and is >running >>as part >>> of sshd daemon. >> >>Ok, that sounds good. Then the server is apparantly no problem for >you. >> >> >>> But when we try to connect to other machine from target board, sftp >>is not >>> working becaue our borad is set to run as sftp -client. >> >>> An SFTP client program called sftp is already insatlled to tmp/work/ >>> fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/bin. >> >>The build process built sftp (the client) as a part of building >>openssh. >>The client was packaged into a separate package, called openssh-sftp. >> >> >>> But on Target I could not find this sftp .bins. >> >>Now you need to install that package, openssh-sftp, to your image. >> >>If you have created your own image, just add openssh-sftp to >>IMAGE_INSTALL. >> >>If you're not creating your own images, I'd strongly suggest that you >>do >>that. (It'll make all your customizations a lot easier in the end). >See >>http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage-custombb >>for more information. >> >>I hope this answers your question. >> >>Cheers, >>Anders >> >> >>> Now we want this stfp run as some daemon or part of sshd daemon >>itself. >> >>> Anders: It's already being installed to a package named openssh-sftp >> >>> We don't have package named openssh-sftp ,we have package named with >>openssh >>> only >> >>> Thanks >>> Amit >> >> >> >> >> >> >> >>> On Tue, Oct 1, 2013 at 1:22 PM, Amit Tomer >>wrote: >> >>> I am new to OpenEmbedded Yocto project and have a requirement to >>provide >>> sftp-client support on my target board. >> >>> Sftp-server bins are already packed into final image and is >>installed at >> >>> >>tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/ >>> sftp-server >> >>> Now ,same way Do I have to install stfp client bins also or is >>there any >>> other way to go about it?? >> >>> Thanks >>> Amit >> >> >> >> >> >> >> >>-- >>Anders Darander >>ChargeStorm AB / eStorm AB > >-- >Anders Darander > >ChargeStorm AB Tel: +46 702 44 84 36 >Laxholmstorget 3Email: and...@chargestorm.se >602 21 Norrköping Web: www.chargestorm.se > >Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Anders Darander ChargeStorm AB Tel: +46 702 44 84 36 Laxholmstorget 3 Email: and...@chargestorm.se 602 21 Norrköping Web: www.chargestorm.se Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "Kernel access of bad area" in kernel module
Jack wrote:
>Hi,
>I want to set/reset GPIO registers in freescale p1022 processor. I saw
>a
>hello-mod kernel module in yocto and I added it to my image and it
>worked.
>According to hello-mod kernel module, I created GPIO module like
>hello-mod.
>But it GPIO module failed when I run it in kernel level. I checked
>several
>times addresses of registers and it seems accurate.
>My code is here :
>
>
>#include
>
>int init_module(void)
>{
> volatile uint32_t * Guts_Pmuxcr;
> volatile uint32_t * Gpio3_Gpdir;
> volatile uint32_t * Gpio3_Gpdat;
>
> // e500 Core View To Power Architecture CCSR: 0x0_FF70_
>
>// GUTS_PMUXCR:Alternate Function Signal Multiplex Control Register
> Guts_Pmuxcr = (volatile uint32_t *)(0xFF7E0060);
>
>// GPIO3_GPDIR: GPIO3 direction register
> Gpio3_Gpdir = (volatile uint32_t *)(0xFF70F200);
>
>// GPIO3_GPDAT: GPIO3 data register
> Gpio3_Gpdat = (volatile uint32_t *)(0xFF70F208);
You should generally a of trying to dereference physical addresses, or you
should explicitly declare them as such.
If suggest looking for some info on using GPIO on your CPU. Unfortunately, I've
not used the p1022, so I can't really help you.
http://linuxppc.10917.n7.nabble.com/Re-GPIO-IRQ-on-P1022-td59356.html discusses
some IRQ issues, though you should be able to use the codes as an example of
the GPIO framework and how to use it.
Cheers,
Anders
>
> // Enable GPIO3[10]: IRQ_DEBUG1_GPIO FIELD [BIT 26] set to "1"
> *(Guts_Pmuxcr) = 0x0010;
>
>
> // Set Direction for GPIO3[10] to Output: FIELD DR10 [BIT 10] set to
>'1'
> *(Gpio3_Gpdir) = 0x0020;
>
>
> // Set GPIO3[10] to '0': FIELD D10 [BIT 10] set to '0'
> *(Gpio3_Gpdat) = 0x;
>
> printk("Hello World!\n");
> return 0;
>}
>
>void cleanup_module(void)
>{
> printk("Goodbye Cruel World!\n");
>}
>
>MODULE_LICENSE("GPL");
>
>
>When I write insmod GPIO.ko in the terminal I get error these errors:
>
>Unable to handle kernel paging request for data at address 0xff7e0060
>faulting instruction address: 0xf107e05c
>Oops: Kernel access of bad area, sig: 11 [#1]
>..
>.
>
>
>How can I solve this problem?
>
>
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
--
Anders Darander
ChargeStorm AB Tel: +46 702 44 84 36
Laxholmstorget 3 Email: and...@chargestorm.se
602 21 Norrköping Web: www.chargestorm.se
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] nativesdk-dbus not shipped for meta-toolchain-qt
Hello We are trying to bitbake meta-toolchain-qt with master and dora. Both launch this error: ERROR: QA Issue: nativesdk-dbus: Files/directories were installed but not shipped /run /run/dbus ERROR: QA run found fatal errors. Please consider fixing them. We compare it to dylan dbus. We found that dora is creating a package-split named nativesdk-dbus with the symbolink link run at build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-dbus/1.6.10-r6.0/packages-split/nativesdk-dbus/opt/poky/1.5/sysroots/i686-pokysdk-linux/var. That link is pointing to /run host directory (a bad thing, we suppose). That link in dylan is pointing to volatile/run (a folder inside the package-split) We try to manually delete the link and recreate it and the folders, but bitbake clean everything and it create again. Any clue about how to solve this? Thank you ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] [eclipse-poky-juno] sdk.remotetools: use xterm for latencytop
Use xterm instead of vt100 in order to avoid having
unreadable output for latencytop due to some control characters.
Signed-off-by: Tudor Florea
---
.../src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
index e931388..1ef34cb 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
@@ -13,7 +13,7 @@ package org.yocto.sdk.remotetools.actions;
public class LatencytopHandler extends DialogHandler {
- private static String initCmd="export
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin; cd; sudo latencytop\r";
+ private static String initCmd="export TERM=xterm; export
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin; cd; sudo latencytop\r";
@Override
protected String getInitCmd() {
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] [eclipse-poky-kepler] sdk.remotetools: use xterm for latencytop
Use xterm instead of vt100 in order to avoid having
unreadable output for latencytop due to some control characters.
Signed-off-by: Tudor Florea
---
.../src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
index e931388..1ef34cb 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
@@ -13,7 +13,7 @@ package org.yocto.sdk.remotetools.actions;
public class LatencytopHandler extends DialogHandler {
- private static String initCmd="export
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin; cd; sudo latencytop\r";
+ private static String initCmd="export TERM=xterm; export
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin; cd; sudo latencytop\r";
@Override
protected String getInitCmd() {
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can I extend split_and_strip_files() in packages.bbclass with Erlang beam support ?
Ok, so now I am at it again :) The package.bbclass is missing support for stripping .beam files. Nothing strange about that. But, now I wish to extend this class with support for erlang .beam files. Initially I do not wish to add this functionality directly into package.bbclass since it will require an erlang execution environment + an erlang escript to run. I do not know if we want that ;) Is it possible to extend the split_and_strip_files() function in some other way using eg the _append postfix? Since this function is a real a beast (with good reason), copying it and making it a strict beam detector (instead of elf) might not be the most attractive solution though :( I assume I need to sneak in the beam stripping in the middle of the processing somewhere since once split_and_strip_files() is completed, actual packaging will commence, and after that it will be too late. Any ideas? Might patching package.bbclass be an alternative? In that case, how to avoid dragging in an erlang-native dependency into package.bbclass if it is not needed? (also considering erlang is not yet officially supported by Yocto/OE-core). Thanks. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] meta-yocto: Removed obsolete distros from SANITY_TESTED_DISTROS in poky.conf
Removed CentOS-6.3, Fedora-17, Debian-6.0 and Poky-1.3 from SANITY_TESTED_DISTROS. Signed-off-by: Alexandru Palalau --- meta-yocto/conf/distro/poky.conf | 4 1 file changed, 4 deletions(-) diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf index 4752356..465dbb9 100644 --- a/meta-yocto/conf/distro/poky.conf +++ b/meta-yocto/conf/distro/poky.conf @@ -72,18 +72,14 @@ CONNECTIVITY_CHECK_URIS ?= " \ http://bugzilla.yoctoproject.org/report.cgi"; SANITY_TESTED_DISTROS ?= " \ -Poky-1.3 \n \ Poky-1.4 \n \ Poky-1.5 \n \ Ubuntu-12.04 \n \ Ubuntu-12.10 \n \ Ubuntu-13.04 \n \ -Fedora-17 \n \ Fedora-18 \n \ Fedora-19 \n \ -CentOS-6.3 \n \ CentOS-6.4 \n \ -Debian-6.0 \n \ Debian-6.0.7 \n \ Debian-7.0 \n \ Debian-7.1 \n \ -- 1.8.1.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] meta-yocto: Removed obsolete distros from SANITY_TESTED_DISTROS in poky.conf
Hi Alex, On Tuesday 01 October 2013 19:40:04 Alexandru Palalau wrote: > Removed CentOS-6.3, Fedora-17, Debian-6.0 and Poky-1.3 from > SANITY_TESTED_DISTROS. Sorry, I forgot to mention last time, these patches should go to the poky mailing list. Also, this is somewhat pedantic, but the shortlog prefix should be "poky.conf:" rather than "meta-yocto:". Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On Oct 1, 2013, at 6:16 AM, Hans Beckérus wrote:
> Hello. We have stumbled into a problem when using ld directly instead
> of going through the gcc frontend.
> A simple operation like this fails:
>
>> ${CC} -c hello_world.c
>> ${LD} hello_world.o -lgcc
> arm-poky-linux-gnueabi-ld: cannot find -lgcc
>
> And yes, I know -lgcc is not required in this case to compile this
> one, but this is only a simple reproducer.
> The real issue was discovered when trying to build U-Boot from the SDK.
>
> To resolve this problem we are forced to provide
> -L/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
> But that should not be needed, should it? Anyone else bumped into this
> problem? Are there any "real" solutions.
> I am starting to think it has to do with the hardcoded installation
> path in the binaries maybe?
I doubt that infact we try hard to keep it relocatable. The problem is you are
interpreting
--sysroot option to do more than what its supposed to do. when linking it only
affects INPUT, GROUP
and SEARCH_DIR linker script variables and if you look at the linker script
path to libgcc is not
specified in SEARCH_DIR, thats where gcc driver comes handy in figuring out
where the right libgcc is installed
and sometimes when you have complex multilib environments thats very handy.
linker does not know
anything about libgcc its just another library for it.
however you could do something like
${CC} -print-libgcc-file-name or ${CC} -print-file-name=libgcc.a
to get to the library
and specify that in your linker cmdline
-Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On 2013-10-01 7:35, Khem Raj wrote:
> On Oct 1, 2013, at 6:16 AM, Hans Beckérus wrote:
>
>> Hello. We have stumbled into a problem when using ld directly instead
>> of going through the gcc frontend.
>> A simple operation like this fails:
>>
>>> ${CC} -c hello_world.c
>>> ${LD} hello_world.o -lgcc
>> arm-poky-linux-gnueabi-ld: cannot find -lgcc
>>
>> And yes, I know -lgcc is not required in this case to compile this
>> one, but this is only a simple reproducer.
>> The real issue was discovered when trying to build U-Boot from the SDK.
>>
>> To resolve this problem we are forced to provide
>> -L/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
>> But that should not be needed, should it? Anyone else bumped into this
>> problem? Are there any "real" solutions.
>> I am starting to think it has to do with the hardcoded installation
>> path in the binaries maybe?
> I doubt that infact we try hard to keep it relocatable. The problem is you
> are interpreting
> --sysroot option to do more than what its supposed to do. when linking it
> only affects INPUT, GROUP
> and SEARCH_DIR linker script variables and if you look at the linker script
> path to libgcc is not
> specified in SEARCH_DIR, thats where gcc driver comes handy in figuring out
> where the right libgcc is installed
> and sometimes when you have complex multilib environments thats very handy.
> linker does not know
> anything about libgcc its just another library for it.
Hi Khem, thanks for your time. I am sure I put too much value into --sysroot,
but what still strikes me a bit odd is why the simple reproducer I showed
before works just fine using the local host gcc and ld? It seems to have no
issues in finding libgcc.a?
So what you are saying is that it is actually expected that U-Boot build will
fail when compiled through the SDK toolchain directly without adding additional
options to the linker? Is that also what the u-boot recipe is doing? After all,
it works fine to bitbake u-boot.
> however you could do something like
>
> ${CC} -print-libgcc-file-name or ${CC} -print-file-name=libgcc.a
>
> to get to the library
>
> and specify that in your linker cmdline
Ok, guess it will simply give me the same path as we are currently hardcoding,
but if the toolchain moves your solution is definitely to prefer.
Thanks for the tip. Did only not know about the --print-sysroot command until
now.
> -Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [v2][meta-security][PATCH] Bastille/lib-perl: Remove dependency on lib-perl
Remove lib-perl from meta-security entirely since it has been a part of
PERL since 5.001.
The Bastille dependency is now on perl-module-lib, already noted as an
RDEPENDS for other parts of meta-security.
Signed-off-by: Joe MacDonald
---
recipes-security/bastille/bastille_3.2.1.bb |2 +-
recipes-security/perl/lib-perl_0.63.bb | 28 ---
2 files changed, 1 insertion(+), 29 deletions(-)
delete mode 100644 recipes-security/perl/lib-perl_0.63.bb
diff --git a/recipes-security/bastille/bastille_3.2.1.bb
b/recipes-security/bastille/bastille_3.2.1.bb
index 969ce30..d2f9aa6 100644
--- a/recipes-security/bastille/bastille_3.2.1.bb
+++ b/recipes-security/bastille/bastille_3.2.1.bb
@@ -6,7 +6,7 @@ LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://${S}/COPYING;md5=c93c0550bd3173f4504b2cbd8991e50b"
# Bash is needed for set +o privileged (check busybox), might also need ncurses
DEPENDS = "virtual/kernel"
-RDEPENDS_${PN} = "perl bash tcl perl-module-getopt-long perl-module-text-wrap
lib-perl perl-module-file-path perl-module-mime-base64 perl-module-file-find
perl-module-errno perl-module-file-glob perl-module-tie-hash-namedcapture
perl-module-file-copy perl-module-english perl-module-exporter perl-module-cwd
libcurses-perl coreutils"
+RDEPENDS_${PN} = "perl bash tcl perl-module-getopt-long perl-module-text-wrap
perl-module-lib perl-module-file-path perl-module-mime-base64
perl-module-file-find perl-module-errno perl-module-file-glob
perl-module-tie-hash-namedcapture perl-module-file-copy perl-module-english
perl-module-exporter perl-module-cwd libcurses-perl coreutils"
FILES_${PN} += "/run/lock/subsys/bastille"
inherit allarch module-base
diff --git a/recipes-security/perl/lib-perl_0.63.bb
b/recipes-security/perl/lib-perl_0.63.bb
deleted file mode 100644
index c05ae1e..000
--- a/recipes-security/perl/lib-perl_0.63.bb
+++ /dev/null
@@ -1,28 +0,0 @@
-DESCRIPTION = "This is a small simple module which simplifies the \
-manipulation of @INC at compile time. It is typically used to add extra \
-directories to Perl's search path so that later "use" or "require" statements \
-will find modules which are not located in the default search path."
-
-SECTION = "libs"
-LICENSE = "Artistic-1.0 | GPL-1.0+"
-PR = "r0"
-
-LIC_FILES_CHKSUM =
"file://README;beginline=26;endline=30;md5=94b119f1a7b8d611efc89b5d562a1a50"
-
-DEPENDS += "perl"
-
-SRC_URI = "http://www.cpan.org/authors/id/S/SM/SMUELLER/lib-${PV}.tar.gz";
-
-SRC_URI[md5sum] = "8607ac4e0d9d43585ec28312f52df67c"
-SRC_URI[sha256sum] =
"72f63db9220098e834d7a38231626bd0c9b802c1ec54a628e2df35f3818e5a00"
-
-S = "${WORKDIR}/lib-${PV}"
-
-EXTRA_CPANFLAGS = "EXPATLIBPATH=${STAGING_LIBDIR}
EXPATINCPATH=${STAGING_INCDIR}"
-
-inherit cpan
-
-do_compile() {
- export LIBC="$(find ${STAGING_DIR_TARGET}/${base_libdir}/ -name
'libc-*.so')"
- cpan_do_compile
-}
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, October 01, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Attendees: Mark, Michael, Cristian, Darren, Corneliu, Paul, Tom, JeffP, Jessica, ScottR, Saul, Nitin, Beth, AlexG, Ross, Song Agenda: * Opens collection - 5 min (Song) * Yocto 1.5 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status - Bug fixing: Thanks to the team, we resolved 59 bugs in the past week. WDD number is down significantly. Great work. Let's keep it up to bring the WDD number down further. - QA: Full pass QA report on the last RC is out on the public mailing list. There are some meta-intel BSP problems. Nitin already have a fix, no impact to oe-core. - Build: doing RC build today, QA will do targeted testing for feature verification, Jason's patches for supporting iso EFI images might need more testing too. - RP may not be available. But waiting for him to pull in more patches before the RC build. - Partitioning: all patches are sent, cleanup work is done. Waiting for Richard to pull the patches. * SWAT team rotation: Saul * Opens - 10 min * Team Sharing - 20 min - Christian: mainly bug fixing for the moment, working on DNS issue, etc. - MichaelH: commercial data center is coming online. Very short downtime. Will have much faster connection. Nothing will happen today. Will be sometime this week. In plan. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ${libdir} usage
Hi,
I'm currently putting together a bunch of recipes to install some cpan
modules. I had some complaints by bitbake about files being installed
but not shipped.
I figured that I need to populate FILES_{PN} but I'm not clear about
what I should do with it: use ${libdir}, use "usr/*" ? Knowing that my
image(s) directories mostly contain usr/lib/perl/* and sometimes usr/bin/*
What's the best practice ? That'll save me some time when I send the
patch :)
Thanks for your help
Jay
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On Oct 1, 2013, at 11:03 AM, Hans Beckerus wrote:
> On 2013-10-01 7:35, Khem Raj wrote:
>> On Oct 1, 2013, at 6:16 AM, Hans Beckérus wrote:
>>
>>> Hello. We have stumbled into a problem when using ld directly instead
>>> of going through the gcc frontend.
>>> A simple operation like this fails:
>>>
${CC} -c hello_world.c
${LD} hello_world.o -lgcc
>>> arm-poky-linux-gnueabi-ld: cannot find -lgcc
>>>
>>> And yes, I know -lgcc is not required in this case to compile this
>>> one, but this is only a simple reproducer.
>>> The real issue was discovered when trying to build U-Boot from the SDK.
>>>
>>> To resolve this problem we are forced to provide
>>> -L/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
>>> But that should not be needed, should it? Anyone else bumped into this
>>> problem? Are there any "real" solutions.
>>> I am starting to think it has to do with the hardcoded installation
>>> path in the binaries maybe?
>> I doubt that infact we try hard to keep it relocatable. The problem is you
>> are interpreting
>> --sysroot option to do more than what its supposed to do. when linking it
>> only affects INPUT, GROUP
>> and SEARCH_DIR linker script variables and if you look at the linker script
>> path to libgcc is not
>> specified in SEARCH_DIR, thats where gcc driver comes handy in figuring out
>> where the right libgcc is installed
>> and sometimes when you have complex multilib environments thats very handy.
>> linker does not know
>> anything about libgcc its just another library for it.
> Hi Khem, thanks for your time. I am sure I put too much value into --sysroot,
> but what still strikes me a bit odd is why the simple reproducer I showed
> before works just fine using the local host gcc and ld? It seems to have no
> issues in finding libgcc.a?
Does it ? what distro are you using on build host. gcc -c hello.c;ld hello.o
-lgcc , does that work ?
on my Ubuntu based system it fails exact same way as OE SDK, and for the
reasons I described
if you use bare ld to do linking then you can not assume it to resolve all kind
of environment for you
gcc driver is there for a reason.
> So what you are saying is that it is actually expected that U-Boot build will
> fail when compiled through the SDK toolchain directly without adding
> additional options to the linker? Is that also what the u-boot recipe is
> doing? After all, it works fine to bitbake u-boot.
No, the magic is in u-boot itself see in top level Makefile
PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(CFLAGS)
-print-libgcc-file-name`) -lgcc
>
>> however you could do something like
>>
>> ${CC} -print-libgcc-file-name or ${CC} -print-file-name=libgcc.a
>>
>> to get to the library
>>
>> and specify that in your linker cmdline
> Ok, guess it will simply give me the same path as we are currently
> hardcoding, but if the toolchain moves your solution is definitely to prefer.
> Thanks for the tip. Did only not know about the --print-sysroot command until
> now.
>> -Khem
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] 1.5_M5.rc6 available for testing.
All 1.5_M5.rc6 is now available for testing. We've identified one issue with package index https://bugzilla.yoctoproject.org/show_bug.cgi?id=5277 Artifacts are available: http://autobuilder.yoctoproject.org/pub/releases/1.5_M5.rc6 poky 0197e5cb4253d6137b0d166cfcd699d404d2cab3 eclipse-poky-juno 9cff88d9b3043547e3ad6264f5af3f4a8d367496 eclipse-poky-kepler ab0acbd9e7fa3b5bc48af72c569b4ed1f7d686bb meta-qt3 199986d8fc59a18cd660dbad635076fc9d4d7cc3 meta-minnow 38c2d6ec6c9f8880ff86bed10aa95589850dc214 meta-intel 0dbdf993f8a7e8005248ffac3a5feba1f8ad3623 meta-fsl-arm 60b2189d29851b9bc066e129b2945163214bc742 meta-fsl-ppc 25ee629b826a138ef407c113f776830e5d822c01 -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
