- Link with library of exact filename (i.e. exact version) - 8 Updates
- Fixing some undefined behavior - 3 Updates
- who's at fault, me or compiler? - 6 Updates
- Observable end padding in arrays - 7 Updates
- Is this undefined behavior? - 1 Update
| Frederick Gotham <cauldwell.thomas@gmail.com>: Jul 07 02:53AM -0700 Let's say I have a single-source-file program that I want to link with a library called "monkey" that resides in the current directory, and so I compile it like this: g++ -o prog main.cpp -L./ -lmonkey Next let's say that I want to specify the exact filename for the library "monkey" because I want an exact version of it, like so: g++ -o prog main.cpp -L./ -l:libmonkey.so.1.2.0 (This means that I want version 1.2.0 and that I want to link dynamically with an "so" file instead of linking statically with a "a" file) If I compile this program on my Linux computer (x86_64), and then if I run "ldd" on the executable file, I get this: libmonkey.so.1 => /usr/lib/libmonkey.so.1 (0x0000007f7d5e0000) If I check my file system, I see that there are three files beginning with "libmonkey.so", as follows: -rwxr-xr-x 1 root root 30.1K Jul 6 2020 ./libmonkey.so.1.0.3 -rwxr-xr-x 1 root root 34.2K Jul 6 2020 ./libmonkey.so.1.2.0 lrwxrwxrwx 1 root root 15 Feb 11 22:14 ./libmonkey.so.1 -> libmonkey.so.1.2.0 So the are two fully-fledged files: libmonkey.so.1.0.3 libmonkey.so.1.2.0 And then there is a symbolic link called "libmonkey.so.1" which points to the more recent library. The problem here is that I don't want my executable file, "prog", to depend on "libmonkey.so.1". Instead, I want it to depend on "libmonkey.so.1.2.0". For some strange reason, the GNU linker is specifying the dependency as ".1" instead of ".1.2.0". How do I get the linker to keep the full library name? |
| Siri Cruise <chine.bleu@yahoo.com>: Jul 07 05:12AM -0700 In article <f6b620fb-562c-426f-880f-0a12975c0c3co@googlegroups.com>, > g++ -o prog main.cpp -L./ -l:libmonkey.so.1.2.0 >> How do I get the linker to keep the full library name? Doesn't this work? g++ -o prog main.cpp ./libmonkey.so.1.2.0 -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Jul 07 06:04AM -0700 On Tuesday, July 7, 2020 at 1:12:30 PM UTC+1, Siri Cruise wrote: > Doesn't this work? > g++ -o prog main.cpp ./libmonkey.so.1.2.0 I tried that aswell but I got the same result. |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Jul 07 03:56PM +0200 Op 07.jul..2020 om 11:53 schreef Frederick Gotham: > And then there is a symbolic link called "libmonkey.so.1" which points to the more recent library. > The problem here is that I don't want my executable file, "prog", to depend on "libmonkey.so.1". Instead, I want it to depend on "libmonkey.so.1.2.0". For some strange reason, the GNU linker is specifying the dependency as ".1" instead of ".1.2.0". > How do I get the linker to keep the full library name? I do not see a C++ question. Probably a group for your operating Linux system can help you better. -- Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>. |
| gazelle@shell.xmission.com (Kenny McCormack): Jul 07 02:46PM In article <re1uu4$hbt$1@gioia.aioe.org>, Fred. Zwarts <F.Zwarts@KVI.nl> wrote: ... >I do not see a C++ question. Probably a group for your operating Linux >system can help you better. What is an operating Linux system? -- The last time a Republican cared about you, you were a fetus. |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Jul 07 04:52PM +0200 Op 07.jul..2020 om 16:46 schreef Kenny McCormack: >> I do not see a C++ question. Probably a group for your operating Linux >> system can help you better. > What is an operating Linux system? Sorry, the sorting of the words in the sentence used an incorrect algorithm. 😉 -- Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>. |
| Cholo Lennon <chololennon@hotmail.com>: Jul 07 12:08PM -0300 On 7/7/20 6:53 AM, Frederick Gotham wrote: > And then there is a symbolic link called "libmonkey.so.1" which points to the more recent library. > The problem here is that I don't want my executable file, "prog", to depend on "libmonkey.so.1". Instead, I want it to depend on "libmonkey.so.1.2.0". For some strange reason, the GNU linker is specifying the dependency as ".1" instead of ".1.2.0". > How do I get the linker to keep the full library name? Maybe you need to specify the RPATH option (but be aware that it will hardcode the library path inside the executable. The option may not be helpful if you distribute your binaries instead of your source code) https://en.wikipedia.org/wiki/Rpath Regards -- Cholo Lennon Bs.As. ARG |
| Manfred <noname@add.invalid>: Jul 07 07:57PM +0200 On 7/7/2020 11:53 AM, Frederick Gotham wrote: > And then there is a symbolic link called "libmonkey.so.1" which points to the more recent library. > The problem here is that I don't want my executable file, "prog", to depend on "libmonkey.so.1". Instead, I want it to depend on "libmonkey.so.1.2.0". For some strange reason, the GNU linker is specifying the dependency as ".1" instead of ".1.2.0". > How do I get the linker to keep the full library name? As others have said, this is not a C++ question, rather it is a [dynamic] linker question instead, and it is specific to the implementation you use (since you refer to gcc this is most probably the GNU linker). However you may want to check the referenced SONAME in the executable. Usually the GNU linker puts the SONAME of the shared library in the executable, and at runtime the dynamic linker loads the shared library by SO_NAME rather than by filename (see ld -soname). Documentation of the GNU linker: https://sourceware.org/binutils/docs-2.34/ld/ |
| Ian Collins <ian-news@hotmail.com>: Jul 07 05:58PM +1200 On 07/07/2020 10:55, Keith Thompson wrote: >> On Monday, July 6, 2020 at 4:18:14 PM UTC-5, Mr Flibble wrote: >> Don't swear here, please. > Don't feed the trolls, please. Which one? -- Ian. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 06 11:37PM -0700 >>> Don't swear here, please. >> Don't feed the trolls, please. > Which one? Any of them. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 07 06:36PM +0100 On 07/07/2020 07:37, Keith Thompson wrote: >>> Don't feed the trolls, please. >> Which one? > Any of them. There is only one homophobic misogynistic religious bigot in this thread. He is probably a racist Trump supporter too. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Juha Nieminen <nospam@thanks.invalid>: Jul 07 06:23AM > I agree with you that the object does not exist before the binary is > loaded, as before loading it does not have an address in the program > memory space. But his argument is that if the object is in the executable binary file, put into RAM alongside the executable binary itself at load time, then it's not "instantiated". It exists in RAM, with a physical address which you can point to, but it was never "instantiated". |
| boltar@nowhere.co.uk: Jul 07 07:59AM On Mon, 6 Jul 2020 21:30:13 +0000 (UTC) >Or if it's implemented in another manner, it may well create code that >initializes it at runtime (and eg. does memory allocations or whatever). >So, is it instantiated in both cases or not? The person making the assertion is the one who has to prove it, its not up to others to disprove it. Get back to us when you're done. |
| boltar@nowhere.co.uk: Jul 07 08:01AM On Tue, 7 Jul 2020 01:20:45 +0300 >MyClass definitely does not exist in the binary. Classes are >compile-time concept and are not present in the generated binary, in >C++. There is no data structure in the generated binary representing the The class memory layout has to be stored in some form somewhere in the binary otherwise on the fly objects could never be created. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 07 01:27AM -0700 > put into RAM alongside the executable binary itself at load time, then > it's not "instantiated". It exists in RAM, with a physical address which > you can point to, but it was never "instantiated". Since there's no agreed definition of "instantiated", I expect the argument will never be resolved. (Which is fine with me.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Juha Nieminen <nospam@thanks.invalid>: Jul 07 03:11PM >>So, is it instantiated in both cases or not? > The person making the assertion is the one who has to prove it, its not up > to others to disprove it. Get back to us when you're done. Prove what? I asked a *question*. If the compiler makes the object into what essentially amounts to a literal that exists in the executable binary, is that instantiating the class or not? And yes, the compiler does that with certain classes. It's no different from eg. creating a const array of ints at the global scope. It just sounds to me that you are now trying to dodge the question, not having to answer it. Probably even you don't know why. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 07 03:15PM > The class memory layout has to be stored in some form somewhere in the binary > otherwise on the fly objects could never be created. Not, it doesn't necessarily. If the class consists of eg. just integers and they are all default-initialized or zero-initialized, the compiler could just as well create code that allocates space for that many integers and do effectively a memset() on that memory block to zero it. Any code that accesses the members just use offsets from the beginning of that memory block. The actual layout isn't specifically stored separately anywhere. The only place where the layout has effect is in any code that accesses the members (and there it's in the form of offsets from the beginning of the memory block). There may be numerous functions that access the members in this way, so there isn't one single unified place where this layout is "stored" in the binary. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 06 07:21PM -0700 > I'm still curious *how* it implies it. The "This implies that ..." > wording seems to indicate that it's a consequence of some normative > requirement elsewhere in the standard. [...] The C++ standard uses but does not define the term "array type". The C++ standard includes the C standard as a normative reference (1 p2, "C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:2011 Programming languages - C", and also 2 p1.3). The C standard defines the term "array type" - 6.2.5 p20, first subitem: "An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type" (and "array type" is italicized, indicating a definition). An array type under the C definition has no padding. So unless there is a conflicting statement somewhere in the C++ standard, it seems reasonable to conclude arrays in C++ cannot have padding. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 07 05:14AM +0200 On 07.07.2020 04:21, Tim Rentsch wrote: > called the element type" (and "array type" is italicized, > indicating a definition). > An array type under the C definition has no padding. That's not implied by your quote. Which C standard is the quote from, anyway? > So unless there is a conflicting statement somewhere in the C++ > standard, it seems reasonable to conclude arrays in C++ cannot > have padding. Yes, but first one has to prove the C case. - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Jul 07 06:24AM >> guaranteed to be exactly 500 bytes in size? > No, because S itself is not guaranteed to be exactly 5 bytes. > However, table is guaranteed to be 100 * sizeof(S) That's why std::array<std::array<T, X>, Y> is not guaranteed to be contiguous, which makes it different from a two-dimensional array. Ie. the answer to your question. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 07 06:26AM > contiguous array with linear indexing, allocate a single continuous > array; if you want multidimensional indexing, allocate a nested > multidimensional array. It's as simple as that. Hence why we need a multidimensional version of std::array, because std::array<std::array<T, X>, Y> is not guaranteed to be contiguous. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 06 11:37PM -0700 >> wording seems to indicate that it's a consequence of some normative >> requirement elsewhere in the standard. [...] > The C++ standard uses but does not define the term "array type". The C++ standard doesn't define that particular phrase, but it discusses array types in 6.9.2 [basic.compound] and 11.3.4 [dcl.array] (references are to C++17). > nonempty set of objects with a particular member object type, > called the element type" (and "array type" is italicized, > indicating a definition). C++17 11.3.4: "An object of array type contains a contiguously allocated non-empty set of N subobjects of type T." > So unless there is a conflicting statement somewhere in the C++ > standard, it seems reasonable to conclude arrays in C++ cannot > have padding. The C++ standard includes (most of) the C library by reference, but as I understand it it provides its own descriptions of everything in the core language. I'm not aware of anything in the C++ core language that's defined by the C standard. At the very least, *most* of the C++ core language is defined directly by the C++ standard. If there are omissions, my first assumption would be that they're unintentional, not that the C core language definition fills in the gaps. It's not 100% clear to me that either the C or C++ discussion of array types completely excludes the possibility of padding at the end. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 07 09:57AM -0400 On 7/6/20 11:14 PM, Alf P. Steinbach wrote: > On 07.07.2020 04:21, Tim Rentsch wrote: ... >> The C++ standard includes the C standard as a normative reference >> (1 p2, "C++ is a general purpose programming language based on >> the C programming language as described in ISO/IEC 9899:2011 ^^^^ >> indicating a definition). >> An array type under the C definition has no padding. > That's not implied by your quote. If an array type in C were allowed to include padding, then the above quote would have to mention the padding as part of what an array type describes. > Which C standard is the quote from, anyway? He explicitly specified that he was quoting from ISO/IEC 9899:2011. All versions of the C standard have said essentially the same thing about that matter. |
| Manfred <noname@add.invalid>: Jul 07 04:30PM +0200 On 7/7/2020 3:57 PM, James Kuyper wrote: > If an array type in C were allowed to include padding, then the above > quote would have to mention the padding as part of what an array type > describes. Not really, for example the following definition about structure type does not mention padding either, but we know that padding may very well exist there. The difference between array and structure is that the former uses the term "contiguously", and the latter uses "sequentially". This makes clear that no padding is allowed /between/ elements of an array, but to me it does not explicitly state that no extra allocated space is allowed at the /end/ of the array, although this may well follow from some other statement in the C standard. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 07 05:26AM -0700 > I wonder why the standard managed to come up with something that > denies /any/ object allocation with malloc (at least according to the > first example in the proposal). Having now reviewed the linked document, I will offer a few remarks and opinions. First I think the given motivating example (with malloc()) is wrong. Per basic.life (6.8 p1) the lifetime of an object has started. Per c.malloc (23.10.11 p1,p2) the semantics of a call to malloc() is specified by the C standard library. Per the description of "Memory management functions" (7.22.3) in the referenced C standard (which is C 2011), a (non-null) pointer returned by malloc() or calloc() or realloc() "may be assigned to a pointer to any type of object [not having an extended alignment requirement] and then used to access such an object or an array of such objects in the space allocated". That last part seems pretty airtight. Whatever we might imagine is implied by other parts of the C++ standard, given an explicit and specific statement that such pointers may be used to access objects or arrays of objects, it seem reasonable to conclude that those pointers are indeed so usable. Indexing operations and pointer arithmetic is part and parcel of that, those being necessary to carry out the accessing of array elements (which doesn't matter to the paper's example but seems worth pointing out). Second, notwithstanding the first comment, the proposal takes what I think is a good direction in suggesting that (for most of it) the topic be treated as a Defect Report, not changing the meaning of the language but only correcting an oversight in previous writings. So for what we thought was working all along it is admitted that indeed it was meant to work all along, and what is changing is only how the Standard is worded, not the C++ language. Third, forgive me for saying this so bluntly, but the writing in the C++ standard is pretty awful, and unfortunately the paper's proposed changes don't show any signs that that is improving. Fourth, and probably most important, regarding TBAA. I see the motivation for doing TBAA, and in fact I agree with it, but I think the general approach C++ is taking to accommodate TBAA is misguided. Little by little, C++ is building up an elaborate and complicated set of rules, with an unfortunate consequence: If your program does almost anything at all outside of vanilla language usage, and the optimizer f**** you, then it's your fault; or, instead it might be that The compiler/optimizer screwed up, either in understanding or in implementing the rules (but unfortunately it is very hard to be sure, and even harder to convince the compiler writers of the truth in many cases). I'm sorry to say that the "implicit lifetime" proposal continues this trend. (Editorial comment: does anyone else find it funny that the set of changes proposed gives so many explicit statements about so-called "implicit" properties? After all that it hardly seems right to call them "implicit".) |
| 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