فرمت اجرایی و مرتبط
در رایانش، فرمت اجرایی و مرتبط (ELF، که قبلاً به نام Extensible Linking Format نامیده میشد) یک استاندارد فرمت فایل برای فایلهای اجرایی، کد هدف (object code)، کتابخانههای اشتراکی و تخلیهٔ هسته (core dump) است. اولین بار با ویژگیهایی برای رابط دودویی نرمافزار (ABI) سیستم عامل یونیکس نسخه یSystem V Release 4 (SVR4) منتشر شد، و بعد تر در استاندارد رابط ابزار که به سرعت مورد قبول فروشندگان مختلف سیستم های یونیکس قرار گرفت. در سال ۱۹۹۹، به عنوان فرمت استاندارد فایل باینری برای سیستمهای یونیکس و شبه یونیکس بر روی پردازندههای x86 توسط پروژه 86open انتخاب شد.
پسوند(های) نام پرونده | none, .axf, .bin, .elf, .o, .prx, .puff, .ko, .mod and .so |
---|---|
عدد جادویی | 0x7F 'E' 'L' 'F' |
توسعهدهنده | Unix System Laboratories |
گونه | Binary, executable, object, shared library, core dump |
دربرگیرنده | Many executable binary formats |
از نظر طراحی، فرمت ELF انعطافپذیر، قابل گسترش و مستقل از سکو است. به عنوان مثال endiannessهای مختلف و اندازههای آدرس را پشتیبانی میکند، بنابراین هیچ پردازنده مرکزی (CPU) خاص یا معماری مجموعه دستورالعمل را حذف نمیکند. این عامل باعث شدهاست که توسط بسیاری از سیستم عاملها در بسیاری از سکوهای سختافزاری مورد استفاده واقع شود.
طرح فایل
هر فایل ELF از یک سرصفحه ELF (هدر ELF) ساخته شدهاست و به دنبال آن دادههای فایل آمدهاست. دادهها میتوانند شامل موارد زیر باشند:
- جدول هدر برنامه، که صفر یا چند بخش حافظه (memory segments) را توصیف میکند.
- جدول هدر بخش، که صفر یا چند بخش (section) را توصیف میکند.
- دادههایی که توسط محتویات جدول هدر برنامه یا جدول هدر بخش به آنها اشاره شدهاست.
بخشها (segments)حاوی اطلاعاتی هستند که برای زمان اجرای فایل مورد نیاز است، در حالی که بخشها (sections) حاوی اطلاعات مهم برای اتصال(linking) و جابجایی هستند. هر بایت در کل فایل میتواند حداکثر متعلق به یک قسمت (section) باشد و اصطلاحاً بایتهای یتیم زمانی به وجود میآیند که بایتی متعلق به هیچ بخش نباشد.
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 3e 00 01 00 00 00 c5 48 40 00 00 00 00 00 |..>......H@.....|
Example hexdump of ELF file header
هدر فایل
هدر ELF تعریف میکند که از آدرسهای ۳۲ بیتی استفاده شدهاست یا ۶۴ بیتی. هدر حاوی سه فیلد است که از ۳۲ بیتی یا ۶۴ بیتی بودن تأثیر میپذیرند و شروع فیلدهای دیگری را که آنها را دنبال میکنند، تعیین میکنند. هدر ELF به ترتیب برای ۳۲ بیت و ۶۴ بیت، ۵۲ یا ۶۴ بایت طول دارد.
Offset | Size (bytes) | Field | Purpose | ||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32-bit | 64-bit | 32-bit | 64-bit | ||||||||||||||||||||||||||||||||||||||
0x00 | ۴ | e_ident[EI_MAG0] through e_ident[EI_MAG3] | 0x7F followed by ELF (45 4c 46 ) in ASCII; these four bytes constitute the magic number.
| ||||||||||||||||||||||||||||||||||||||
0x04 | ۱ | e_ident[EI_CLASS] | This byte is set to either 1 or 2 to signify 32- or 64-bit format, respectively.
| ||||||||||||||||||||||||||||||||||||||
0x05 | ۱ | e_ident[EI_DATA] | This byte is set to either 1 or 2 to signify little or big endianness, respectively. This affects interpretation of multi-byte fields starting with offset 0x10 .
| ||||||||||||||||||||||||||||||||||||||
0x06 | ۱ | e_ident[EI_VERSION] | Set to 1 for the original version of ELF.
| ||||||||||||||||||||||||||||||||||||||
0x07 | ۱ | e_ident[EI_OSABI] | Identifies the target operating system ABI.
It is often set to | ||||||||||||||||||||||||||||||||||||||
0x08 | ۱ | e_ident[EI_ABIVERSION] | Further specifies the ABI version. Its interpretation depends on the target ABI. Linux kernel (after at least 2.6) has no definition of it. In that case, offset and size of EI_PAD are 8 .
| ||||||||||||||||||||||||||||||||||||||
0x09 | ۷ | e_ident[EI_PAD] | currently unused | ||||||||||||||||||||||||||||||||||||||
0x10 | ۲ | e_type | Identifies object file type.
| ||||||||||||||||||||||||||||||||||||||
0x12 | ۲ | e_machine | Specifies target instruction set architecture. Some examples are:
| ||||||||||||||||||||||||||||||||||||||
0x14 | ۴ | e_version | Set to 1 for the original version of ELF.
| ||||||||||||||||||||||||||||||||||||||
0x18 | ۴ | ۸ | e_entry | This is the memory address of the entry point from where the process starts executing. This field is either 32 or 64 bits long depending on the format defined earlier. | |||||||||||||||||||||||||||||||||||||
0x1C | 0x20 | ۴ | ۸ | e_phoff | Points to the start of the program header table. It usually follows the file header immediately, making the offset 0x34 or 0x40 for 32- and 64-bit ELF executables, respectively.
| ||||||||||||||||||||||||||||||||||||
0x20 | 0x28 | ۴ | ۸ | e_shoff | Points to the start of the section header table. | ||||||||||||||||||||||||||||||||||||
0x24 | 0x30 | ۴ | e_flags | Interpretation of this field depends on the target architecture. | |||||||||||||||||||||||||||||||||||||
0x28 | 0x34 | ۲ | e_ehsize | Contains the size of this header, normally 64 Bytes for 64-bit and 52 Bytes for 32-bit format. | |||||||||||||||||||||||||||||||||||||
0x2A | 0x36 | ۲ | e_phentsize | Contains the size of a program header table entry. | |||||||||||||||||||||||||||||||||||||
0x2C | 0x38 | ۲ | e_phnum | Contains the number of entries in the program header table. | |||||||||||||||||||||||||||||||||||||
0x2E | 0x3A | ۲ | e_shentsize | Contains the size of a section header table entry. | |||||||||||||||||||||||||||||||||||||
0x30 | 0x3C | ۲ | e_shnum | Contains the number of entries in the section header table. | |||||||||||||||||||||||||||||||||||||
0x32 | 0x3E | ۲ | e_shstrndx | Contains index of the section header table entry that contains the section names. |
هدر برنامه
جدول هدر برنامه به سیستم میگوید چگونه یک تصویر پردازش ایجاد کند.
هدر برنامه در محل نشانگر فایل e_phoff یافت میشود و شامل ورودیهای e_phnum است که هر کدام با اندازه e_phentsize هستند. طرح بندی در ELF ۳۲ بیتی نسبت به ELF 64 بیتی کمی متفاوت است، زیرا p_flags به دلیل ایجاد هماهنگی در مکان ساختاری متفاوت قرار دارند. هر ورودی به صورت زیر تشکیل شدهاست:
Offset | Size (bytes) | Field | Purpose | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32-bit | 64-bit | 32-bit | 64-bit | |||||||||||||||||||||||||||||||||||
0x00 | ۴ | p_type | Identifies the type of the segment.
PT_LOOS to PT_HIOS (PT_LOPROC to PT_HIPROC) is an inclusive reserved ranges for operating system (processor) specific semantics. | |||||||||||||||||||||||||||||||||||
0x04 | ۴ | p_flags | Segment-dependent flags (position for 64-bit structure). | |||||||||||||||||||||||||||||||||||
0x04 | 0x08 | ۴ | ۸ | p_offset | Offset of the segment in the file image. | |||||||||||||||||||||||||||||||||
0x08 | 0x10 | ۴ | ۸ | p_vaddr | Virtual address of the segment in memory. | |||||||||||||||||||||||||||||||||
0x0C | 0x18 | ۴ | ۸ | p_paddr | On systems where physical address is relevant, reserved for segment's physical address. | |||||||||||||||||||||||||||||||||
0x10 | 0x20 | ۴ | ۸ | p_filesz | Size in bytes of the segment in the file image. May be 0. | |||||||||||||||||||||||||||||||||
0x14 | 0x28 | ۴ | ۸ | p_memsz | Size in bytes of the segment in memory. May be 0. | |||||||||||||||||||||||||||||||||
0x18 | ۴ | p_flags | Segment-dependent flags (position for 32-bit structure). | |||||||||||||||||||||||||||||||||||
0x1C | 0x30 | ۴ | ۸ | p_align | 0 and 1 specify no alignment. Otherwise should be a positive, integral power of 2, with p_vaddr equating p_offset modulus p_align.
| |||||||||||||||||||||||||||||||||
0x20 | 0x38 | End of Program Header (size) |
سربرگ بخش
Offset | Size (bytes) | Field | Purpose | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32-bit | 64-bit | 32-bit | 64-bit | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x00 | ۴ | sh_name | An offset to a string in the .shstrtab section that represents the name of this section | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x04 | ۴ | sh_type | Identifies the type of this header.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x08 | ۴ | ۸ | sh_flags | Identifies the attributes of the section.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0C | 0x10 | ۴ | ۸ | sh_addr | Virtual address of the section in memory, for sections that are loaded. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x10 | 0x18 | ۴ | ۸ | sh_offset | Offset of the section in the file image. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x14 | 0x20 | ۴ | ۸ | sh_size | Size in bytes of the section in the file image. May be 0. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x18 | 0x28 | ۴ | sh_link | Contains the section index of an associated section. This field is used for several purposes, depending on the type of section. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x1C | 0x2C | ۴ | sh_info | Contains extra information about the section. This field is used for several purposes, depending on the type of section. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x20 | 0x30 | ۴ | ۸ | sh_addralign | Contains the required alignment of the section. This field must be a power of two. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x24 | 0x38 | ۴ | ۸ | sh_entsize | Contains the size, in bytes, of each entry, for sections that contain fixed-size entries. Otherwise, this field contains zero. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x28 | 0x40 | End of Section Header (size) |
ابزارها
readelf
یک ابزار باینری یونیکس است که اطلاعات مربوط به یک یا چند فایل ELF را نمایش میدهد. پیادهسازی نرمافزار رایگان توسط GNU Binutils ارائه شدهاست.elfutils
ابزارهای جایگزین را برای GNU Binutils صرفاً برای لینوکس فراهم میکند.elfdump
یک فرمان برای مشاهده اطلاعات ELF در یک فایل ELF است که تحت Solaris و FreeBSD موجود است.objdump
طیف گستردهای از اطلاعات مربوط به فایلهای ELF و سایر فرمتهای شی را فراهم میکند.objdump
از کتابخانه توصیفگر فایل باینری به عنوان پایه برای ساخت دادههای ELF استفاده میکند.- ابزار
file
یونیکس میتواند برخی از اطلاعات مربوط به فایلهای ELF را نمایش دهد، از جمله معماری تنظیم دستورالعمل که کد آن در یک فایل قابل جابجایی، اجرایی یا شی مشترک، مورد نظر قرار میگیرد یا در آن یک تخلیه هسته ای ال اف (ELF core dump) تولید شدهاست.
برنامههای کاربردی
سیستمهای شبه یونیکس
فرمت ELF جایگزین فرمتهای اجرایی قدیمی در محیطهای مختلف شدهاست. این فرمت، فرمتهای a.out و COFF را در سیستم عاملهای شبه یونیکس جایگزین کردهاست:
- لینوکس
- solaris/ Illumos
- IRIX
- FreeBSD
- NetBSD
- OpenBSD
- Redox
- DragonFly BSD
- Syllable
- HP-UX (به جز برنامههای ۳۲ بیتی PA-RISC که همچنان از SOM استفاده میکنند)
- QNX Neutrino
- MINIX
تصویب غیریونیکس
ELF همچنین مورد تصویب برخی از سیستمهای عامل غیر یونیکس بودهاست، مانند:
- OpenVMS, در ورژنهای Itanium و x86-64
- BeOS Revision 4 وبعدتر برای کامپیوترهایی که پایهٔ آنها x86 است. (که فرمت Portable Executable را جایگزین کرد؛ ورژن PowerPC همچنان با فرمت Preferred Executable Format باقی ماند)
- Haiku, یک پیادهسازی مجدد متن باز برای BeOS
- RISC OS
- Stratus VOS, در ورژنهای PA-RISC و x86
- Windows 10 Anniversary Update با استفاده از Windows Subsystem for Linux.
- SkyOS
- Fuchsia OS
- Z/TPF
- HPE NonStop OS
کنسولهای بازی
همچنین برخی از کنسولهای بازی از ELF استفاده میکنند:
PowerPC
سایر سیستم عاملهای فعال در PowerPC که از ELF استفاده میکنند:
- AmigaOS 4، ای ال اف اجرایی (ELF executableج ایگزین Format Extended Hunk Format (EHF) شدهاست که در Amigas که مجهز به کارتهای توسعه PPC است، استفاده شدهاست.
- MorphOS
- AROS
تلفنهای همراه
برخی از سیستم عاملهای تلفن همراه و دستگاههای تلفن همراه از ELF استفاده میکنند:
- Symbian OS v9 از فرمت E32Image کند که بر اساس فرمت فایل ELF است؛
- برای مثال سونی اریکسون، W800i، W610، W300 و غیره
- سیستمهای زیمنس، سکوهای SGOLD و SGOLD2: از زیمنس C65 تا S75 و BenQ-Siemens E71 / EL71؛
- موتورولا، به عنوان مثال، E398، SLVR L7، v360، v3i (و تمام گوشی LTE2 که دارای پچ است).
- برای مثال بادا، سامسونگ Wave S8500
- تلفنهای نوکیا یا تبلتهای نوکیا که Maemo یا Meego OS را اجرا میکنند، به عنوان مثال Nokia N900.
- اندروید از کتابخانههای (ELF .so (shared object برای رابط بومی جاوا استفاده میکند. با استفاده از Android Runtime (ART)، بهطور پیش فرض از Android 5.0 "Lollipop"، تمام برنامههای کاربردی در هنگام نصب به صورت ELFهای بومی باینری کامپایل میشوند.
برخی از تلفنها میتوانند فایلهای ELF را از طریق استفاده از یک پچ که کد مونتاژ را به سیستم عامل اصلی اضافه میکند، اجرا کنند که این ویژگی با عنوان ELFPack در فرهنگ مودینگ زیرزمینی، شناخته شدهاست. فرمت فایل ELF همچنین با Atmel AVR (8 بیتی)، AVR32 و با معماری میکروکنترلر Texas Instruments MSP430 مورد استفاده قرار میگیرد. برخی از پیادهسازیهای Firmware Open همچنین میتوانند فایلهای ELF را بارگذاری کنند، به ویژه پیادهسازیهای اپل که در تقریباً تمامی دستگاههای PowerPC که توسط خود شرکت تولید شدهاند، مورد استفاده قرار میگیرند.
مشخصات فنی
- Generic:
- System V Application Binary Interface Edition 4.1 (1997-03-18)
- System V ABI Update (اکتبر ۲۰۰۹)
- AMD64:
- ARM:
- IA-32:
- IA-64:
- Itanium Software Conventions and Runtime Guide (سپتامبر ۲۰۰۰)
- M32R:
- M32R ELF ABI Supplement Version 1.2 (2004-08-26)
- MIPS:
- Motorola 6800:
- PA-RISC:
- ELF Supplement for PA-RISC Version 1.43 (۶ اکتبر ۱۹۹۷)
- PowerPC:
- System V ABI, PPC Supplement
- PowerPC Embedded Application Binary Interface 32-Bit Implementation (1995-10-01)
- 64-bit PowerPC ELF Application Binary Interface Supplement Version 1.9 (2004)
- SPARC:
- S/390:
- zSeries:
- Symbian OS 9:
پایگاه استاندارد لینوکس (LSB) بعضی از ویژگیهای فوق را برای معماریهایی که مشخص شدهاند، میافزاید. به عنوان مثال، برای System V ABI، مکمل AMD64 وجود دارد.
86open
86open یک پروژه برای شکلگیری توافق عمومی بر روی یک فرمت فایل باینری رایج برای سیستم عاملهای یونیکس و شبه یونیکس روی کامپیوترهای رایج سازگار با معماری x86 بود تا توسعه دهندگان نرمافزار تشویق شوند که به این معماری روی بیاورند. ایده اولیه این بود که بر روی یک زیر مجموعه کوچک از Spec 1170، یک پیشین برای مشخصات یونیکس تک و کتابخانه GNU C (glibc) استانداردسازی شود تا باینریهای غیر اصلاح شده بتوانند در سیستم عاملهای یونیکس x86 اجرا شوند. این پروژه در ابتدا "Spec 150" نامگذاری شد.
فرمتی که در نهایت انتخاب شد، ELF بود، به ویژه ELF پیادهسازی شده برای لینوکس که پس از آن تبدیل شده بود به استاندارد de facto که توسط همه فروشندگان و سیستم عاملهای مرتبط پشتیبانی میشد.
این گروه در سال ۱۹۹۷ بحثهای ایمیلی را آغاز کرد و برای اولین بار در ۲۲ اوت ۱۹۹۷ با یکدیگر در دفتر Santa Cruz Operation ملاقات کرد.
کمیته فرماندهی مارک ایوینگ، دیون جانسون، ایوان لیبوویچ، بروس پرونس، اندرو روچ، برین اسپارکس و لینوس توروالدز بودند. دیگر افراد در این پروژه عبارت اند از: کیت بستیک، چاک کرانور، مایکل دیویدسون، کریس جی. دمتریو، اولریش دپپر، دون دوگگر، استیو گینزبورگ، جان دانیل هال، رون هولت، اردن هابارد، دیو جانسن، کین جانستون، اندرو جوزی، رابرت لیپ، بلا لوبکین، تیم مارسلند، گرگ پیج، رونالدو جو رکورد، تیم راکله، جوئل سیلور اشتاین، چیا پی تیین و اریک تران.
سیستمهای عامل و شرکتهای موجود عبارت بودند از BeOS، BSDI، FreeBSD، اینتل، لینوکس، NetBSD , SCO و SunSoft, Inc..
این پروژه پیشرفت کرد و در اواسط سال ۱۹۹۸، SCO شروع به توسعه lxrun کرد که یک لایه سازگاری با منبع باز بود که قادر به اجرای باینریهای لینوکس در OpenServer , UnixWare و Solaris بود. SCO حمایت رسمی خود را از lxrun در LinuxWorld در ماه مارس ۱۹۹۹ اعلام کرد. Sun Microsystems در اوایل سال ۱۹۹۹ بهطور رسمی از lxrun برای سولاریس پشتیبانی کرد و بعد به پشتیبانی یکپارچه از فرمت دودویی لینوکس از طریق Solaris Containers for Linux Applications پرداخت.
با استفاده از BSDهایی که به مدت طولانی لینوکس را پشتیبانی میکنند (از طریق یک لایه سازگاری) و فروشندگان اصلی x86 Unix با پشتیبانی از فرمت اضافه شدهاست، این پروژه تصمیم گرفت که ELF لینوکس فرمت انتخاب شده توسط صنعت باشد و «اعلام کند که خودش حل شده» در ۲۵ ژوئیه ۱۹۹۹.
FatELF: باینریهای جهانی برای لینوکس
FatELF یک فرمت دودویی گسترش یافتهٔ ELF است که قابلیتهای باینری fat را اضافه میکند. ّFatELF برای لینوکس و سایر سیستم عاملهای مشابه یونیکس بشمار میرود. علاوه بر انتزاع معماری پردازنده (ترتیب بایت، اندازهٔ word، دستورالعمل CPU و غیره)، در software-platform abstraction مزیت بالقوه ای وجد دارد مانند باینریهایی که از نسخههای متعددی از کرنل ABI پشتیبانی میکنند. تا سال ۲۰۱۴، پشتیبانی از FatELF در خط اصلی کرنل لینوکس یکپارچه نیست.
جستارهای وابسته
- رابط باینری برنامه
- مقایسه فرمتهای فایل اجرایی
- DWARF - یک فرمت برای اشکال زدایی دادهها
- استاندارد سازگاری باینری اینتل
- اجرایی قابل حمل - فرمت مورد استفاده توسط ویندوز
- virtual DSO - vDSO
منابع
- ↑ Tool Interface Standard (TIS) Executable and Linking Format (ELF) Specification Version 1.2 (May 1995)
- ↑ نرمافزار V System Application Variant Edition 4.1 (18-03-1993)
- ↑ "Available lexers — Pygments". pygments.org.
- ↑ "ELF Header". Sco.com. July 2000. Retrieved 2014-02-07.
- ↑ "LXR linux/include/linux/elf.h". linux.no. Retrieved 27 April 2015.
- ↑ "MinixReleases – Minix Wiki". Wiki.minix3.org. Archived from the original on 2013-01-18. Retrieved 2014-01-19.
- ↑ استفاده از PlayStation Portable ELF رمزگذاری شده و انتقال یافتهاست: PSP
- ↑ Record, Ronald (1998-05-21). "Bulletin on status of 86open at SCO". Archived from the original on 2008-12-08. Retrieved 2008-05-06.
خواندن بیشتر
- Levine, John R. (October 1999). Linkers and Loaders. Morgan Kaufmann. ISBN 1-55860-496-0.
- Drepper, Ulrich (2006-08-20). "How To Write Shared Libraries" (PDF). 4.0. Retrieved 2007-06-20.
- An unsung hero: The hardworking ELF by Peter Seebach, December 20, 2005, archived from the original on February 24, 2007
- LibElf and GElf - A Library to Manipulate ELf Files توسط Wayback Machine (بایگانیشده فوریه ۲۵, ۲۰۰۴)
- The ELF Object File Format by Dissection by Eric Youngdale (1995-05-01)
- A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux by Brian Raiter
- ELF relocation into non-relocatable objects by Julien Vanegue (2003-08-13)
- Embedded ELF debugging without ptrace by the ELFsh team (2005-08-01)
- Study of ELF loading and relocs by Pat Beirne (1999-08-03)
پیوند به بیرون
- FreeBSD Handbook: Binary formats (archived version)
- FreeBSD elf(5) manual page
- NetBSD ELF FAQ
- Linux elf(5) manual page
- Oracle Solaris Linker and Libraries Guide
- The ERESI project : reverse engineering on ELF-based operating systems بایگانیشده در ۱۴ مارس ۲۰۲۱ توسط Wayback Machine
- Linux Today article on 86open ۲۶ ژوئیه ۱۹۹۹
- Announcement of 86open on Debian Announce mailing list October 10, 1997, Bruce Perens
- Declaration of Ulrich Drepper (PDF) in The SCO Group vs IBM, ۱۹ سپتامبر ۲۰۰۶
- 86open and ELF discussion on Groklaw, ۱۳ اوت ۲۰۰۶