| Summary: | dev-lang/fpc-2.2.4-r2 ebuild with x86 support on amd64 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Konstantin Münning <konstantin> |
| Component: | New packages | Assignee: | Amy Liffey <amynka> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | enhancement | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
fpc-2.2.4-r2.ebuild
fpc-2.2.4-crtlinkpath.patch fpc-2.6.0.ebuild fpc-2.6.0-crtlinkpath.patch |
||
|
Description
Konstantin Münning
2010-06-06 11:10:15 UTC
Created attachment 234293 [details]
fpc-2.2.4-r2.ebuild
Created attachment 234295 [details, diff]
fpc-2.2.4-crtlinkpath.patch
To be placed in files directory.
FreePascal build uses a dumb routine to search for crtbegin.o, crti.o, crtend.o and crtn.o and uses their absolute paths for linking. This way it tries to link amd64 (as they are found first) and x86 files together which of course fails. This patch removes the absolute paths and lets ld determine the right version. Maybe good to be reported upstream?
Thanks for the suggestion. A few small comments on your implementation - this should check `use amd64 && use multilib`, rather than bringing in a new flag. Simply rename the flag you're using now, and make sure to also check amd64 in SRC_URI. - you're redefining S, which is a bit nasty. Maybe use a new variable? Other than that, the ebuild changes look about right. As for the patch, though, that doesn't look right to me, but maybe I'm missing something. You're letting fpc-i386 continue to look in /usr/lib only to ignore the results, rather than making fpc-i386 know about lib32. fpc uses the library dirs also for looking for actual libraries, and this won't work if it continues to check /usr/lib, will it? This would be a welcome addition, and would definitely be good to report upstream. Would you do so, and link back to the report here? (In reply to comment #3) Thanks for the comments. - yes, using multilib may be a better idea but I'm not sure about its exact meaning. The emul-linux-x86 flag is not my invention, it appears in profiles/arch/amd64/use.mask and seemed right to me. My first idea was to use something like the LINGUAS variable, a FPC_ARCHS, but as the only architecture I know it makes sense for now is amd64 and the effort to get this in portage seems to be large I preferred the flag. What do you mean by checking amd64 in SRC_URI? Using amd64-FPC on a x86 machine will not work. - I didn't like the redefinition of S myself but it is the way the in-tree ebuild does that. I tried to do minimal changes so it's easier for the original ebuild maintainer to use my ebuild. - as for my patch, I'm not ignoring the results but am only using the filenames without paths (in case they were found). To make it work better the dumb search routine must be extended to do some architecture checks on the files it finds or some other non-trivial magic to select the right file out of the found candidates. This should really be done upstream ;-). I'm not sure if this is really necessary as it is used only to generate the link resource file so omitting the paths lets ld do the magic. Maybe skipping all the searches for these would be OK but would require more testing. Changing to search only in lib32 for x86 is IMHO not a good idea as on normal x86 machines there is no lib32 and I'm not sure of the impact. I'll see about the upstream report and post anything new here. (In reply to comment #4) > - yes, using multilib may be a better idea but I'm not sure about its exact > meaning. The emul-linux-x86 flag is not my invention, it appears in > profiles/arch/amd64/use.mask and seemed right to me. Interesting, I did not know about that. emul-linux-x86 is not used in any ebuilds though, it looks to be something from a few years back that's left over in the profiles, and that pretty much did what use amd64 && use multilib more generally does now. use multilib is not specific to any one arch, but it means enable support for multiple libdirs, which for amd64 means lib32/lib64 or x86/amd64, but other architectures have different multilib setups. > My first idea was to use > something like the LINGUAS variable, a FPC_ARCHS, but as the only architecture > I know it makes sense for now is amd64 and the effort to get this in portage > seems to be large I preferred the flag. I agree that it's too broad for just this, but your FPC_ARCHS idea might be a useful later addition for people wishing to cross-compile using fpc. > What do you mean by checking amd64 in > SRC_URI? Using amd64-FPC on a x86 machine will not work. I know, I mean that setting `emul-linux-x86` in your ebuild, when not on amd64, will not install fpc for x86, but will still download the binary. SRC_URI can contain amd64? ( multilib? ( ... ) ) to avoid this. (USE=emul-linux-x86 on ppc would be silly, but USE=multilib on that same ppc is not.) > - I didn't like the redefinition of S myself but it is the way the in-tree > ebuild does that. I tried to do minimal changes so it's easier for the original > ebuild maintainer to use my ebuild. The current ebuild sets S once, at global scope, and that's fine, you're supposed to be able to set S there. You're modifying it during the build process. > - as for my patch, I'm not ignoring the results but am only using the filenames > without paths (in case they were found). The way I'm reading the code -- and do correct me if I'm misreading it -- is that you're looking for crtn.o in /usr/lib (and other directories), and if you find it there, you pass crtn.o to the linker without checking whether the 32-bit crtn.o in /usr/lib32 exists too. > To make it work better the dumb search > routine must be extended to do some architecture checks on the files it finds > or some other non-trivial magic to select the right file out of the found > candidates. This should really be done upstream ;-). Take a look at the existing /etc/fpc.cfg and its #ifdefs :) There doesn't really need to be any magic, the configuration file can make sure the correct paths are searched depending on which compiler binary is called. > I'm not sure if this is > really necessary as it is used only to generate the link resource file so > omitting the paths lets ld do the magic. What I meant with searching for libraries seems to be wrong, so forget about that, I agree then, that omitting the paths is good for ld, but the problem with checking whether crt*.o should be used at all still exists. > Maybe skipping all the searches for > these would be OK but would require more testing. Changing to search only in > lib32 for x86 is IMHO not a good idea as on normal x86 machines there is no > lib32 and I'm not sure of the impact. Right, any patch that breaks fpc on a pure x86 system is definitely bad. > I'll see about the upstream report and post anything new here. Thanks! Created attachment 317898 [details]
fpc-2.6.0.ebuild
Here the enhanced ebuild for the latest FPC version. Made out of official ebuild.
Created attachment 317900 [details, diff]
fpc-2.6.0-crtlinkpath.patch
Here the according patch to be placed in files directory.
I still have to check if upstream has a better approach for this.
(In reply to Konstantin Münning from comment #7) > Created attachment 317900 [details, diff] [details, diff] > fpc-2.6.0-crtlinkpath.patch > > Here the according patch to be placed in files directory. > > I still have to check if upstream has a better approach for this. Is this still valid for version 2.6.4 which is now in tree? Thanks Amy |
