2383 2012-05-01 21:14:52 +0000 Relocatable SDK 2012-08-30 08:40:01 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto 1.3 All Multiple VERIFIED FIXED (P2)(Scheduled) Low enhancement 1.3 M3 2838 1 raj.khem laurentiu.palcu alexandru.c.georgescu bogdan.a.marinescu jason.wessel jessica.zhang poky.bs.watcher poky.watcher richard.purdie song.liu --- --- --- oldest_to_newest 20967 0 raj.khem 2012-05-01 21:14:52 +0000 currently SDKs are not relocatable. It would be a nice feature to dump the SDK anywhere and use it (as long as the tree structure underneath is mantained same) 20970 1 richard.purdie 2012-05-01 22:10:55 +0000 Biggest problem is we hardcode in the path to our dynamic loader. You can't use $ORIGIN in the dynamic loader path. Our only option is probably to write and require some kind of "bounce" binary which would get installed to a known location and allow us to bounce to something $ORIGIN like to locate the dynamic loader. Using the host systems dynamic loader proves problematic since it essentially implies you need the host libc and then you have to link against the lowest common denomninator of the platforms you want to support rather than being independent like we currently are. 21060 2 jason.wessel 2012-05-03 14:14:59 +0000 (In reply to comment #1) > Biggest problem is we hardcode in the path to our dynamic loader. You can't > use $ORIGIN in the dynamic loader path. Our only option is probably to write > and require some kind of "bounce" binary which would get installed to a > known location and allow us to bounce to something $ORIGIN like to locate > the dynamic loader. > Using a "bounce" binary is an interesting idea, but what about the possibility of changing the linker to NULL pad the absolute path to the dynamic loader lookup? With this concept you would not be depending on anything that is external. You would either design in an SDK sanity check to make sure the path the SDK is currently at is the same as the binaries else "update" the binaries as needed. Or leave behind a "setup_sdk.sh" script with the intended purpose that you run it to generate your initial environment script and do the check and update at that point. 21062 3 richard.purdie 2012-05-03 14:51:07 +0000 (In reply to comment #2) > (In reply to comment #1) > > Biggest problem is we hardcode in the path to our dynamic loader. You can't > > use $ORIGIN in the dynamic loader path. Our only option is probably to write > > and require some kind of "bounce" binary which would get installed to a > > known location and allow us to bounce to something $ORIGIN like to locate > > the dynamic loader. > > > > Using a "bounce" binary is an interesting idea, but what about the > possibility of changing the linker to NULL pad the absolute path to the > dynamic loader lookup? With this concept you would not be depending on > anything that is external. You would either design in an SDK sanity check > to make sure the path the SDK is currently at is the same as the binaries > else "update" the binaries as needed. Or leave behind a "setup_sdk.sh" > script with the intended purpose that you run it to generate your initial > environment script and do the check and update at that point. I agree, this is the other option. We could inject a long linker path, update it to a shorter standard one matching the current baviour as post processing, then have a "relocate" script allowing it to be updated to a new location... 22662 4 laurentiu.palcu 2012-06-28 11:14:13 +0000 I've been doing a little bit of reaserch on both solutions and I might have found a 3rd one which, in my opinion, is the simplest. Unless I got the entire problem completely wrong: - I'll start with Jason's solution. Null padding the dynamic loader path wouldn't be possible unless the linker itself is changed to do that by default. An alternative to this would be to pass a very long pattern (as Richard suggested) that would later be changed to our path. This is doable but we would need some special tools at install time in order to change the pattern in the path we want: readelf would be necessary to get .interp offset in the ELF file(unless we want to write everything from scratch) and a sed-like tool (bbe might be able to do that) to search/replace stuff in binary files (an alternative would be to use a combination of head/tail and temporary files). Aditional tools mean that the user has to install them all in order to complete SDK installation... Not very nice. Another option to this would be to use the patchelf tool, compile it statically and use it at install time to change the dynamic loader path; - Richard's solution: First off, having a binary installed at a known location means that we would need to put in a directory like /lib, /bin, etc. These are known locations that are very unlikely not to exist on a host. But for installing a binary in these locations the user would need root permissions... Are we OK to assume the user has root permissions on the dev machine? Also, depending on the type of bouncing binary, we might need to handle virtual addresses conflicts between first executable and our interpreter. - 3rd solution: based, partially, on Richard's solution. However, instead of a bouncing binary, we have a soft link to the loader itself that gets set at install time: /lib/ld-linux-poky -> <path_to_our_sdk>/lib/ld-linux-x86-64.so.2. So .interp section will be hardcoded to: /lib/ld-linux-poky. It needs, however, root permissions too but it looks like it's the simplest of all. What do you guys say? 22664 5 richard.purdie 2012-06-28 12:02:39 +0000 (In reply to comment #4) > I've been doing a little bit of reaserch on both solutions and I might have > found a 3rd one which, in my opinion, is the simplest. Unless I got the > entire problem completely wrong: > - I'll start with Jason's solution. Null padding the dynamic loader path > wouldn't be possible unless the linker itself is changed to do that by > default. An alternative to this would be to pass a very long pattern (as > Richard suggested) that would later be changed to our path. This is doable > but we would need some special tools at install time in order to change the > pattern in the path we want: readelf would be necessary to get .interp > offset in the ELF file(unless we want to write everything from scratch) and > a sed-like tool (bbe might be able to do that) to search/replace stuff in > binary files (an alternative would be to use a combination of head/tail and > temporary files). Another option here is some kind of script, say in python or perl which simply loads the file as a binary blob, looks for the magic interpreter string within the first say 500 bytes of the file and then rewrites it. In some ways this is pretty nasty but it would also be pretty effective. > Aditional tools mean that the user has to install them all > in order to complete SDK installation... Not very nice. Another option to > this would be to use the patchelf tool, compile it statically and use it at > install time to change the dynamic loader path; > - Richard's solution: First off, having a binary installed at a known > location means that we would need to put in a directory like /lib, /bin, > etc. These are known locations that are very unlikely not to exist on a > host. But for installing a binary in these locations the user would need > root permissions... Are we OK to assume the user has root permissions on the > dev machine? Also, depending on the type of bouncing binary, we might need > to handle virtual addresses conflicts between first executable and our > interpreter. > - 3rd solution: based, partially, on Richard's solution. However, instead of > a bouncing binary, we have a soft link to the loader itself that gets set at > install time: /lib/ld-linux-poky -> > <path_to_our_sdk>/lib/ld-linux-x86-64.so.2. So .interp section will be > hardcoded to: /lib/ld-linux-poky. It needs, however, root permissions too > but it looks like it's the simplest of all. I like the simplicity of it. I'd like to propose a multi-pronged approach with this: a) We test the symlink relocation method, get that working and document it. We need pretty much everything we'd need to do to make that work anyway for subsequent work such as ensuring RPATHS are relocated and symlinks are relative. We have this for -native packages but I'm not sure its being applied to -nativesdk right now. b) Investigate whether we can have the linker take a parameter to pad the interpreter field to a specific length, maybe with a NULL to terminate the name, then magic padding characters so any search/replace utility can spot them. c) Assuming we can get b) working, write a relocation util, probably in a scripting lanaguage that can make the search/replacement. Does that seem like a reasonable plan? 22666 6 laurentiu.palcu 2012-06-28 13:06:01 +0000 (In reply to comment #5) > (In reply to comment #4) > > I've been doing a little bit of reaserch on both solutions and I might have > > found a 3rd one which, in my opinion, is the simplest. Unless I got the > > entire problem completely wrong: > > - I'll start with Jason's solution. Null padding the dynamic loader path > > wouldn't be possible unless the linker itself is changed to do that by > > default. An alternative to this would be to pass a very long pattern (as > > Richard suggested) that would later be changed to our path. This is doable > > but we would need some special tools at install time in order to change the > > pattern in the path we want: readelf would be necessary to get .interp > > offset in the ELF file(unless we want to write everything from scratch) and > > a sed-like tool (bbe might be able to do that) to search/replace stuff in > > binary files (an alternative would be to use a combination of head/tail and > > temporary files). > > Another option here is some kind of script, say in python or perl which > simply loads the file as a binary blob, looks for the magic interpreter > string within the first say 500 bytes of the file and then rewrites it. In > some ways this is pretty nasty but it would also be pretty effective. > > > Aditional tools mean that the user has to install them all > > in order to complete SDK installation... Not very nice. Another option to > > this would be to use the patchelf tool, compile it statically and use it at > > install time to change the dynamic loader path; > > - Richard's solution: First off, having a binary installed at a known > > location means that we would need to put in a directory like /lib, /bin, > > etc. These are known locations that are very unlikely not to exist on a > > host. But for installing a binary in these locations the user would need > > root permissions... Are we OK to assume the user has root permissions on the > > dev machine? Also, depending on the type of bouncing binary, we might need > > to handle virtual addresses conflicts between first executable and our > > interpreter. > > - 3rd solution: based, partially, on Richard's solution. However, instead of > > a bouncing binary, we have a soft link to the loader itself that gets set at > > install time: /lib/ld-linux-poky -> > > <path_to_our_sdk>/lib/ld-linux-x86-64.so.2. So .interp section will be > > hardcoded to: /lib/ld-linux-poky. It needs, however, root permissions too > > but it looks like it's the simplest of all. > > I like the simplicity of it. > > I'd like to propose a multi-pronged approach with this: > > a) We test the symlink relocation method, get that working and document it. > We need pretty much everything we'd need to do to make that work anyway for > subsequent work such as ensuring RPATHS are relocated and symlinks are > relative. We have this for -native packages but I'm not sure its being > applied to -nativesdk right now. So this is just a temporary solution? > > b) Investigate whether we can have the linker take a parameter to pad the > interpreter field to a specific length, maybe with a NULL to terminate the > name, then magic padding characters so any search/replace utility can spot > them. I couldn't find any way to pad the .interp field to the length we want using existing linker options... Unless we patch the linker. > > c) Assuming we can get b) working, write a relocation util, probably in a > scripting lanaguage that can make the search/replacement. If we're talking about sh/bash, it might be a little bit hard (not impossible though). If we use python, it might be easier but the users that don't build yocto themselves and don't have python installed will be forced to do that prior to installing the SDK. If this is acceptable, than I'm for python. > > Does that seem like a reasonable plan? 22667 7 richard.purdie 2012-06-28 13:49:54 +0000 (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > I've been doing a little bit of reaserch on both solutions and I might have > > > found a 3rd one which, in my opinion, is the simplest. Unless I got the > > > entire problem completely wrong: > > > - I'll start with Jason's solution. Null padding the dynamic loader path > > > wouldn't be possible unless the linker itself is changed to do that by > > > default. An alternative to this would be to pass a very long pattern (as > > > Richard suggested) that would later be changed to our path. This is doable > > > but we would need some special tools at install time in order to change the > > > pattern in the path we want: readelf would be necessary to get .interp > > > offset in the ELF file(unless we want to write everything from scratch) and > > > a sed-like tool (bbe might be able to do that) to search/replace stuff in > > > binary files (an alternative would be to use a combination of head/tail and > > > temporary files). > > > > Another option here is some kind of script, say in python or perl which > > simply loads the file as a binary blob, looks for the magic interpreter > > string within the first say 500 bytes of the file and then rewrites it. In > > some ways this is pretty nasty but it would also be pretty effective. > > > > > Aditional tools mean that the user has to install them all > > > in order to complete SDK installation... Not very nice. Another option to > > > this would be to use the patchelf tool, compile it statically and use it at > > > install time to change the dynamic loader path; > > > - Richard's solution: First off, having a binary installed at a known > > > location means that we would need to put in a directory like /lib, /bin, > > > etc. These are known locations that are very unlikely not to exist on a > > > host. But for installing a binary in these locations the user would need > > > root permissions... Are we OK to assume the user has root permissions on the > > > dev machine? Also, depending on the type of bouncing binary, we might need > > > to handle virtual addresses conflicts between first executable and our > > > interpreter. > > > - 3rd solution: based, partially, on Richard's solution. However, instead of > > > a bouncing binary, we have a soft link to the loader itself that gets set at > > > install time: /lib/ld-linux-poky -> > > > <path_to_our_sdk>/lib/ld-linux-x86-64.so.2. So .interp section will be > > > hardcoded to: /lib/ld-linux-poky. It needs, however, root permissions too > > > but it looks like it's the simplest of all. > > > > I like the simplicity of it. > > > > I'd like to propose a multi-pronged approach with this: > > > > a) We test the symlink relocation method, get that working and document it. > > We need pretty much everything we'd need to do to make that work anyway for > > subsequent work such as ensuring RPATHS are relocated and symlinks are > > relative. We have this for -native packages but I'm not sure its being > > applied to -nativesdk right now. > So this is just a temporary solution? Its a stepping stone, yes. I haven't put timescales against any of these items, I'm trying to figure out the long term plan, then we see how soon we can get each piece done. So it might be temporary but might be what we ship for 1.3 for example, depending on time constraints. > > b) Investigate whether we can have the linker take a parameter to pad the > > interpreter field to a specific length, maybe with a NULL to terminate the > > name, then magic padding characters so any search/replace utility can spot > > them. > I couldn't find any way to pad the .interp field to the length we want using > existing linker options... Unless we patch the linker. I'm thinking we should patch the linker. We build it ourselves anyway and the patch shouldn't be too invasive. This issue is important enough that this makes sense. > > c) Assuming we can get b) working, write a relocation util, probably in a > > scripting lanaguage that can make the search/replacement. > If we're talking about sh/bash, it might be a little bit hard (not > impossible though). I don't want to use shell for this. > If we use python, it might be easier but the users that > don't build yocto themselves and don't have python installed will be forced > to do that prior to installing the SDK. If this is acceptable, than I'm for > python. I think python is acceptable as long as we can work on old versions of python, say python 2.4. This is to allow people to install and relocate our "external python" tarball to meet the minimum bitbake python requirement of 2.6. I can't think of any issue with a 2.4 minimum version for something as simple as this script. 23822 8 laurentiu.palcu 2012-08-06 10:32:02 +0000 Patches were merged to master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=e81441a92fff59d617f22387716f6c1a9da5a9af http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=77973e3004b9d3e2d5a59715e30d46e9351d0008 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=749b8a52c68500cca546d705b7ac81905c1fe0e7 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=44df019842bc83cdcf559ac64b989ab3c5febd6a http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=476ced15c244b5a4bb91cef59fdf7e3b5a981576 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=e3a13b8d93cdfe2fdb58ef84f6d58bbbcaeb7a05 24648 9 alexandru.c.georgescu 2012-08-30 08:40:01 +0000 Setting it to verified-fixed. The SDK installs in the desired location.