aboutsummaryrefslogtreecommitdiffstats
path: root/arch/ia64/hp/sim/boot/Makefile
Commit message (Collapse)AuthorAge
* [kbuild] handle exports in lib-y objects reliablyAl Viro2016-08-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Collect the symbols exported by anything that goes into lib.a and add an empty object (lib-exports.o) with explicit undefs for each of those to obj-y. That allows to relax the rules regarding the use of exports in lib-* objects - right now an object with export can be in lib-* only if we are guaranteed that there always will be users in built-in parts of the tree, otherwise it needs to be in obj-*. As the result, we have an unholy mix of lib- and obj- in lib/Makefile and (especially) in arch/*/lib/Makefile. Moreover, a change in generic part of the kernel can lead to mysteriously missing exports on some configs. With this change we don't have to worry about that anymore. One side effect is that built-in.o now pulls everything with exports from the corresponding lib.a (if such exists). That's exactly what we want for linking vmlinux and fortunately it's almost the only thing built-in.o is used in. arch/ia64/hp/sim/boot/bootloader is the only exception and it's easy to get rid of now - just turn everything in arch/ia64/lib into lib-* and don't bother with arch/ia64/lib/built-in.o anymore. [AV: stylistic fix from Michal folded in] Acked-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* [IA64] export copy_page() to modulesAndrew Morton2007-12-07
| | | | | | | | | | | | | | | | | With the unionfs patch applied I get ERROR: "copy_page" [fs/unionfs/unionfs.ko] undefined! the other architectures (some, at least) export copy_page() so I guess ia64 should also do so. To do this we need to move the copy_page() functions out of lib.a and into built-in.o and add the EXPORT_SYMBOL(). Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
* Linux-2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!