- mixing compilers (g++ but Intel others)? - 16 Updates
- cout slower than printf - 7 Updates
- Reading C++ error messages - 2 Updates
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 08:12PM -0400 On 4/25/2016 6:43 PM, Scott Lurndal wrote: >> Yes, but even on unix, object files are not the same as libraries. > You'll have to explain that in further detail. A .a and a .o are > interchangable and almost indistinguishable from the perspective of the linker. The key here is - ALMOST INDISTINGUISHABLE. A .a file is an OS standard format and can be used with many linkers and languages. A .o file is dependent on the compiler, and may or may not be compatible with other compilers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Apr 26 12:37PM +1200 On 04/26/16 12:12, Jerry Stuckle wrote: > A .a file is an OS standard format and can be used with many linkers and > languages. A .o file is dependent on the compiler, and may or may not > be compatible with other compilers. UNIX .a files (and Windows .lib files) are a simple archive of object files. The format of the archive may be standard, but the format of the archived object files is not. A reasonable analogy would be a physical library: the library layout is standard, but English books are still in English and French books are in French. -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 12:17AM -0400 On 4/25/2016 8:37 PM, Ian Collins wrote: > archived object files is not. A reasonable analogy would be a physical > library: the library layout is standard, but English books are still in > English and French books are in French. Ah, but the format of the objects in the library are standard. Otherwise you would not be able to call the system libraries from C, PASCAL, FORTRAN, or any of the other languages. You can make the entry point names and calling conventions non-standard. But if you define the functions with the PASCAL calling convention, they are available in any language and any compiler. You cannot say the same with object files, even with the PASCAL calling convention. There is no standard format, and every compiler is free to define it's own. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Apr 26 05:14PM +1200 On 04/26/16 16:17, Jerry Stuckle wrote: > You cannot say the same with object files, even with the PASCAL calling > convention. There is no standard format, and every compiler is free to > define it's own. What part of "UNIX .a files (and Windows .lib files) are a simple archive of object files" did you miss? There aren't any transformations when an object file is archived, so any incompatibilities in the object files are faithfully preserved. With C++, the usual incompatibility is the name mangling. This isn't an issue with system libraries which are either written in C or have C linkage. -- Ian Collins |
| David Brown <david.brown@hesbynett.no>: Apr 26 08:57AM +0200 On 26/04/16 06:17, Jerry Stuckle wrote: > Ah, but the format of the objects in the library are standard. > Otherwise you would not be able to call the system libraries from C, > PASCAL, FORTRAN, or any of the other languages. Are you sure you are not mixing up /dynamic/ libraries, which follow OS standards so that any program in any language can call their functions at runtime, and /static/ libraries that are simply a way to collect object files to make static linking more efficient? |
| scott@slp53.sl.home (Scott Lurndal): Apr 26 02:11PM >A .a file is an OS standard format and can be used with many linkers and >languages. A .o file is dependent on the compiler, and may or may not >be compatible with other compilers. Actually, the gABI and psABI define the (ELF) object file format for Unix, specifically to enable interoperability between toolsets. The fact that one single compiler may not follow the standard means little. Likewise, the COFF format was defined in a standard (and even sort of adopted by MS) before ELF was developed in the late 80's. |
| scott@slp53.sl.home (Scott Lurndal): Apr 26 02:18PM >Ah, but the format of the objects in the library are standard. >Otherwise you would not be able to call the system libraries from C, >PASCAL, FORTRAN, or any of the other languages. Your understanding of linkage (static or at runtime) on unix systems seems to be somewhat lacking. The only thing in an archive library are regular object files. The linker simply extracts each and attempts to resolve any unresolved symbols from each in turn. A shared object, on the other hand, is a set of object files linked into a new object file - one that includes a global offset table(s) and procedure linkage table(s) designed to enable run-time linkage between an executable and the shared object. In both cases, the object file format is defined by the gABI and psABI for the processor family. >You can make the entry point names and calling conventions non-standard. > But if you define the functions with the PASCAL calling convention, >they are available in any language and any compiler. WTF? >You cannot say the same with object files, even with the PASCAL calling >convention. There is no standard format, and every compiler is free to >define it's own. This is incorrect: https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4) http://www.x86-64.org/documentation/abi.pdf (chapter 4) |
| scott@slp53.sl.home (Scott Lurndal): Apr 26 02:21PM >standards so that any program in any language can call their functions >at runtime, and /static/ libraries that are simply a way to collect >object files to make static linking more efficient? Even if he were, he'd be wrong. The System V Generic ABI and the associated processor supplements (psABIs) document completely both the object file format and the calling sequences for all languages. A shared object is just another object file using the same ELF-based format as any other object file. It simply has additional sections (.dynsym, .got, .plt, et. alia). There are psABI's for 32-bit intel, 64-bit intel (x86_64 and ia64) as well as sparc, powerpc, mips and arm (Aarch32 and Aarch64) and even system/370. |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 10:29AM -0400 On 4/26/2016 1:14 AM, Ian Collins wrote: >> define it's own. > What part of "UNIX .a files (and Windows .lib files) are a simple > archive of object files" did you miss? What part of object file formats being compiler dependent and library file formats being defined by the operating system did you miss? > C++, the usual incompatibility is the name mangling. This isn't an > issue with system libraries which are either written in C or have C > linkage. Maybe not with gcc - but that is NOT the only compiler in the world. But it obviously is the only one you've ever used. You once again show a distinct lack of understanding of anything outside of your limited experience. For instance - the Microsoft compiler object files are not compatible with Watcom object files, and neither were compatible with Borland object files. But libraries created by any of them are compatible with the others. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 10:30AM -0400 On 4/26/2016 2:57 AM, David Brown wrote: > standards so that any program in any language can call their functions > at runtime, and /static/ libraries that are simply a way to collect > object files to make static linking more efficient? No, I am not. The static library format is also defined by OS standards and libraries created to that standard can also be used by different compilers and languages. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 10:33AM -0400 On 4/26/2016 10:21 AM, Scott Lurndal wrote: > There are psABI's for 32-bit intel, 64-bit intel (x86_64 and ia64) > as well as sparc, powerpc, mips and arm (Aarch32 and Aarch64) and > even system/370. Then why aren't Microsoft generated object files compatible with Watcom generated object file, and neither were compatible with Borland generated object files? But all of the libraries were. And why can't you use a Linux object file on a Windows machine, and vice versa? If what you say were true, none of the above would be correct. But it can easily be demonstrated. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 10:39AM -0400 On 4/26/2016 10:18 AM, Scott Lurndal wrote: >> PASCAL, FORTRAN, or any of the other languages. > Your understanding of linkage (static or at runtime) on unix systems > seems to be somewhat lacking. Not at all. I was probably working with them before you were born. > The only thing in an archive library are regular object files. The linker > simply extracts each and attempts to resolve any unresolved symbols > from each in turn. Yes, that is true. The linker then writes the library in an *OS standard* format. But the object file may or may not be compatible with other compilers. gcc is NOT the only compiler in this world! > into a new object file - one that includes a global offset table(s) and > procedure linkage table(s) designed to enable run-time linkage between > an executable and the shared object. Are you talking about a shared object - or a shared library? > In both cases, the object file format is defined by the gABI and psABI > for the processor family. Then why aren't object files compatible across compilers and operating systems? If it were generated with gcc on Linux, I should be able to link it in using a Microsoft compiler on Windows. >> But if you define the functions with the PASCAL calling convention, >> they are available in any language and any compiler. > WTF? That is correct. The PASCAL calling convention is common to all compiled languages, including FORTRAN, COBOL and others. Even C compilers have ways of defining the PASCAL calling convention. OTOH, the C calling convention is only usable by a few languages, the most common being C and C++. That's why system libraries use the PASCAL calling convention - on all OS's. > This is incorrect: > https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4) > http://www.x86-64.org/documentation/abi.pdf (chapter 4) Then please explain why I can't do the above. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 10:40AM -0400 On 4/26/2016 10:11 AM, Scott Lurndal wrote: > Actually, the gABI and psABI define the (ELF) object file format for Unix, specifically to > enable interoperability between toolsets. The fact that one single compiler > may not follow the standard means little. The fact that multiple compilers do not follow this standard means a lot. > Likewise, the COFF format was defined in a standard (and even sort of adopted > by MS) before ELF was developed in the late 80's. So why aren't compilers able to link each others object files? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| scott@slp53.sl.home (Scott Lurndal): Apr 26 04:37PM >> enable interoperability between toolsets. The fact that one single compiler >> may not follow the standard means little. >The fact that multiple compilers do not follow this standard means a lot. Citation required. >> Likewise, the COFF format was defined in a standard (and even sort of adopted >> by MS) before ELF was developed in the late 80's. >So why aren't compilers able to link each others object files? In my experience, they do. |
| scott@slp53.sl.home (Scott Lurndal): Apr 26 04:41PM >Then why aren't object files compatible across compilers and operating >systems? If it were generated with gcc on Linux, I should be able to >link it in using a Microsoft compiler on Windows. Last I checked, Windows isn't Unix. gABI/psABI are Unix. As it happens, the gnu binutils _will_, with effort, handle the Microsoft PECOFF object format (which was the old, inefficient, unix object format until superceded by the superior ELF format). Microsoft has chosen not to support ELF. That's their problem. |
| Gareth Owen <gwowen@gmail.com>: Apr 26 07:43PM +0100 > What part of object file formats being compiler dependent and library > file formats being defined by the operating system did you miss? Well, mostly that part about the fact that *on Unix its not true*. The format of the object files is not modified when stored within the library container format. If a Pascal program can link to foo() in libfoo.a, then it can just as easily link to foo() in foo.o > with Watcom object files, and neither were compatible with Borland > object files. But libraries created by any of them are compatible > with the others. And this refers to Ian's statement - which is clearly, unambiguously and explicitly talking about Unix - how, exactly? |
| Rosario19 <Ros@invalid.invalid>: Apr 26 06:55AM +0200 On Sat, 23 Apr 2016 00:22:09 +0100, Mr Flibble wrote: >to sprintf (or its equivalent) for each number. >Yes code-reuse is good in general but here using the C stdlib in a C++ >LIBRARY implementation resulting in poor performance is just not on. why? if use the same functions that C stdio; the only reason i can think would be the code is not localizated in the same place in memory and there are many calls in different parts of memory [instead of a loop or function calls in some little region of memory] |
| Juha Nieminen <nospam@thanks.invalid>: Apr 26 06:09AM > Also, since the manipulators are expressed in code, you > can't easily put a format mask into configuration storage, which is > something we frequently want to do. Which, incidentally, is one of the major security flaws typical of C which many programmers aren't aware of (unless you go through the trouble of implementing a checking code that meticulously validates the format string before using it). --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: Apr 26 06:11AM > In C++, both to_string and the stream insertion operator<< require custom > implementations for MyClass. I think you know that, so I'm not quite > sure what your point is. I'm talking about the code that uses the stream to output the value. How can that code know if it should just output the value as-is, or whether it should call the .to_string() method of it? Especially if the code is eg. templated. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: Apr 26 06:14AM > Write a virtual print/serialize function in your class. You rarely need > to "just print" it. Maybe even printf("%s", my.repr()) can be an easy > solution. And obviously this solution works fine and dandy if 'my' happens to be a more abstract or generic type (such as a template type)? --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| leigh.v.johnston@googlemail.com: Apr 26 06:22AM -0700 Because printf is doing one thing whilst cout is doing three things multiple times for EACH number: 1. Changing state for each manipulator call 2. Generating a sprintf format string 3. Calling sprintf. |
| woodbrian77@gmail.com: Apr 26 10:51AM -0700 On Friday, April 22, 2016 at 6:22:12 PM UTC-5, Mr Flibble wrote: Leigh, Please don't swear here. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 26 07:41PM +0100 > On Friday, April 22, 2016 at 6:22:12 PM UTC-5, Mr Flibble wrote: > Leigh, Please don't swear here. 'This video may contain sexual swearwords, I'm afraid. There are 28 'fucks'. Including that one 29. Ah, fuck it, make it 30.' -- Paul Calf https://www.youtube.com/watch?v=42UCpOzTbNU /Flibble |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 22 05:33PM +0300 On 22.04.2016 14:57, jacobnavia wrote: > Now, the letter sequence "getloc" does NOT appear in the file > ServerMain.cpp. > How could I figure out what is wrong and where? By googling of course! http://stackoverflow.com/questions/19521398/linker-error-while-building-clang-using-makefile-with-a-checker HTH Paavo |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 22 01:57PM +0200 Undefined reference to: "std::__1::ios_base::getloc() const", referenced from: ServerMain(int, char**, bool) in libdatabaselibrary.a(ServerMain.o) std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequ ence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char > >&, char const*, unsigned long) in libdatabaselibrary.a(ServerMain.o) (etc) Now, the letter sequence "getloc" does NOT appear in the file ServerMain.cpp. How could I figure out what is wrong and where? Thanks in advance for any hints. jacob |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment