| 1 |
On Tue, 2009-07-21 at 14:15 +0200, Fabian Groffen wrote: |
| 2 |
> On 21-07-2009 13:33:26 +0200, Markus Duft wrote: |
| 3 |
> > i spent another few hours on getting this right. attached is a (way |
| 4 |
> > smaller) new version of the patch, making both interix and winnt work. |
| 5 |
> > the patch is written as such, that other platforms may be easily added |
| 6 |
> > in the future (i think of hppa-hpux and aix - i talked to haubi, and the |
| 7 |
> > format of the NEEDED.PFX.1 files is ok - if not, we can still |
| 8 |
> > change :)). |
| 9 |
> |
| 10 |
> I actually don't understand why you took .PFX this time. It seems this |
| 11 |
> stands for Prefix, as the python code is doing now too. I don't really |
| 12 |
> understand what Prefix is different from ELF in this case. It works |
| 13 |
> fine on Linux and Solaris ELF in Prefix. So what was the idea behind |
| 14 |
> PFX? I think ITX was better. If it's really because you hate to waste |
| 15 |
> space in the python code on inventing new format names, you might better |
| 16 |
> call it ELFLIKE or something. However, the MACHO case won't ever fit in |
| 17 |
> it, and we decided to split it off, because that also will make other |
| 18 |
> tools that read/use it fail because of file not found, instead of not |
| 19 |
> understanding the file format, or its contents. |
| 20 |
|
| 21 |
the idea behind PFX was to gather together all platforms that use a |
| 22 |
similar format, and make implementing preserve-libs for thos platforms |
| 23 |
as easy as writing another scanbin_* function in scanbin-prefix. after |
| 24 |
thinking a little more of it, and discussing with haubi, i think you're |
| 25 |
right. i renamed scanbin-prefix to scanpecoff and the NEEDED file to |
| 26 |
NEEDED.PECOFF.1. this way we keep up the correct naming for the file |
| 27 |
format, and even have a binary that follows the naming on other |
| 28 |
platforms (although it's usage is a little different, but only portage |
| 29 |
should care :)). |
| 30 |
|
| 31 |
Another approach would have been to call the NEEDED file NEEDED.ELF.2 |
| 32 |
too, as both interix and windows try to mimic ELF, and thus have the |
| 33 |
same information stored on disk - this way external tools (as you |
| 34 |
mentioned) wouldn't even need to know that it's interix/winnt, it would |
| 35 |
just work - however this would be a plain lie, which i don't like that |
| 36 |
much. |
| 37 |
|
| 38 |
What i was talking about regarding the LinkageMapMacho, was to make the |
| 39 |
class inherit from LinkageMap, and remove functions that are the exact |
| 40 |
same in both (and thus inherit them from LinkageMap - it's the same |
| 41 |
code). i did that for (now) LinkageMapPeCoff, which works fine - |
| 42 |
LinkageMapPeCoff is now only a few lines long. |
| 43 |
|
| 44 |
> |
| 45 |
> So please consider this. What's the benefit of squeezing them all into |
| 46 |
> one file/format? Only if you're absolutely sure this is completely |
| 47 |
> compatible, and also for the future, without harming others, then it |
| 48 |
> could be done. But on the other hand, giving each its own file name |
| 49 |
> takes not much more, especially if they share the implementation, but |
| 50 |
> allows easy upgrade/bump/migration if ever they /need/ to be |
| 51 |
> fixed/changed/etc. |
| 52 |
|
| 53 |
the plan was to reduce the amount of work needed to introduce |
| 54 |
preserve-libs to a new platform which is ELF-like and thus has the same |
| 55 |
linkage information in the NEEDED file. but i guess we're running out of |
| 56 |
such platforms anyway :) |
| 57 |
|
| 58 |
Cheers, Markus |
| 59 |
|
| 60 |
> |
| 61 |
> |
| 62 |
> |
Archives