http://bugs.freedesktop.org/show_bug.cgi?id=25663
--- Comment #14 from Ben Matthews <mbe...@gmail.com> 2009-12-16 21:17:50 PST --- I think it's safe to assume that .a is always going to be the library extension. Some background which hopefully helps answer the question better: It's important to note that there is no concept of a shared library on BG/L. BG/L systems are actually a rather complex architecture. There are three major user facing parts of a BG/L system. There's one or more fast IBM P series machines which provide the UI and cross compilers for the main compute system. The compilers generate a static binary image with the user application and a minimal operating system called blrts. The user can then give that binary image to the scheduler which loads it into RAM on each compute node using some largely undocumented magic. The compute nodes then interface with the rest of the world through a smaller number of IO nodes. The IO nodes are minimal Linux systems which run a server called CIOD which takes system calls on from the compute nodes (over one of the internal interconnects) and acts on them (over GigE.. NFS, Sockets, etc). Blrts is intended to look like Linux to the developer but have a lot less jitter. Unfortunately there are a bunch of features that were never implemented (presumably because they'd be hard to fit into this architecture), including shared libraries/dlopen, threads and listen(). If you want to support all Bluegene systems there are a couple places where this can break down. There are two other classes of Bluegene hardware: the /P and the /Q. BG/Q isn't publicly available yet, but BG/P is and may do things differently. I know it supports more of the features that are missing in /L, but I don't know too much more at the moment. I'm in the process of getting an account on a BG/P system to test the code I'm trying to port so if it's of interest to mesa I can probably tell you more in a few days/weeks. The second possible problem is that there's an unofficial alternative to blrts and a corresponding IO node image called ZeptoOS. ZeptoOS runs on both BG/L and BG/P hardware and provides more features than IBM's stack (as well as another toolchain). I'll try building with autoconf tomorrow. Thus far I've been using the old build system because it saves me having to trick autoconf into cross compiling (sometimes that's not too bad and sometimes it's a huge problem depending on what tests it wants to do). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
