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