From nic.csu.net!usc!howland.reston.ans.net!newsserver.jvnc.net!netnews.upenn.edu!gradient.cis.upenn.edu Mon May 24 14:12:31 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!usc!howland.reston.ans.net!newsserver.jvnc.net!netnews.upenn.edu!gradient.cis.upenn.edu Newsgroups: comp.lang.c,comp.lang.c++ Subject: More about malloc() problems in AIX Message-ID: <127358@netnews.upenn.edu> From: freeman@gradient.cis.upenn.edu (Jon W. Freeman) Date: 19 May 93 18:28:29 GMT Sender: news@netnews.upenn.edu Followup-To: comp.lang.c Organization: University of Pennsylvania Nntp-Posting-Host: gradient.cis.upenn.edu Lines: 61 Xref: filly comp.lang.c:37333 comp.lang.c++:33633 Status: O In , Kevin Hopps (kjhopps@mmm.com) described a serious and more or less unfixable problem with malloc on AIX: I've seen a few postings now related to malloc, realloc, memory limits and why realloc sometimes causes a seg fault. I haven't heard the term "AIX" used yet, but I wonder if this plays in. In the last year I had the unpleasant experience of using AIX to write an application which by its nature used lots of memory. The problem I experienced sounds remarkably like the problems I've been reading about in comp.lang.c -- namely that malloc returns a nonzero pointer but using the memory causes problems. It turns out that when an app calls malloc, AIX doesn't carve out space in the paging area before returning a non-zero pointer. Page space is allocated when the memory is touched, not requested. This means that if there is 100MB if paging space on the machine, many apps could each call malloc with 90MB requests and each would receive a nonzero value. But, when they try to use the memory, problems occur. AIX actually kills them (with SIGKILL). I'm leaving out details, but essentially malloc's return of nonzero is not a guarantee that the memory can be used. I called IBM support to report this behavior which was surely a bug. They said engineering said that it's working just the way they want it to. I asked them how I should write apps which didn't crash and they gave a long and convoluted answer which involved catching a special SIGDANGER signal and wrapping my malloc with a routine which touched all the pages before returning its pointer. I said I can do that, but how do I deal with 3rd party software which just calls plain malloc? I can't rewrite their code. Like what? Oh, how about Xlib? Sorry, they said. I told them that when my customers complain about my app crashing, I'll just tell them IBM says it's working just the way they want it to. I've since made it my personal mission to ensure that the world hears about how AIX has been designed. -- Kevin J. Hopps e-mail: kjhopps@mmm.com 3M Company phone: (612) 737-3300 3M Center, Bldg. 235-3B-16 fax: (612) 737-2700 St. Paul, MN 55144-1000 ** USE kjhopps@mmm.com FOR E-MAIL REPLIES ** Well, I think I've found out _why_ AIX's malloc() behaves this way (I realize that this is no great help, but I thought people might be curious). Apparently it is impossible to do dynamic memory allocation in FORTRAN, so it is common practice for FORTRAN programmers to declare arrays with enormous dimensions at the start of the program, even though the program only uses a small part of these arrays in practice. Furthermore, it seems that these array declarations are actually implemented as calls to malloc(). Under these circumstances, the behavior of AIX's malloc() makes sense. What's puzzling, though, is why the folks at IBM chose to call this function "malloc". This is a completely different memory allocation function, of course, and they should have called it something else, like "aix_malloc" or "aix_fortran_compiler_malloc". Breaking a widely-used library routine for the sake of an inadequate programming language from the 1950's. What a great idea! Jon (freeman@gradient.cis.upenn.edu) From nic.csu.net!csus.edu!decwrl!decwrl!spool.mu.edu!howland.reston.ans.net! Mon May 24 14:14:31 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!spool.mu.edu!howland.reston.ans.net! europa.eng.gtefsd.com!emory!sol.ctr.columbia.edu!caen!malgudi.oar.net! news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Thu, 20 May 1993 16:08:24 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1433@mavrick.UUCP> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 96 Xref: filly comp.unix.aix:23432 comp.unix.programmer:10940 comp.lang.c:37403 Status: O In article , coleman@twinsun.com (Mike Coleman) writes: |> |So what are you saying here? That you would prefer that ld complain? |> |> YES, of course! This program would be considered bogus by any Unix linker |> I've ever used. Well, pardon me, but I think the issue goes beyond what a Un*x linker is capable of. Let's all remember that C is used on other platforms, also. |> If you link these files with b.c before c.c, you'll get one answer when you |> run the program, and if you do it the other way, you'll get another answer. |> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" |> 'ld' would complain loudly. Historically, that's because any allegedly "normal" ld has never had the intelligence or capability to do anything but complain and die. |> ||> The catch is that |> ||> even if a first definition of 's' has already been encountered, if an object |> ||> both references and defines 's', the latter "local" definition will be used. |> |> |Which is as it should be. The scoping rules of the C language dictate which |> |symbol definition is referred to when a file contains both a reference |> |and a definition of a symbol. The question becomes one of: what is a |> |reasonably intelligent action on the part of ld when that situation arises? |> |> The semantics of C given in the ANSI C standard specify that there is never to |> be more than one external definition of a particular function. While it is |> not required by the standard, in my opinion the only "reasonably intelligent" |> action is to emit a fatal error message and stop. Close, but incomplete. There is never to be more than one external definition of a particular symbol _within the same translation unit_. Later in section 3.7 the standard states that there is only a single definition within a program. During the link phase, the object modules do _not_ constitute a program; they act simply is input information for the linker. Your arguments appear (to me; no flame intended) to be combining aspects of compiling and linking. The two are not the same. And using the definition of a single language to determine what the behavior of some other utility should be strikes me as interesting :-) |> I would be interested to hear from all C programmers who feel that multiple, |> conflicting definitions of external C functions should by default not be |> flagged in any way by the compiler or linker. Would these be the same people who utilize multiple definitions of symbols within various shared objects and rely on command line ordering to refer to the desired symbol? So, within shared objects in a link cycle, it's okay to have multiple definitions, but not in explicit object modules? Therefore we _want_ inconsistent behavior in the linker? I don't think so. I myself would be very interested to hear how many non-trivial projects allow the development of code that lends itself to the creation of multiple definitions of symbols. Perhaps I'm being an idealist, but it seems to be that anything larger than 2-3 people should be clearly defining and documenting what names come into being and who writes what subsystem. Call me a dreamer :-) |> |> ||> This means that some references to duplicate symbols are dependent on ld |> ||> argument order, and some are not. |> |> |Some are dependant upon the language being used. |> |> I'm not sure I understand the point, Because scoping rules vary from language to language, and ld _must_ respect the idiosyncracies while trying to make intelligent decisions. |> ||> Because of these problems, it might be better to develop software on a Un*x |> ||> system, and only use AIX to compile it once it's been determined to be |> ||> correct. |> |> |Well, I see we're playing a game of semantics. When it comes down to |> |correctness of code, it's actually smarter to develop on AIX and port to |> |other platforms :-) |> |> Okay, I'll bite. Why would that be? IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly organized code and questionable structure; reliance on undocumented behavior; dependance upon "the way things happen to be", rather than concrete methodologies. Regarding design and implementation, current and emerging standards are attempting to fill these "holes"; and AIX is right up front when it comes to adhering to those standards. The sloppiness exhibited by an awful lot of the code I've seen (on other platforms) isn't (as oftern) allowed in AIX, and from a reliability standpoint, I'll take tight and organized any day. Oh dear, this is a religious discussion now, isn't it? :-) -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________ From nic.csu.net!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Mon May 24 14:14:32 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: coleman@twinsun.com (Mike Coleman) Date: Thu, 20 May 1993 22:49:00 GMT Sender: usenet@twinsun.com References: <1433@mavrick.UUCP> Organization: Twin Sun Inc, El Segundo, CA, USA Nntp-Posting-Host: twin Lines: 125 Xref: filly comp.unix.aix:23465 comp.unix.programmer:10949 comp.lang.c:37439 Status: O hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. I'm not sure what "the issue" is, but clearly a Un*x linker is capable of flagging conflicting external symbol definitions. That nearly all Un*x linkers in existence already do this proves that. I'm aware that C exists on non-Un*x platforms. As far as I am aware, linkers on these platforms also typically flag conflicting symbol definitions, by default. >|> If you link these files with b.c before c.c, you'll get one answer when you >|> run the program, and if you do it the other way, you'll get another answer. >|> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" >|> 'ld' would complain loudly. >Historically, that's because any allegedly "normal" ld has never had the >intelligence or capability to do anything but complain and die. It's not the lack of intelligence or capability, it's the lack of information. When a linker sees multiple conflicting external symbol definitions, it doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. The AIX linker, on the other hand, silently makes a proxy decision about what the programmer might have intended. A flag to disable (or better yet *enable*) this "feature" could easily be added. Until it exists, I think this problem makes AIX unfit for software development in C (at least). >Close, but incomplete. There is never to be more than one external definition of >a particular symbol _within the same translation unit_. Later in section 3.7 >the standard states that there is only a single definition within a program. >During the link phase, the object modules do _not_ constitute a program; they >act simply is input information for the linker. I agree that the ANSI C standard is not specific enough about linking methods to exclude the IBM linking model. >Your arguments appear (to me; no flame intended) to be combining aspects >of compiling and linking. The two are not the same. And using the definition >of a single language to determine what the behavior of some other utility >should be strikes me as interesting :-) Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what anyone who's used existing implementations of 'ld' on various flavors of Un*x would expect. There is no standard for the behavior of 'ld', but common sense suggests that AIX's new 'ld' has the potential to cause much unneeded effort. Also, I suspect that most compiled languages which have a concept of seperate translation units and global objects also have the idea that global objects in different translation units ought to be consistent. >|> I would be interested to hear from all C programmers who feel that multiple, >|> conflicting definitions of external C functions should by default not be >|> flagged in any way by the compiler or linker. >Would these be the same people who utilize multiple definitions of >symbols within various shared objects and rely on command line ordering >to refer to the desired symbol? So, within shared objects in a link cycle, >it's okay to have multiple definitions, but not in explicit object modules? >Therefore we _want_ inconsistent behavior in the linker? I don't think so. I'm not entirely clear on all of the details of shared objects, but my understanding is that they should act the way libraries (lib*.a) work. The semantics is the same. Yes, object files and libraries are treated differently in the traditional behavior. And it is perhaps unfortunate that conflicting definitions in libraries are not flagged. But this does not mean that the extension of this unfortunate behavior by IBM is a good idea. >I myself would be very interested to hear how many non-trivial projects allow >the development of code that lends itself to the creation of multiple definitions >of symbols. Perhaps I'm being an idealist, but it seems to be that anything >larger than 2-3 people should be clearly defining and documenting what names >come into being and who writes what subsystem. Call me a dreamer :-) Yes, you're being an idealist. I'd be willing to bet that a problematic multiple definition was discovered by 'ld' during the development of over 99% of large (>100K SLOC) C programs. A more typical case is dealing with large quantities of poorly-written, undocumented code that the programmer didn't write and isn't familiar with. Under these circumstances, we need *help*, not creative interpretation of incorrect programs. >Because scoping rules vary from language to language, and ld _must_ respect >the idiosyncracies while trying to make intelligent decisions. This may be true, but is the behavior I'm complaining about required to support *any* language? >IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly >organized code and questionable structure; reliance on undocumented behavior; >dependance upon "the way things happen to be", rather than concrete >methodologies. Good point. Are there any systems that do *not* allow these things? >Regarding design and implementation, current and emerging standards >are attempting to fill these "holes"; and AIX is right up front when >it comes to adhering to those standards. Committee standards, perhaps, but not de facto standards in their absence. >The sloppiness exhibited by an awful >lot of the code I've seen (on other platforms) isn't (as oftern) allowed in AIX, >and from a reliability standpoint, I'll take tight and organized any day. In this case, sloppiness is allowed, but AIX silently interprets it as it pleases. Most Un*xes disallow this sloppiness. >Oh dear, this is a religious discussion now, isn't it? :-) Is it? If you spend a day tracking one of these problems down, you might not think so. We need *help*, not design self-righteousness. Mike -- Speaking only for myself, of course. From nic.csu.net!csus.edu!wupost!cs.utexas.edu!hermes.chpc.utexas.edu!pefv700 Mon May 24 14:14:35 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!hermes.chpc.utexas.edu!pefv700 Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <1993May20.233700.2462@chpc.utexas.edu> From: pefv700@chpc.utexas.edu (Christopher Phillips) Date: Thu, 20 May 93 23:37:00 GMT References: Organization: The University of Texas System - CHPC Lines: 36 Xref: filly comp.unix.aix:23463 comp.unix.programmer:10948 comp.lang.c:37438 Status: O In article hook@vnet.ibm.com writes: >In article , coleman@twinsun.com (Mike Coleman) writes: >|> |So what are you saying here? That you would prefer that ld complain? >|> >|> YES, of course! This program would be considered bogus by any Unix linker >|> I've ever used. > >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. > >|> If you link these files with b.c before c.c, you'll get one answer when you >|> run the program, and if you do it the other way, you'll get another answer. >|> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" >|> 'ld' would complain loudly. > >Historically, that's because any allegedly "normal" ld has never had the >intelligence or capability to do anything but complain and die. Well, here's one scenario that happened to me. Say you have a.c, b.c, lib1.a, and lib2.a. Further suppose that lib1.a and lib2.a both share an external function ``func.'' Now AIX31% cc a.o b.o -llib1 -llib2 complains about unresolved externals that are *clearly* in one of the two libraries. Try changing the order of a.o and b.o or -llib1 and -llib2. ld complains again, giving some of the same symbols as before and some new ones. It's one thing to complain. It's another thing to give misleading information. (Of course, if it hadn't complained, bad things -- hopefully -- would have happened at run time.) Chris From nic.csu.net!csus.edu!decwrl!decwrl!sdd.hp.com!elroy.jpl.nasa.gov!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Mon May 24 14:14:36 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!sdd.hp.com!elroy.jpl.nasa.gov!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: coleman@twinsun.com (Mike Coleman) Date: Thu, 20 May 1993 02:04:44 GMT Sender: usenet@twinsun.com References: <1433@mavrick.UUCP> Organization: Twin Sun Inc, El Segundo, CA, USA Nntp-Posting-Host: twin Lines: 94 Xref: filly comp.unix.aix:23405 comp.unix.programmer:10930 comp.lang.c:37355 Status: O hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: ||> It appears that the AIX linker simply *expects* global symbols to be ||> redefined. For example, it doesn't have any trouble linking together the ||> following two files: ||> ||> a.c: int a() { return 2+c(); } int main() { return a(); } ||> b.c: int c() { return 5; } int a() { return 3+c(); } |So what are you saying here? That you would prefer that ld complain? YES, of course! This program would be considered bogus by any Unix linker I've ever used. Here's a slightly more egregious example: a.c: #include int a() { f1(); return 2+c(); } int main() { f1(); printf("RETURN %u\n", a()); } b.c: #include int f1() { printf("b.c: f1\n"); } int c() { f1(); return 5; } int a() { f1(); return 3+c(); } c.c: #include int f1() { printf("c.c: f1\n"); } If you link these files with b.c before c.c, you'll get one answer when you run the program, and if you do it the other way, you'll get another answer. You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" 'ld' would complain loudly. |But (IMHO) I've found that the discarding |of duplicate symbol definitions can be rather convenient. It may be, if you know they're there. I can imagine annoyance or disaster if you don't, which can easily be the case since AIX 'ld' will not tell you. The only reasonable way to get this information under AIX is to use a special, non-standard 'ld' flag to get a log file, and then run that log file through a custom 'sed' (or whatever) script to strip out spurious warnings. This procedure would be complicated, unreliable, prone to break, and generally unknown to new AIX users. ||> The catch is that ||> even if a first definition of 's' has already been encountered, if an object ||> both references and defines 's', the latter "local" definition will be used. |Which is as it should be. The scoping rules of the C language dictate which |symbol definition is referred to when a file contains both a reference |and a definition of a symbol. The question becomes one of: what is a |reasonably intelligent action on the part of ld when that situation arises? The semantics of C given in the ANSI C standard specify that there is never to be more than one external definition of a particular function. While it is not required by the standard, in my opinion the only "reasonably intelligent" action is to emit a fatal error message and stop. I would be interested to hear from all C programmers who feel that multiple, conflicting definitions of external C functions should by default not be flagged in any way by the compiler or linker. ||> This means that some references to duplicate symbols are dependent on ld ||> argument order, and some are not. |Some are dependant upon the language being used. I'm not sure I understand the point, but I don't think this makes me feel any better. ||> but the AIX linker will not complain. |No. It handles the situation in a reasonable manner and provides diagnostics |information for you to peruse at your leisure. That's just the problem. By default, it doesn't produce *any* diagnostics. If you *specifically* ask for them, it will give you a long log. If your program uses Xlib, you'll have to wade through dozens of spurious warnings to try to find one you might be looking for. This is unacceptable. ||> Because of these problems, it might be better to develop software on a Un*x ||> system, and only use AIX to compile it once it's been determined to be ||> correct. |Well, I see we're playing a game of semantics. When it comes down to |correctness of code, it's actually smarter to develop on AIX and port to |other platforms :-) Okay, I'll bite. Why would that be? Mike -- El Segundo, California--Where the jets rumble over the sharks From nic.csu.net!csus.edu!decwrl!decwrl!elroy.jpl.nasa.gov!swrinde!gatech!concert! Mon May 24 14:14:36 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!elroy.jpl.nasa.gov!swrinde!gatech!concert! news-feed-1.peachnet.edu!umn.edu!gaia.ucs.orst.edu!wsrcc.com! hack.dragoman.com!wetware!spunky.RedBrick.COM!psinntp!psinntp!curly.appmag.com!pa Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <1449@curly.appmag.com> From: pa@curly.appmag.com (Pierre Asselin) Date: 21 May 93 01:01:19 GMT Followup-To: comp.unix.aix References: <1433@mavrick.UUCP> Organization: Applied Magnetics, Goleta, CA Lines: 96 Xref: filly comp.unix.aix:23515 comp.unix.programmer:10964 comp.lang.c:37508 Status: O In hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >In article , coleman@twinsun.com (Mike Coleman) writes: >|> |So what are you saying here? That you would prefer that ld complain? >|> >|> YES, of course! This program would be considered bogus by any Unix linker >|> I've ever used. >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. Agreed, but I concur with Mike Coleman. This program would be considered bogus by any linker trying to button up the pieces of a C program. >Close, but incomplete. There is never to be more than one external >definition of a particular symbol _within the same translation unit_. >Later in section 3.7 the standard states that there is only a single >definition within a program. During the link phase, the object modules >do _not_ constitute a program; they act simply is input information for >the linker. I don't think your position is defensible. See section 3.1.2.2, line 10: "In the set of translation units and libraries that constitutes an entire program, each instance of a particular identifier with external linkage denotes the same object or function." I think the object modules are a little more than input to the linker. The corresponding section of the Rationale adds, "...only a single translation unit contains the definition of a given object..." Granted, this last bit is not the standard proper, but it should carry some weight. >Your arguments appear (to me; no flame intended) to be combining aspects >of compiling and linking. The two are not the same. And using the definition >of a single language to determine what the behavior of some other utility >should be strikes me as interesting :-) If I link Mike's example on AIX using `bind', I expect to have to read the fine print in the manual. If I use `ld', I expect familiar behaviour, in this case a link-time error. If I link with `cc' or `xlc', the C standard *demands* a link-time error. Whether cc and ld are implemented on top of bind is irrelevant. Cc and ld ought to work like they used to. I know AIX is not Unix, but I still hate it when the utilities remind me. >Would these be the same people who utilize multiple definitions of >symbols within various shared objects and rely on command line ordering >to refer to the desired symbol? So, within shared objects in a link cycle, >it's okay to have multiple definitions, but not in explicit object modules? >Therefore we _want_ inconsistent behavior in the linker? I don't think so. I think I understand what you are saying, but I'm not sure. My mental model of the linker is one where all object files are unconditionally combined; libraries are searched when there are unsatisfied external references; object files are pulled from the libraries as necessary to satisfy the references, at the risk of introducing more unsatisfied references and triggering more library searches. That's what I know. I find it useful to be able to type $ cc -o testprog myprog.o tidbit.o mylib.a when I want to test an experimental version of the object `tidbit.o' in the library `mylib.a'. Many implementations of shared libraries do not allow it, for example because other objects in mylib.a are pre-linked to the tidbit.o of the library. I consider this a design flaw. >I myself would be very interested to hear how many non-trivial projects >allow the development of code that lends itself to the creation of >multiple definitions of symbols. None, I hope. Conflicting definitions of the same external symbol are errors. Blow up loud! >IMHO (from what I've seen) Un*x systems tend to allow development of >haphazardly organized code [...] >The sloppiness exhibited by an awful lot of the code >I've seen (on other platforms) isn't (as oftern) allowed in AIX, and >from a reliability standpoint, I'll take tight and organized any day. I wouldn't present AIX as a shining example. I *do* see IBM trying to tidy up their flavour of Unix but I think reinventing the wheel got in their way. I am typing this on a 520 running the now unsupported AIX 3.1.6. Why aren't we upgrading? because none of our 3.2.x machines work right, even after installing PTFs by the hectomeg. My machine is our email and news link to the world and we can't afford to lose it. Thank god I am no longer the sysadmin. -- --Pierre Asselin, Magnetoresistive Head Engineering, Applied Magnetics. pa@appmag.com the usual disclaimers apply. From nic.csu.net!csus.edu!wupost!emory!europa.eng.gtefsd.com!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Mon May 24 14:14:37 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!emory!europa.eng.gtefsd.com!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Fri, 21 May 1993 22:10:31 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1433@mavrick.UUCP> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 161 Xref: filly comp.unix.aix:23523 comp.unix.programmer:10968 comp.lang.c:37511 Status: O In article , coleman@twinsun.com (Mike Coleman) writes: |> hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: |> >Historically, that's because any allegedly "normal" ld has never had the |> >intelligence or capability to do anything but complain and die. |> |> It's not the lack of intelligence or capability, it's the lack of information. |> When a linker sees multiple conflicting external symbol definitions, it |> doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. Well, I disagree. And given that many programmers historically have used command line ordering to perform symbol resolution precedence operations (re: shared objects below), I'll have to disagree that ld _should_ die. |> The AIX linker, on the other hand, silently makes a proxy decision about what |> the programmer might have intended. |> |> A flag to disable (or better yet *enable*) this "feature" could easily be |> added. Until it exists, I think this problem makes AIX unfit for software |> development in C (at least). ANd the fundamental capability of the system with respect to shared objects has already provided your other annoyance: extraneious complaints from the X libraries. The floag _does_ exist, you simply appear to be unsatisfied with that as well. |> |> >Close, but incomplete. There is never to be more than one external definition of |> >a particular symbol _within the same translation unit_. Later in section 3.7 |> >the standard states that there is only a single definition within a program. |> >During the link phase, the object modules do _not_ constitute a program; they |> >act simply is input information for the linker. |> |> I agree that the ANSI C standard is not specific enough about linking methods |> to exclude the IBM linking model. |> |> >Your arguments appear (to me; no flame intended) to be combining aspects |> >of compiling and linking. The two are not the same. And using the definition |> >of a single language to determine what the behavior of some other utility |> >should be strikes me as interesting :-) |> |> Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what |> anyone who's used existing implementations of 'ld' on various flavors of Un*x |> would expect. There is no standard for the behavior of 'ld', Thank you for the admission :-) |> but common sense |> suggests that AIX's new 'ld' has the potential to cause much unneeded effort. And the same line of reasoning was used in the flame war in comp.unix.solaris when Solaris 2.0 was released and caused a lot of headaches because full binary compatibility was lost. |> Also, I suspect that most compiled languages which have a concept of seperate |> translation units and global objects also have the idea that global objects in |> different translation units ought to be consistent. They don't even have to be consistent in C, regardless of what the standard says. |> >|> I would be interested to hear from all C programmers who feel that multiple, |> >|> conflicting definitions of external C functions should by default not be |> >|> flagged in any way by the compiler or linker. |> |> >Would these be the same people who utilize multiple definitions of |> >symbols within various shared objects and rely on command line ordering |> >to refer to the desired symbol? So, within shared objects in a link cycle, |> >it's okay to have multiple definitions, but not in explicit object modules? |> >Therefore we _want_ inconsistent behavior in the linker? I don't think so. |> |> I'm not entirely clear on all of the details of shared objects, but my |> understanding is that they should act the way libraries (lib*.a) work. The |> semantics is the same. No, they're not. Not on AIX, not on SunOS, etc. Do some research into them, and then we'll talk. |> Yes, object files and libraries are treated differently in the traditional |> behavior. And it is perhaps unfortunate that conflicting definitions in |> libraries are not flagged. But this does not mean that the extension of this |> unfortunate behavior by IBM is a good idea. The only difference in AIX is ld's ability to "separate" an object module into some component pieces and discard the portions not required or that conflict. Thus, any part of an object module that is not used does not actually end up in the executable. As far as I know, no other "standard" Un*x can make that claim. I'll leave the advantages of this feature as an exercise for the reader :-) |> >I myself would be very interested to hear how many non-trivial projects allow |> >the development of code that lends itself to the creation of multiple definitions |> >of symbols. Perhaps I'm being an idealist, but it seems to be that anything |> >larger than 2-3 people should be clearly defining and documenting what names |> >come into being and who writes what subsystem. Call me a dreamer :-) |> |> Yes, you're being an idealist. I'd be willing to bet that a problematic |> multiple definition was discovered by 'ld' during the development of over 99% |> of large (>100K SLOC) C programs. |> |> A more typical case is dealing with large quantities of poorly-written, |> undocumented code that the programmer didn't write and isn't familiar with. |> Under these circumstances, we need *help*, not creative interpretation of |> incorrect programs. |> |> >Because scoping rules vary from language to language, and ld _must_ respect |> >the idiosyncracies while trying to make intelligent decisions. |> |> This may be true, but is the behavior I'm complaining about required to |> support *any* language? Yes, it's required to support C. The link of reference to symbol within a translation unit is clearly defined and _distinclty_ _different_ that that from without. i.e. if a() calls b() _within the same file_ then the scope of that reference _can not_ be overridden. The same can't be said when a() and b() are in different files. And this makes a difference in what ld can do when handling multiple definitions. |> >IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly |> >organized code and questionable structure; reliance on undocumented behavior; |> >dependance upon "the way things happen to be", rather than concrete |> >methodologies. |> |> Good point. Are there any systems that do *not* allow these things? No, but the newer ones tend to impress better paradigms, don't ya think? (Ahhhh!!!! that word!!!! :-) |> >Regarding design and implementation, current and emerging standards |> >are attempting to fill these "holes"; and AIX is right up front when |> >it comes to adhering to those standards. |> |> Committee standards, perhaps, but not de facto standards in their absence. And everyone and their grandmother has de facto standards. Why are yours more "correct" than anyone elses? |> In this case, sloppiness is allowed, but AIX silently interprets it as it |> pleases. Most Un*xes disallow this sloppiness. |> |> >Oh dear, this is a religious discussion now, isn't it? :-) |> |> Is it? If you spend a day tracking one of these problems down, you might not |> think so. I have. All too often. And longer than a single day, I assure you. If you want to try it, use -bdelcsect and see what wierd little symbols turn up _undefined_. That might help you narrow in on the problem faster. |> We need *help*, not design self-righteousness. My goodness, I don't think we're talking self-righteousness, we're talking technology and problem solving. -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________ From nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!vnet.IBM.COM Mon May 24 14:14:38 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!vnet.IBM.COM Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <19930521.065558.721@almaden.ibm.com> From: russotto@vnet.IBM.COM (Matthew T. Russotto) Date: Fri, 21 May 93 09:45:13 EDT References: <1433@mavrick.UUCP> Disclaimer: This posting represents the poster's views, not those of IBM News-Software: UReply 3.1 Lines: 32 Xref: filly comp.unix.aix:23482 comp.unix.programmer:10957 comp.lang.c:37476 Status: O In Mike Coleman writes: >It's not the lack of intelligence or capability, it's the lack of information. >When a linker sees multiple conflicting external symbol definitions, it >doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. > >The AIX linker, on the other hand, silently makes a proxy decision about what >the programmer might have intended. > >A flag to disable (or better yet *enable*) this "feature" could easily be >added. Until it exists, I think this problem makes AIX unfit for software >development in C (at least). I think this is overreaction, to say the least. >Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what >anyone who's used existing implementations of 'ld' on various flavors of Un*x >would expect. There is no standard for the behavior of 'ld', but common sense >suggests that AIX's new 'ld' has the potential to cause much unneeded effort. Personally, I think the "traditional" behavior of discarding symbol definitions if the symbols haven't yet been referenced causes much unneeded effort. >Also, I suspect that most compiled languages which have a concept of seperate >translation units and global objects also have the idea that global objects in >different translation units ought to be consistent. You might want to try the -qextchk option to the cc/xlc command. It might do some of what you want. (though, unfortunately, somewhat cryptically-- if you reference a symbol which has a different type than it expects, it considers the symbol undefined. And it won't distinguish between multiple compatible declarations of a symbol name.) From nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!torolab6.VNET.IBM.COM Mon May 24 14:14:38 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!torolab6.VNET.IBM.COM Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <19930521.070546.904@almaden.ibm.com> From: ferreira@torolab6.VNET.IBM.COM (John Ferreira) Date: Fri, 21 May 93 09:50:12 EDT References: <1433@mavrick.UUCP> Organization: IBM Canada Disclaimer: This posting represents the poster's views, not those of IBM News-Software: UReply 3.0 Lines: 33 Xref: filly comp.unix.aix:23484 comp.unix.programmer:10958 comp.lang.c:37477 Status: O In Mike Coleman writes: >hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >I'm not sure what "the issue" is, but clearly a Un*x linker is capable of >flagging conflicting external symbol definitions. That nearly all Un*x >linkers in existence already do this proves that. > >I'm aware that C exists on non-Un*x platforms. As far as I am aware, linkers >on these platforms also typically flag conflicting symbol definitions, by >default. > ... > >It's not the lack of intelligence or capability, it's the lack of information. >When a linker sees multiple conflicting external symbol definitions, it >doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. > >The AIX linker, on the other hand, silently makes a proxy decision about what >the programmer might have intended. > >A flag to disable (or better yet *enable*) this "feature" could easily be >added. Until it exists, I think this problem makes AIX unfit for software >development in C (at least). > The AIX linker does have an option that allows identification of duplicate symbols: -bh:2 If you compile two programs tmp1.c tmp2.c that contain duplicate a duplicate function, func1, cc tmp1.c tmp2.c -bh:2 You get the following message: 0706-224 WARNING: Duplicate symbol '.func1'. John Ferreira From nic.csu.net!csus.edu!wupost!howland.reston.ans.net!zaphod.mps.ohio-state.edu! Mon May 24 14:14:39 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!howland.reston.ans.net!zaphod.mps.ohio-state.edu! malgudi.oar.net!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Fri, 21 May 1993 21:22:29 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1993May20.233700.2462@chpc.utexas.edu> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 31 Xref: filly comp.unix.aix:23519 comp.unix.programmer:10966 comp.lang.c:37509 Status: O In article <1993May20.233700.2462@chpc.utexas.edu>, pefv700@chpc.utexas.edu (Christopher Phillips) writes: |> Well, here's one scenario that happened to me. Say you have a.c, b.c, |> lib1.a, and lib2.a. Further suppose that lib1.a and lib2.a both |> share an external function ``func.'' |> |> Now |> |> AIX31% cc a.o b.o -llib1 -llib2 |> |> complains about unresolved externals that are *clearly* in one of |> the two libraries. Try changing the order of a.o and b.o or |> -llib1 and -llib2. ld complains again, giving some of the same |> symbols as before and some new ones. |> |> It's one thing to complain. It's another thing to give misleading |> information. (Of course, if it hadn't complained, bad things |> -- hopefully -- would have happened at run time.) |> This is a side effect of the -bdelcsect flag that was the default on 3.1. Unfortunately, this behavior is woefully undocumented, and the change was made at 3.1.6 (I think) to default to nodelcsect. |> Chris -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________ From nic.csu.net!csus.edu!decwrl!decwrl!spool.mu.edu!howland.reston.ans.net! Mon May 24 14:14:31 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!spool.mu.edu!howland.reston.ans.net! europa.eng.gtefsd.com!emory!sol.ctr.columbia.edu!caen!malgudi.oar.net! news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Thu, 20 May 1993 16:08:24 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1433@mavrick.UUCP> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 96 Xref: filly comp.unix.aix:23432 comp.unix.programmer:10940 comp.lang.c:37403 Status: O In article , coleman@twinsun.com (Mike Coleman) writes: |> |So what are you saying here? That you would prefer that ld complain? |> |> YES, of course! This program would be considered bogus by any Unix linker |> I've ever used. Well, pardon me, but I think the issue goes beyond what a Un*x linker is capable of. Let's all remember that C is used on other platforms, also. |> If you link these files with b.c before c.c, you'll get one answer when you |> run the program, and if you do it the other way, you'll get another answer. |> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" |> 'ld' would complain loudly. Historically, that's because any allegedly "normal" ld has never had the intelligence or capability to do anything but complain and die. |> ||> The catch is that |> ||> even if a first definition of 's' has already been encountered, if an object |> ||> both references and defines 's', the latter "local" definition will be used. |> |> |Which is as it should be. The scoping rules of the C language dictate which |> |symbol definition is referred to when a file contains both a reference |> |and a definition of a symbol. The question becomes one of: what is a |> |reasonably intelligent action on the part of ld when that situation arises? |> |> The semantics of C given in the ANSI C standard specify that there is never to |> be more than one external definition of a particular function. While it is |> not required by the standard, in my opinion the only "reasonably intelligent" |> action is to emit a fatal error message and stop. Close, but incomplete. There is never to be more than one external definition of a particular symbol _within the same translation unit_. Later in section 3.7 the standard states that there is only a single definition within a program. During the link phase, the object modules do _not_ constitute a program; they act simply is input information for the linker. Your arguments appear (to me; no flame intended) to be combining aspects of compiling and linking. The two are not the same. And using the definition of a single language to determine what the behavior of some other utility should be strikes me as interesting :-) |> I would be interested to hear from all C programmers who feel that multiple, |> conflicting definitions of external C functions should by default not be |> flagged in any way by the compiler or linker. Would these be the same people who utilize multiple definitions of symbols within various shared objects and rely on command line ordering to refer to the desired symbol? So, within shared objects in a link cycle, it's okay to have multiple definitions, but not in explicit object modules? Therefore we _want_ inconsistent behavior in the linker? I don't think so. I myself would be very interested to hear how many non-trivial projects allow the development of code that lends itself to the creation of multiple definitions of symbols. Perhaps I'm being an idealist, but it seems to be that anything larger than 2-3 people should be clearly defining and documenting what names come into being and who writes what subsystem. Call me a dreamer :-) |> |> ||> This means that some references to duplicate symbols are dependent on ld |> ||> argument order, and some are not. |> |> |Some are dependant upon the language being used. |> |> I'm not sure I understand the point, Because scoping rules vary from language to language, and ld _must_ respect the idiosyncracies while trying to make intelligent decisions. |> ||> Because of these problems, it might be better to develop software on a Un*x |> ||> system, and only use AIX to compile it once it's been determined to be |> ||> correct. |> |> |Well, I see we're playing a game of semantics. When it comes down to |> |correctness of code, it's actually smarter to develop on AIX and port to |> |other platforms :-) |> |> Okay, I'll bite. Why would that be? IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly organized code and questionable structure; reliance on undocumented behavior; dependance upon "the way things happen to be", rather than concrete methodologies. Regarding design and implementation, current and emerging standards are attempting to fill these "holes"; and AIX is right up front when it comes to adhering to those standards. The sloppiness exhibited by an awful lot of the code I've seen (on other platforms) isn't (as oftern) allowed in AIX, and from a reliability standpoint, I'll take tight and organized any day. Oh dear, this is a religious discussion now, isn't it? :-) -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________ From nic.csu.net!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Mon May 24 14:14:32 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: coleman@twinsun.com (Mike Coleman) Date: Thu, 20 May 1993 22:49:00 GMT Sender: usenet@twinsun.com References: <1433@mavrick.UUCP> Organization: Twin Sun Inc, El Segundo, CA, USA Nntp-Posting-Host: twin Lines: 125 Xref: filly comp.unix.aix:23465 comp.unix.programmer:10949 comp.lang.c:37439 Status: O hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. I'm not sure what "the issue" is, but clearly a Un*x linker is capable of flagging conflicting external symbol definitions. That nearly all Un*x linkers in existence already do this proves that. I'm aware that C exists on non-Un*x platforms. As far as I am aware, linkers on these platforms also typically flag conflicting symbol definitions, by default. >|> If you link these files with b.c before c.c, you'll get one answer when you >|> run the program, and if you do it the other way, you'll get another answer. >|> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" >|> 'ld' would complain loudly. >Historically, that's because any allegedly "normal" ld has never had the >intelligence or capability to do anything but complain and die. It's not the lack of intelligence or capability, it's the lack of information. When a linker sees multiple conflicting external symbol definitions, it doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. The AIX linker, on the other hand, silently makes a proxy decision about what the programmer might have intended. A flag to disable (or better yet *enable*) this "feature" could easily be added. Until it exists, I think this problem makes AIX unfit for software development in C (at least). >Close, but incomplete. There is never to be more than one external definition of >a particular symbol _within the same translation unit_. Later in section 3.7 >the standard states that there is only a single definition within a program. >During the link phase, the object modules do _not_ constitute a program; they >act simply is input information for the linker. I agree that the ANSI C standard is not specific enough about linking methods to exclude the IBM linking model. >Your arguments appear (to me; no flame intended) to be combining aspects >of compiling and linking. The two are not the same. And using the definition >of a single language to determine what the behavior of some other utility >should be strikes me as interesting :-) Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what anyone who's used existing implementations of 'ld' on various flavors of Un*x would expect. There is no standard for the behavior of 'ld', but common sense suggests that AIX's new 'ld' has the potential to cause much unneeded effort. Also, I suspect that most compiled languages which have a concept of seperate translation units and global objects also have the idea that global objects in different translation units ought to be consistent. >|> I would be interested to hear from all C programmers who feel that multiple, >|> conflicting definitions of external C functions should by default not be >|> flagged in any way by the compiler or linker. >Would these be the same people who utilize multiple definitions of >symbols within various shared objects and rely on command line ordering >to refer to the desired symbol? So, within shared objects in a link cycle, >it's okay to have multiple definitions, but not in explicit object modules? >Therefore we _want_ inconsistent behavior in the linker? I don't think so. I'm not entirely clear on all of the details of shared objects, but my understanding is that they should act the way libraries (lib*.a) work. The semantics is the same. Yes, object files and libraries are treated differently in the traditional behavior. And it is perhaps unfortunate that conflicting definitions in libraries are not flagged. But this does not mean that the extension of this unfortunate behavior by IBM is a good idea. >I myself would be very interested to hear how many non-trivial projects allow >the development of code that lends itself to the creation of multiple definitions >of symbols. Perhaps I'm being an idealist, but it seems to be that anything >larger than 2-3 people should be clearly defining and documenting what names >come into being and who writes what subsystem. Call me a dreamer :-) Yes, you're being an idealist. I'd be willing to bet that a problematic multiple definition was discovered by 'ld' during the development of over 99% of large (>100K SLOC) C programs. A more typical case is dealing with large quantities of poorly-written, undocumented code that the programmer didn't write and isn't familiar with. Under these circumstances, we need *help*, not creative interpretation of incorrect programs. >Because scoping rules vary from language to language, and ld _must_ respect >the idiosyncracies while trying to make intelligent decisions. This may be true, but is the behavior I'm complaining about required to support *any* language? >IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly >organized code and questionable structure; reliance on undocumented behavior; >dependance upon "the way things happen to be", rather than concrete >methodologies. Good point. Are there any systems that do *not* allow these things? >Regarding design and implementation, current and emerging standards >are attempting to fill these "holes"; and AIX is right up front when >it comes to adhering to those standards. Committee standards, perhaps, but not de facto standards in their absence. >The sloppiness exhibited by an awful >lot of the code I've seen (on other platforms) isn't (as oftern) allowed in AIX, >and from a reliability standpoint, I'll take tight and organized any day. In this case, sloppiness is allowed, but AIX silently interprets it as it pleases. Most Un*xes disallow this sloppiness. >Oh dear, this is a religious discussion now, isn't it? :-) Is it? If you spend a day tracking one of these problems down, you might not think so. We need *help*, not design self-righteousness. Mike -- Speaking only for myself, of course. From nic.csu.net!csus.edu!wupost!cs.utexas.edu!hermes.chpc.utexas.edu!pefv700 Mon May 24 14:14:35 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!hermes.chpc.utexas.edu!pefv700 Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <1993May20.233700.2462@chpc.utexas.edu> From: pefv700@chpc.utexas.edu (Christopher Phillips) Date: Thu, 20 May 93 23:37:00 GMT References: Organization: The University of Texas System - CHPC Lines: 36 Xref: filly comp.unix.aix:23463 comp.unix.programmer:10948 comp.lang.c:37438 Status: O In article hook@vnet.ibm.com writes: >In article , coleman@twinsun.com (Mike Coleman) writes: >|> |So what are you saying here? That you would prefer that ld complain? >|> >|> YES, of course! This program would be considered bogus by any Unix linker >|> I've ever used. > >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. > >|> If you link these files with b.c before c.c, you'll get one answer when you >|> run the program, and if you do it the other way, you'll get another answer. >|> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" >|> 'ld' would complain loudly. > >Historically, that's because any allegedly "normal" ld has never had the >intelligence or capability to do anything but complain and die. Well, here's one scenario that happened to me. Say you have a.c, b.c, lib1.a, and lib2.a. Further suppose that lib1.a and lib2.a both share an external function ``func.'' Now AIX31% cc a.o b.o -llib1 -llib2 complains about unresolved externals that are *clearly* in one of the two libraries. Try changing the order of a.o and b.o or -llib1 and -llib2. ld complains again, giving some of the same symbols as before and some new ones. It's one thing to complain. It's another thing to give misleading information. (Of course, if it hadn't complained, bad things -- hopefully -- would have happened at run time.) Chris From nic.csu.net!csus.edu!decwrl!decwrl!sdd.hp.com!elroy.jpl.nasa.gov!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Mon May 24 14:14:36 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!sdd.hp.com!elroy.jpl.nasa.gov!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: coleman@twinsun.com (Mike Coleman) Date: Thu, 20 May 1993 02:04:44 GMT Sender: usenet@twinsun.com References: <1433@mavrick.UUCP> Organization: Twin Sun Inc, El Segundo, CA, USA Nntp-Posting-Host: twin Lines: 94 Xref: filly comp.unix.aix:23405 comp.unix.programmer:10930 comp.lang.c:37355 Status: O hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: ||> It appears that the AIX linker simply *expects* global symbols to be ||> redefined. For example, it doesn't have any trouble linking together the ||> following two files: ||> ||> a.c: int a() { return 2+c(); } int main() { return a(); } ||> b.c: int c() { return 5; } int a() { return 3+c(); } |So what are you saying here? That you would prefer that ld complain? YES, of course! This program would be considered bogus by any Unix linker I've ever used. Here's a slightly more egregious example: a.c: #include int a() { f1(); return 2+c(); } int main() { f1(); printf("RETURN %u\n", a()); } b.c: #include int f1() { printf("b.c: f1\n"); } int c() { f1(); return 5; } int a() { f1(); return 3+c(); } c.c: #include int f1() { printf("c.c: f1\n"); } If you link these files with b.c before c.c, you'll get one answer when you run the program, and if you do it the other way, you'll get another answer. You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" 'ld' would complain loudly. |But (IMHO) I've found that the discarding |of duplicate symbol definitions can be rather convenient. It may be, if you know they're there. I can imagine annoyance or disaster if you don't, which can easily be the case since AIX 'ld' will not tell you. The only reasonable way to get this information under AIX is to use a special, non-standard 'ld' flag to get a log file, and then run that log file through a custom 'sed' (or whatever) script to strip out spurious warnings. This procedure would be complicated, unreliable, prone to break, and generally unknown to new AIX users. ||> The catch is that ||> even if a first definition of 's' has already been encountered, if an object ||> both references and defines 's', the latter "local" definition will be used. |Which is as it should be. The scoping rules of the C language dictate which |symbol definition is referred to when a file contains both a reference |and a definition of a symbol. The question becomes one of: what is a |reasonably intelligent action on the part of ld when that situation arises? The semantics of C given in the ANSI C standard specify that there is never to be more than one external definition of a particular function. While it is not required by the standard, in my opinion the only "reasonably intelligent" action is to emit a fatal error message and stop. I would be interested to hear from all C programmers who feel that multiple, conflicting definitions of external C functions should by default not be flagged in any way by the compiler or linker. ||> This means that some references to duplicate symbols are dependent on ld ||> argument order, and some are not. |Some are dependant upon the language being used. I'm not sure I understand the point, but I don't think this makes me feel any better. ||> but the AIX linker will not complain. |No. It handles the situation in a reasonable manner and provides diagnostics |information for you to peruse at your leisure. That's just the problem. By default, it doesn't produce *any* diagnostics. If you *specifically* ask for them, it will give you a long log. If your program uses Xlib, you'll have to wade through dozens of spurious warnings to try to find one you might be looking for. This is unacceptable. ||> Because of these problems, it might be better to develop software on a Un*x ||> system, and only use AIX to compile it once it's been determined to be ||> correct. |Well, I see we're playing a game of semantics. When it comes down to |correctness of code, it's actually smarter to develop on AIX and port to |other platforms :-) Okay, I'll bite. Why would that be? Mike -- El Segundo, California--Where the jets rumble over the sharks From nic.csu.net!csus.edu!decwrl!decwrl!elroy.jpl.nasa.gov!swrinde!gatech!concert! Mon May 24 14:14:36 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!elroy.jpl.nasa.gov!swrinde!gatech!concert! news-feed-1.peachnet.edu!umn.edu!gaia.ucs.orst.edu!wsrcc.com! hack.dragoman.com!wetware!spunky.RedBrick.COM!psinntp!psinntp!curly.appmag.com!pa Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <1449@curly.appmag.com> From: pa@curly.appmag.com (Pierre Asselin) Date: 21 May 93 01:01:19 GMT Followup-To: comp.unix.aix References: <1433@mavrick.UUCP> Organization: Applied Magnetics, Goleta, CA Lines: 96 Xref: filly comp.unix.aix:23515 comp.unix.programmer:10964 comp.lang.c:37508 Status: O In hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >In article , coleman@twinsun.com (Mike Coleman) writes: >|> |So what are you saying here? That you would prefer that ld complain? >|> >|> YES, of course! This program would be considered bogus by any Unix linker >|> I've ever used. >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. Agreed, but I concur with Mike Coleman. This program would be considered bogus by any linker trying to button up the pieces of a C program. >Close, but incomplete. There is never to be more than one external >definition of a particular symbol _within the same translation unit_. >Later in section 3.7 the standard states that there is only a single >definition within a program. During the link phase, the object modules >do _not_ constitute a program; they act simply is input information for >the linker. I don't think your position is defensible. See section 3.1.2.2, line 10: "In the set of translation units and libraries that constitutes an entire program, each instance of a particular identifier with external linkage denotes the same object or function." I think the object modules are a little more than input to the linker. The corresponding section of the Rationale adds, "...only a single translation unit contains the definition of a given object..." Granted, this last bit is not the standard proper, but it should carry some weight. >Your arguments appear (to me; no flame intended) to be combining aspects >of compiling and linking. The two are not the same. And using the definition >of a single language to determine what the behavior of some other utility >should be strikes me as interesting :-) If I link Mike's example on AIX using `bind', I expect to have to read the fine print in the manual. If I use `ld', I expect familiar behaviour, in this case a link-time error. If I link with `cc' or `xlc', the C standard *demands* a link-time error. Whether cc and ld are implemented on top of bind is irrelevant. Cc and ld ought to work like they used to. I know AIX is not Unix, but I still hate it when the utilities remind me. >Would these be the same people who utilize multiple definitions of >symbols within various shared objects and rely on command line ordering >to refer to the desired symbol? So, within shared objects in a link cycle, >it's okay to have multiple definitions, but not in explicit object modules? >Therefore we _want_ inconsistent behavior in the linker? I don't think so. I think I understand what you are saying, but I'm not sure. My mental model of the linker is one where all object files are unconditionally combined; libraries are searched when there are unsatisfied external references; object files are pulled from the libraries as necessary to satisfy the references, at the risk of introducing more unsatisfied references and triggering more library searches. That's what I know. I find it useful to be able to type $ cc -o testprog myprog.o tidbit.o mylib.a when I want to test an experimental version of the object `tidbit.o' in the library `mylib.a'. Many implementations of shared libraries do not allow it, for example because other objects in mylib.a are pre-linked to the tidbit.o of the library. I consider this a design flaw. >I myself would be very interested to hear how many non-trivial projects >allow the development of code that lends itself to the creation of >multiple definitions of symbols. None, I hope. Conflicting definitions of the same external symbol are errors. Blow up loud! >IMHO (from what I've seen) Un*x systems tend to allow development of >haphazardly organized code [...] >The sloppiness exhibited by an awful lot of the code >I've seen (on other platforms) isn't (as oftern) allowed in AIX, and >from a reliability standpoint, I'll take tight and organized any day. I wouldn't present AIX as a shining example. I *do* see IBM trying to tidy up their flavour of Unix but I think reinventing the wheel got in their way. I am typing this on a 520 running the now unsupported AIX 3.1.6. Why aren't we upgrading? because none of our 3.2.x machines work right, even after installing PTFs by the hectomeg. My machine is our email and news link to the world and we can't afford to lose it. Thank god I am no longer the sysadmin. -- --Pierre Asselin, Magnetoresistive Head Engineering, Applied Magnetics. pa@appmag.com the usual disclaimers apply. From nic.csu.net!csus.edu!wupost!emory!europa.eng.gtefsd.com!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Mon May 24 14:14:37 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!emory!europa.eng.gtefsd.com!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Fri, 21 May 1993 22:10:31 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1433@mavrick.UUCP> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 161 Xref: filly comp.unix.aix:23523 comp.unix.programmer:10968 comp.lang.c:37511 Status: O In article , coleman@twinsun.com (Mike Coleman) writes: |> hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: |> >Historically, that's because any allegedly "normal" ld has never had the |> >intelligence or capability to do anything but complain and die. |> |> It's not the lack of intelligence or capability, it's the lack of information. |> When a linker sees multiple conflicting external symbol definitions, it |> doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. Well, I disagree. And given that many programmers historically have used command line ordering to perform symbol resolution precedence operations (re: shared objects below), I'll have to disagree that ld _should_ die. |> The AIX linker, on the other hand, silently makes a proxy decision about what |> the programmer might have intended. |> |> A flag to disable (or better yet *enable*) this "feature" could easily be |> added. Until it exists, I think this problem makes AIX unfit for software |> development in C (at least). ANd the fundamental capability of the system with respect to shared objects has already provided your other annoyance: extraneious complaints from the X libraries. The floag _does_ exist, you simply appear to be unsatisfied with that as well. |> |> >Close, but incomplete. There is never to be more than one external definition of |> >a particular symbol _within the same translation unit_. Later in section 3.7 |> >the standard states that there is only a single definition within a program. |> >During the link phase, the object modules do _not_ constitute a program; they |> >act simply is input information for the linker. |> |> I agree that the ANSI C standard is not specific enough about linking methods |> to exclude the IBM linking model. |> |> >Your arguments appear (to me; no flame intended) to be combining aspects |> >of compiling and linking. The two are not the same. And using the definition |> >of a single language to determine what the behavior of some other utility |> >should be strikes me as interesting :-) |> |> Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what |> anyone who's used existing implementations of 'ld' on various flavors of Un*x |> would expect. There is no standard for the behavior of 'ld', Thank you for the admission :-) |> but common sense |> suggests that AIX's new 'ld' has the potential to cause much unneeded effort. And the same line of reasoning was used in the flame war in comp.unix.solaris when Solaris 2.0 was released and caused a lot of headaches because full binary compatibility was lost. |> Also, I suspect that most compiled languages which have a concept of seperate |> translation units and global objects also have the idea that global objects in |> different translation units ought to be consistent. They don't even have to be consistent in C, regardless of what the standard says. |> >|> I would be interested to hear from all C programmers who feel that multiple, |> >|> conflicting definitions of external C functions should by default not be |> >|> flagged in any way by the compiler or linker. |> |> >Would these be the same people who utilize multiple definitions of |> >symbols within various shared objects and rely on command line ordering |> >to refer to the desired symbol? So, within shared objects in a link cycle, |> >it's okay to have multiple definitions, but not in explicit object modules? |> >Therefore we _want_ inconsistent behavior in the linker? I don't think so. |> |> I'm not entirely clear on all of the details of shared objects, but my |> understanding is that they should act the way libraries (lib*.a) work. The |> semantics is the same. No, they're not. Not on AIX, not on SunOS, etc. Do some research into them, and then we'll talk. |> Yes, object files and libraries are treated differently in the traditional |> behavior. And it is perhaps unfortunate that conflicting definitions in |> libraries are not flagged. But this does not mean that the extension of this |> unfortunate behavior by IBM is a good idea. The only difference in AIX is ld's ability to "separate" an object module into some component pieces and discard the portions not required or that conflict. Thus, any part of an object module that is not used does not actually end up in the executable. As far as I know, no other "standard" Un*x can make that claim. I'll leave the advantages of this feature as an exercise for the reader :-) |> >I myself would be very interested to hear how many non-trivial projects allow |> >the development of code that lends itself to the creation of multiple definitions |> >of symbols. Perhaps I'm being an idealist, but it seems to be that anything |> >larger than 2-3 people should be clearly defining and documenting what names |> >come into being and who writes what subsystem. Call me a dreamer :-) |> |> Yes, you're being an idealist. I'd be willing to bet that a problematic |> multiple definition was discovered by 'ld' during the development of over 99% |> of large (>100K SLOC) C programs. |> |> A more typical case is dealing with large quantities of poorly-written, |> undocumented code that the programmer didn't write and isn't familiar with. |> Under these circumstances, we need *help*, not creative interpretation of |> incorrect programs. |> |> >Because scoping rules vary from language to language, and ld _must_ respect |> >the idiosyncracies while trying to make intelligent decisions. |> |> This may be true, but is the behavior I'm complaining about required to |> support *any* language? Yes, it's required to support C. The link of reference to symbol within a translation unit is clearly defined and _distinclty_ _different_ that that from without. i.e. if a() calls b() _within the same file_ then the scope of that reference _can not_ be overridden. The same can't be said when a() and b() are in different files. And this makes a difference in what ld can do when handling multiple definitions. |> >IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly |> >organized code and questionable structure; reliance on undocumented behavior; |> >dependance upon "the way things happen to be", rather than concrete |> >methodologies. |> |> Good point. Are there any systems that do *not* allow these things? No, but the newer ones tend to impress better paradigms, don't ya think? (Ahhhh!!!! that word!!!! :-) |> >Regarding design and implementation, current and emerging standards |> >are attempting to fill these "holes"; and AIX is right up front when |> >it comes to adhering to those standards. |> |> Committee standards, perhaps, but not de facto standards in their absence. And everyone and their grandmother has de facto standards. Why are yours more "correct" than anyone elses? |> In this case, sloppiness is allowed, but AIX silently interprets it as it |> pleases. Most Un*xes disallow this sloppiness. |> |> >Oh dear, this is a religious discussion now, isn't it? :-) |> |> Is it? If you spend a day tracking one of these problems down, you might not |> think so. I have. All too often. And longer than a single day, I assure you. If you want to try it, use -bdelcsect and see what wierd little symbols turn up _undefined_. That might help you narrow in on the problem faster. |> We need *help*, not design self-righteousness. My goodness, I don't think we're talking self-righteousness, we're talking technology and problem solving. -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________ From nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!vnet.IBM.COM Mon May 24 14:14:38 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!vnet.IBM.COM Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <19930521.065558.721@almaden.ibm.com> From: russotto@vnet.IBM.COM (Matthew T. Russotto) Date: Fri, 21 May 93 09:45:13 EDT References: <1433@mavrick.UUCP> Disclaimer: This posting represents the poster's views, not those of IBM News-Software: UReply 3.1 Lines: 32 Xref: filly comp.unix.aix:23482 comp.unix.programmer:10957 comp.lang.c:37476 Status: O In Mike Coleman writes: >It's not the lack of intelligence or capability, it's the lack of information. >When a linker sees multiple conflicting external symbol definitions, it >doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. > >The AIX linker, on the other hand, silently makes a proxy decision about what >the programmer might have intended. > >A flag to disable (or better yet *enable*) this "feature" could easily be >added. Until it exists, I think this problem makes AIX unfit for software >development in C (at least). I think this is overreaction, to say the least. >Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what >anyone who's used existing implementations of 'ld' on various flavors of Un*x >would expect. There is no standard for the behavior of 'ld', but common sense >suggests that AIX's new 'ld' has the potential to cause much unneeded effort. Personally, I think the "traditional" behavior of discarding symbol definitions if the symbols haven't yet been referenced causes much unneeded effort. >Also, I suspect that most compiled languages which have a concept of seperate >translation units and global objects also have the idea that global objects in >different translation units ought to be consistent. You might want to try the -qextchk option to the cc/xlc command. It might do some of what you want. (though, unfortunately, somewhat cryptically-- if you reference a symbol which has a different type than it expects, it considers the symbol undefined. And it won't distinguish between multiple compatible declarations of a symbol name.) From nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!torolab6.VNET.IBM.COM Mon May 24 14:14:38 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!torolab6.VNET.IBM.COM Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <19930521.070546.904@almaden.ibm.com> From: ferreira@torolab6.VNET.IBM.COM (John Ferreira) Date: Fri, 21 May 93 09:50:12 EDT References: <1433@mavrick.UUCP> Organization: IBM Canada Disclaimer: This posting represents the poster's views, not those of IBM News-Software: UReply 3.0 Lines: 33 Xref: filly comp.unix.aix:23484 comp.unix.programmer:10958 comp.lang.c:37477 Status: O In Mike Coleman writes: >hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >I'm not sure what "the issue" is, but clearly a Un*x linker is capable of >flagging conflicting external symbol definitions. That nearly all Un*x >linkers in existence already do this proves that. > >I'm aware that C exists on non-Un*x platforms. As far as I am aware, linkers >on these platforms also typically flag conflicting symbol definitions, by >default. > ... > >It's not the lack of intelligence or capability, it's the lack of information. >When a linker sees multiple conflicting external symbol definitions, it >doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. > >The AIX linker, on the other hand, silently makes a proxy decision about what >the programmer might have intended. > >A flag to disable (or better yet *enable*) this "feature" could easily be >added. Until it exists, I think this problem makes AIX unfit for software >development in C (at least). > The AIX linker does have an option that allows identification of duplicate symbols: -bh:2 If you compile two programs tmp1.c tmp2.c that contain duplicate a duplicate function, func1, cc tmp1.c tmp2.c -bh:2 You get the following message: 0706-224 WARNING: Duplicate symbol '.func1'. John Ferreira From nic.csu.net!csus.edu!wupost!howland.reston.ans.net!zaphod.mps.ohio-state.edu! Mon May 24 14:14:39 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!howland.reston.ans.net!zaphod.mps.ohio-state.edu! malgudi.oar.net!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Fri, 21 May 1993 21:22:29 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1993May20.233700.2462@chpc.utexas.edu> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 31 Xref: filly comp.unix.aix:23519 comp.unix.programmer:10966 comp.lang.c:37509 Status: O In article <1993May20.233700.2462@chpc.utexas.edu>, pefv700@chpc.utexas.edu (Christopher Phillips) writes: |> Well, here's one scenario that happened to me. Say you have a.c, b.c, |> lib1.a, and lib2.a. Further suppose that lib1.a and lib2.a both |> share an external function ``func.'' |> |> Now |> |> AIX31% cc a.o b.o -llib1 -llib2 |> |> complains about unresolved externals that are *clearly* in one of |> the two libraries. Try changing the order of a.o and b.o or |> -llib1 and -llib2. ld complains again, giving some of the same |> symbols as before and some new ones. |> |> It's one thing to complain. It's another thing to give misleading |> information. (Of course, if it hadn't complained, bad things |> -- hopefully -- would have happened at run time.) |> This is a side effect of the -bdelcsect flag that was the default on 3.1. Unfortunately, this behavior is woefully undocumented, and the change was made at 3.1.6 (I think) to default to nodelcsect. |> Chris -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________ From nic.csu.net!csus.edu!decwrl!decwrl!spool.mu.edu!howland.reston.ans.net! Mon May 24 14:14:31 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!spool.mu.edu!howland.reston.ans.net! europa.eng.gtefsd.com!emory!sol.ctr.columbia.edu!caen!malgudi.oar.net! news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Thu, 20 May 1993 16:08:24 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1433@mavrick.UUCP> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 96 Xref: filly comp.unix.aix:23432 comp.unix.programmer:10940 comp.lang.c:37403 Status: O In article , coleman@twinsun.com (Mike Coleman) writes: |> |So what are you saying here? That you would prefer that ld complain? |> |> YES, of course! This program would be considered bogus by any Unix linker |> I've ever used. Well, pardon me, but I think the issue goes beyond what a Un*x linker is capable of. Let's all remember that C is used on other platforms, also. |> If you link these files with b.c before c.c, you'll get one answer when you |> run the program, and if you do it the other way, you'll get another answer. |> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" |> 'ld' would complain loudly. Historically, that's because any allegedly "normal" ld has never had the intelligence or capability to do anything but complain and die. |> ||> The catch is that |> ||> even if a first definition of 's' has already been encountered, if an object |> ||> both references and defines 's', the latter "local" definition will be used. |> |> |Which is as it should be. The scoping rules of the C language dictate which |> |symbol definition is referred to when a file contains both a reference |> |and a definition of a symbol. The question becomes one of: what is a |> |reasonably intelligent action on the part of ld when that situation arises? |> |> The semantics of C given in the ANSI C standard specify that there is never to |> be more than one external definition of a particular function. While it is |> not required by the standard, in my opinion the only "reasonably intelligent" |> action is to emit a fatal error message and stop. Close, but incomplete. There is never to be more than one external definition of a particular symbol _within the same translation unit_. Later in section 3.7 the standard states that there is only a single definition within a program. During the link phase, the object modules do _not_ constitute a program; they act simply is input information for the linker. Your arguments appear (to me; no flame intended) to be combining aspects of compiling and linking. The two are not the same. And using the definition of a single language to determine what the behavior of some other utility should be strikes me as interesting :-) |> I would be interested to hear from all C programmers who feel that multiple, |> conflicting definitions of external C functions should by default not be |> flagged in any way by the compiler or linker. Would these be the same people who utilize multiple definitions of symbols within various shared objects and rely on command line ordering to refer to the desired symbol? So, within shared objects in a link cycle, it's okay to have multiple definitions, but not in explicit object modules? Therefore we _want_ inconsistent behavior in the linker? I don't think so. I myself would be very interested to hear how many non-trivial projects allow the development of code that lends itself to the creation of multiple definitions of symbols. Perhaps I'm being an idealist, but it seems to be that anything larger than 2-3 people should be clearly defining and documenting what names come into being and who writes what subsystem. Call me a dreamer :-) |> |> ||> This means that some references to duplicate symbols are dependent on ld |> ||> argument order, and some are not. |> |> |Some are dependant upon the language being used. |> |> I'm not sure I understand the point, Because scoping rules vary from language to language, and ld _must_ respect the idiosyncracies while trying to make intelligent decisions. |> ||> Because of these problems, it might be better to develop software on a Un*x |> ||> system, and only use AIX to compile it once it's been determined to be |> ||> correct. |> |> |Well, I see we're playing a game of semantics. When it comes down to |> |correctness of code, it's actually smarter to develop on AIX and port to |> |other platforms :-) |> |> Okay, I'll bite. Why would that be? IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly organized code and questionable structure; reliance on undocumented behavior; dependance upon "the way things happen to be", rather than concrete methodologies. Regarding design and implementation, current and emerging standards are attempting to fill these "holes"; and AIX is right up front when it comes to adhering to those standards. The sloppiness exhibited by an awful lot of the code I've seen (on other platforms) isn't (as oftern) allowed in AIX, and from a reliability standpoint, I'll take tight and organized any day. Oh dear, this is a religious discussion now, isn't it? :-) -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________ From nic.csu.net!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Mon May 24 14:14:32 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: coleman@twinsun.com (Mike Coleman) Date: Thu, 20 May 1993 22:49:00 GMT Sender: usenet@twinsun.com References: <1433@mavrick.UUCP> Organization: Twin Sun Inc, El Segundo, CA, USA Nntp-Posting-Host: twin Lines: 125 Xref: filly comp.unix.aix:23465 comp.unix.programmer:10949 comp.lang.c:37439 Status: O hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. I'm not sure what "the issue" is, but clearly a Un*x linker is capable of flagging conflicting external symbol definitions. That nearly all Un*x linkers in existence already do this proves that. I'm aware that C exists on non-Un*x platforms. As far as I am aware, linkers on these platforms also typically flag conflicting symbol definitions, by default. >|> If you link these files with b.c before c.c, you'll get one answer when you >|> run the program, and if you do it the other way, you'll get another answer. >|> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" >|> 'ld' would complain loudly. >Historically, that's because any allegedly "normal" ld has never had the >intelligence or capability to do anything but complain and die. It's not the lack of intelligence or capability, it's the lack of information. When a linker sees multiple conflicting external symbol definitions, it doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. The AIX linker, on the other hand, silently makes a proxy decision about what the programmer might have intended. A flag to disable (or better yet *enable*) this "feature" could easily be added. Until it exists, I think this problem makes AIX unfit for software development in C (at least). >Close, but incomplete. There is never to be more than one external definition of >a particular symbol _within the same translation unit_. Later in section 3.7 >the standard states that there is only a single definition within a program. >During the link phase, the object modules do _not_ constitute a program; they >act simply is input information for the linker. I agree that the ANSI C standard is not specific enough about linking methods to exclude the IBM linking model. >Your arguments appear (to me; no flame intended) to be combining aspects >of compiling and linking. The two are not the same. And using the definition >of a single language to determine what the behavior of some other utility >should be strikes me as interesting :-) Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what anyone who's used existing implementations of 'ld' on various flavors of Un*x would expect. There is no standard for the behavior of 'ld', but common sense suggests that AIX's new 'ld' has the potential to cause much unneeded effort. Also, I suspect that most compiled languages which have a concept of seperate translation units and global objects also have the idea that global objects in different translation units ought to be consistent. >|> I would be interested to hear from all C programmers who feel that multiple, >|> conflicting definitions of external C functions should by default not be >|> flagged in any way by the compiler or linker. >Would these be the same people who utilize multiple definitions of >symbols within various shared objects and rely on command line ordering >to refer to the desired symbol? So, within shared objects in a link cycle, >it's okay to have multiple definitions, but not in explicit object modules? >Therefore we _want_ inconsistent behavior in the linker? I don't think so. I'm not entirely clear on all of the details of shared objects, but my understanding is that they should act the way libraries (lib*.a) work. The semantics is the same. Yes, object files and libraries are treated differently in the traditional behavior. And it is perhaps unfortunate that conflicting definitions in libraries are not flagged. But this does not mean that the extension of this unfortunate behavior by IBM is a good idea. >I myself would be very interested to hear how many non-trivial projects allow >the development of code that lends itself to the creation of multiple definitions >of symbols. Perhaps I'm being an idealist, but it seems to be that anything >larger than 2-3 people should be clearly defining and documenting what names >come into being and who writes what subsystem. Call me a dreamer :-) Yes, you're being an idealist. I'd be willing to bet that a problematic multiple definition was discovered by 'ld' during the development of over 99% of large (>100K SLOC) C programs. A more typical case is dealing with large quantities of poorly-written, undocumented code that the programmer didn't write and isn't familiar with. Under these circumstances, we need *help*, not creative interpretation of incorrect programs. >Because scoping rules vary from language to language, and ld _must_ respect >the idiosyncracies while trying to make intelligent decisions. This may be true, but is the behavior I'm complaining about required to support *any* language? >IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly >organized code and questionable structure; reliance on undocumented behavior; >dependance upon "the way things happen to be", rather than concrete >methodologies. Good point. Are there any systems that do *not* allow these things? >Regarding design and implementation, current and emerging standards >are attempting to fill these "holes"; and AIX is right up front when >it comes to adhering to those standards. Committee standards, perhaps, but not de facto standards in their absence. >The sloppiness exhibited by an awful >lot of the code I've seen (on other platforms) isn't (as oftern) allowed in AIX, >and from a reliability standpoint, I'll take tight and organized any day. In this case, sloppiness is allowed, but AIX silently interprets it as it pleases. Most Un*xes disallow this sloppiness. >Oh dear, this is a religious discussion now, isn't it? :-) Is it? If you spend a day tracking one of these problems down, you might not think so. We need *help*, not design self-righteousness. Mike -- Speaking only for myself, of course. From nic.csu.net!csus.edu!wupost!cs.utexas.edu!hermes.chpc.utexas.edu!pefv700 Mon May 24 14:14:35 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!hermes.chpc.utexas.edu!pefv700 Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <1993May20.233700.2462@chpc.utexas.edu> From: pefv700@chpc.utexas.edu (Christopher Phillips) Date: Thu, 20 May 93 23:37:00 GMT References: Organization: The University of Texas System - CHPC Lines: 36 Xref: filly comp.unix.aix:23463 comp.unix.programmer:10948 comp.lang.c:37438 Status: O In article hook@vnet.ibm.com writes: >In article , coleman@twinsun.com (Mike Coleman) writes: >|> |So what are you saying here? That you would prefer that ld complain? >|> >|> YES, of course! This program would be considered bogus by any Unix linker >|> I've ever used. > >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. > >|> If you link these files with b.c before c.c, you'll get one answer when you >|> run the program, and if you do it the other way, you'll get another answer. >|> You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" >|> 'ld' would complain loudly. > >Historically, that's because any allegedly "normal" ld has never had the >intelligence or capability to do anything but complain and die. Well, here's one scenario that happened to me. Say you have a.c, b.c, lib1.a, and lib2.a. Further suppose that lib1.a and lib2.a both share an external function ``func.'' Now AIX31% cc a.o b.o -llib1 -llib2 complains about unresolved externals that are *clearly* in one of the two libraries. Try changing the order of a.o and b.o or -llib1 and -llib2. ld complains again, giving some of the same symbols as before and some new ones. It's one thing to complain. It's another thing to give misleading information. (Of course, if it hadn't complained, bad things -- hopefully -- would have happened at run time.) Chris From nic.csu.net!csus.edu!decwrl!decwrl!sdd.hp.com!elroy.jpl.nasa.gov!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Mon May 24 14:14:36 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!sdd.hp.com!elroy.jpl.nasa.gov!usc!news.service.uci.edu!ucivax!ucla-cs!twinsun!coleman Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: coleman@twinsun.com (Mike Coleman) Date: Thu, 20 May 1993 02:04:44 GMT Sender: usenet@twinsun.com References: <1433@mavrick.UUCP> Organization: Twin Sun Inc, El Segundo, CA, USA Nntp-Posting-Host: twin Lines: 94 Xref: filly comp.unix.aix:23405 comp.unix.programmer:10930 comp.lang.c:37355 Status: O hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: ||> It appears that the AIX linker simply *expects* global symbols to be ||> redefined. For example, it doesn't have any trouble linking together the ||> following two files: ||> ||> a.c: int a() { return 2+c(); } int main() { return a(); } ||> b.c: int c() { return 5; } int a() { return 3+c(); } |So what are you saying here? That you would prefer that ld complain? YES, of course! This program would be considered bogus by any Unix linker I've ever used. Here's a slightly more egregious example: a.c: #include int a() { f1(); return 2+c(); } int main() { f1(); printf("RETURN %u\n", a()); } b.c: #include int f1() { printf("b.c: f1\n"); } int c() { f1(); return 5; } int a() { f1(); return 3+c(); } c.c: #include int f1() { printf("c.c: f1\n"); } If you link these files with b.c before c.c, you'll get one answer when you run the program, and if you do it the other way, you'll get another answer. You'll get no complaints from AIX 'cc' or 'ld' either way, though any "normal" 'ld' would complain loudly. |But (IMHO) I've found that the discarding |of duplicate symbol definitions can be rather convenient. It may be, if you know they're there. I can imagine annoyance or disaster if you don't, which can easily be the case since AIX 'ld' will not tell you. The only reasonable way to get this information under AIX is to use a special, non-standard 'ld' flag to get a log file, and then run that log file through a custom 'sed' (or whatever) script to strip out spurious warnings. This procedure would be complicated, unreliable, prone to break, and generally unknown to new AIX users. ||> The catch is that ||> even if a first definition of 's' has already been encountered, if an object ||> both references and defines 's', the latter "local" definition will be used. |Which is as it should be. The scoping rules of the C language dictate which |symbol definition is referred to when a file contains both a reference |and a definition of a symbol. The question becomes one of: what is a |reasonably intelligent action on the part of ld when that situation arises? The semantics of C given in the ANSI C standard specify that there is never to be more than one external definition of a particular function. While it is not required by the standard, in my opinion the only "reasonably intelligent" action is to emit a fatal error message and stop. I would be interested to hear from all C programmers who feel that multiple, conflicting definitions of external C functions should by default not be flagged in any way by the compiler or linker. ||> This means that some references to duplicate symbols are dependent on ld ||> argument order, and some are not. |Some are dependant upon the language being used. I'm not sure I understand the point, but I don't think this makes me feel any better. ||> but the AIX linker will not complain. |No. It handles the situation in a reasonable manner and provides diagnostics |information for you to peruse at your leisure. That's just the problem. By default, it doesn't produce *any* diagnostics. If you *specifically* ask for them, it will give you a long log. If your program uses Xlib, you'll have to wade through dozens of spurious warnings to try to find one you might be looking for. This is unacceptable. ||> Because of these problems, it might be better to develop software on a Un*x ||> system, and only use AIX to compile it once it's been determined to be ||> correct. |Well, I see we're playing a game of semantics. When it comes down to |correctness of code, it's actually smarter to develop on AIX and port to |other platforms :-) Okay, I'll bite. Why would that be? Mike -- El Segundo, California--Where the jets rumble over the sharks From nic.csu.net!csus.edu!decwrl!decwrl!elroy.jpl.nasa.gov!swrinde!gatech!concert! Mon May 24 14:14:36 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!decwrl!decwrl!elroy.jpl.nasa.gov!swrinde!gatech!concert! news-feed-1.peachnet.edu!umn.edu!gaia.ucs.orst.edu!wsrcc.com! hack.dragoman.com!wetware!spunky.RedBrick.COM!psinntp!psinntp!curly.appmag.com!pa Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <1449@curly.appmag.com> From: pa@curly.appmag.com (Pierre Asselin) Date: 21 May 93 01:01:19 GMT Followup-To: comp.unix.aix References: <1433@mavrick.UUCP> Organization: Applied Magnetics, Goleta, CA Lines: 96 Xref: filly comp.unix.aix:23515 comp.unix.programmer:10964 comp.lang.c:37508 Status: O In hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >In article , coleman@twinsun.com (Mike Coleman) writes: >|> |So what are you saying here? That you would prefer that ld complain? >|> >|> YES, of course! This program would be considered bogus by any Unix linker >|> I've ever used. >Well, pardon me, but I think the issue goes beyond what a Un*x linker is >capable of. Let's all remember that C is used on other platforms, also. Agreed, but I concur with Mike Coleman. This program would be considered bogus by any linker trying to button up the pieces of a C program. >Close, but incomplete. There is never to be more than one external >definition of a particular symbol _within the same translation unit_. >Later in section 3.7 the standard states that there is only a single >definition within a program. During the link phase, the object modules >do _not_ constitute a program; they act simply is input information for >the linker. I don't think your position is defensible. See section 3.1.2.2, line 10: "In the set of translation units and libraries that constitutes an entire program, each instance of a particular identifier with external linkage denotes the same object or function." I think the object modules are a little more than input to the linker. The corresponding section of the Rationale adds, "...only a single translation unit contains the definition of a given object..." Granted, this last bit is not the standard proper, but it should carry some weight. >Your arguments appear (to me; no flame intended) to be combining aspects >of compiling and linking. The two are not the same. And using the definition >of a single language to determine what the behavior of some other utility >should be strikes me as interesting :-) If I link Mike's example on AIX using `bind', I expect to have to read the fine print in the manual. If I use `ld', I expect familiar behaviour, in this case a link-time error. If I link with `cc' or `xlc', the C standard *demands* a link-time error. Whether cc and ld are implemented on top of bind is irrelevant. Cc and ld ought to work like they used to. I know AIX is not Unix, but I still hate it when the utilities remind me. >Would these be the same people who utilize multiple definitions of >symbols within various shared objects and rely on command line ordering >to refer to the desired symbol? So, within shared objects in a link cycle, >it's okay to have multiple definitions, but not in explicit object modules? >Therefore we _want_ inconsistent behavior in the linker? I don't think so. I think I understand what you are saying, but I'm not sure. My mental model of the linker is one where all object files are unconditionally combined; libraries are searched when there are unsatisfied external references; object files are pulled from the libraries as necessary to satisfy the references, at the risk of introducing more unsatisfied references and triggering more library searches. That's what I know. I find it useful to be able to type $ cc -o testprog myprog.o tidbit.o mylib.a when I want to test an experimental version of the object `tidbit.o' in the library `mylib.a'. Many implementations of shared libraries do not allow it, for example because other objects in mylib.a are pre-linked to the tidbit.o of the library. I consider this a design flaw. >I myself would be very interested to hear how many non-trivial projects >allow the development of code that lends itself to the creation of >multiple definitions of symbols. None, I hope. Conflicting definitions of the same external symbol are errors. Blow up loud! >IMHO (from what I've seen) Un*x systems tend to allow development of >haphazardly organized code [...] >The sloppiness exhibited by an awful lot of the code >I've seen (on other platforms) isn't (as oftern) allowed in AIX, and >from a reliability standpoint, I'll take tight and organized any day. I wouldn't present AIX as a shining example. I *do* see IBM trying to tidy up their flavour of Unix but I think reinventing the wheel got in their way. I am typing this on a 520 running the now unsupported AIX 3.1.6. Why aren't we upgrading? because none of our 3.2.x machines work right, even after installing PTFs by the hectomeg. My machine is our email and news link to the world and we can't afford to lose it. Thank god I am no longer the sysadmin. -- --Pierre Asselin, Magnetoresistive Head Engineering, Applied Magnetics. pa@appmag.com the usual disclaimers apply. From nic.csu.net!csus.edu!wupost!emory!europa.eng.gtefsd.com!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Mon May 24 14:14:37 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!emory!europa.eng.gtefsd.com!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Fri, 21 May 1993 22:10:31 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1433@mavrick.UUCP> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 161 Xref: filly comp.unix.aix:23523 comp.unix.programmer:10968 comp.lang.c:37511 Status: O In article , coleman@twinsun.com (Mike Coleman) writes: |> hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: |> >Historically, that's because any allegedly "normal" ld has never had the |> >intelligence or capability to do anything but complain and die. |> |> It's not the lack of intelligence or capability, it's the lack of information. |> When a linker sees multiple conflicting external symbol definitions, it |> doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. Well, I disagree. And given that many programmers historically have used command line ordering to perform symbol resolution precedence operations (re: shared objects below), I'll have to disagree that ld _should_ die. |> The AIX linker, on the other hand, silently makes a proxy decision about what |> the programmer might have intended. |> |> A flag to disable (or better yet *enable*) this "feature" could easily be |> added. Until it exists, I think this problem makes AIX unfit for software |> development in C (at least). ANd the fundamental capability of the system with respect to shared objects has already provided your other annoyance: extraneious complaints from the X libraries. The floag _does_ exist, you simply appear to be unsatisfied with that as well. |> |> >Close, but incomplete. There is never to be more than one external definition of |> >a particular symbol _within the same translation unit_. Later in section 3.7 |> >the standard states that there is only a single definition within a program. |> >During the link phase, the object modules do _not_ constitute a program; they |> >act simply is input information for the linker. |> |> I agree that the ANSI C standard is not specific enough about linking methods |> to exclude the IBM linking model. |> |> >Your arguments appear (to me; no flame intended) to be combining aspects |> >of compiling and linking. The two are not the same. And using the definition |> >of a single language to determine what the behavior of some other utility |> >should be strikes me as interesting :-) |> |> Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what |> anyone who's used existing implementations of 'ld' on various flavors of Un*x |> would expect. There is no standard for the behavior of 'ld', Thank you for the admission :-) |> but common sense |> suggests that AIX's new 'ld' has the potential to cause much unneeded effort. And the same line of reasoning was used in the flame war in comp.unix.solaris when Solaris 2.0 was released and caused a lot of headaches because full binary compatibility was lost. |> Also, I suspect that most compiled languages which have a concept of seperate |> translation units and global objects also have the idea that global objects in |> different translation units ought to be consistent. They don't even have to be consistent in C, regardless of what the standard says. |> >|> I would be interested to hear from all C programmers who feel that multiple, |> >|> conflicting definitions of external C functions should by default not be |> >|> flagged in any way by the compiler or linker. |> |> >Would these be the same people who utilize multiple definitions of |> >symbols within various shared objects and rely on command line ordering |> >to refer to the desired symbol? So, within shared objects in a link cycle, |> >it's okay to have multiple definitions, but not in explicit object modules? |> >Therefore we _want_ inconsistent behavior in the linker? I don't think so. |> |> I'm not entirely clear on all of the details of shared objects, but my |> understanding is that they should act the way libraries (lib*.a) work. The |> semantics is the same. No, they're not. Not on AIX, not on SunOS, etc. Do some research into them, and then we'll talk. |> Yes, object files and libraries are treated differently in the traditional |> behavior. And it is perhaps unfortunate that conflicting definitions in |> libraries are not flagged. But this does not mean that the extension of this |> unfortunate behavior by IBM is a good idea. The only difference in AIX is ld's ability to "separate" an object module into some component pieces and discard the portions not required or that conflict. Thus, any part of an object module that is not used does not actually end up in the executable. As far as I know, no other "standard" Un*x can make that claim. I'll leave the advantages of this feature as an exercise for the reader :-) |> >I myself would be very interested to hear how many non-trivial projects allow |> >the development of code that lends itself to the creation of multiple definitions |> >of symbols. Perhaps I'm being an idealist, but it seems to be that anything |> >larger than 2-3 people should be clearly defining and documenting what names |> >come into being and who writes what subsystem. Call me a dreamer :-) |> |> Yes, you're being an idealist. I'd be willing to bet that a problematic |> multiple definition was discovered by 'ld' during the development of over 99% |> of large (>100K SLOC) C programs. |> |> A more typical case is dealing with large quantities of poorly-written, |> undocumented code that the programmer didn't write and isn't familiar with. |> Under these circumstances, we need *help*, not creative interpretation of |> incorrect programs. |> |> >Because scoping rules vary from language to language, and ld _must_ respect |> >the idiosyncracies while trying to make intelligent decisions. |> |> This may be true, but is the behavior I'm complaining about required to |> support *any* language? Yes, it's required to support C. The link of reference to symbol within a translation unit is clearly defined and _distinclty_ _different_ that that from without. i.e. if a() calls b() _within the same file_ then the scope of that reference _can not_ be overridden. The same can't be said when a() and b() are in different files. And this makes a difference in what ld can do when handling multiple definitions. |> >IMHO (from what I've seen) Un*x systems tend to allow development of haphazardly |> >organized code and questionable structure; reliance on undocumented behavior; |> >dependance upon "the way things happen to be", rather than concrete |> >methodologies. |> |> Good point. Are there any systems that do *not* allow these things? No, but the newer ones tend to impress better paradigms, don't ya think? (Ahhhh!!!! that word!!!! :-) |> >Regarding design and implementation, current and emerging standards |> >are attempting to fill these "holes"; and AIX is right up front when |> >it comes to adhering to those standards. |> |> Committee standards, perhaps, but not de facto standards in their absence. And everyone and their grandmother has de facto standards. Why are yours more "correct" than anyone elses? |> In this case, sloppiness is allowed, but AIX silently interprets it as it |> pleases. Most Un*xes disallow this sloppiness. |> |> >Oh dear, this is a religious discussion now, isn't it? :-) |> |> Is it? If you spend a day tracking one of these problems down, you might not |> think so. I have. All too often. And longer than a single day, I assure you. If you want to try it, use -bdelcsect and see what wierd little symbols turn up _undefined_. That might help you narrow in on the problem faster. |> We need *help*, not design self-righteousness. My goodness, I don't think we're talking self-righteousness, we're talking technology and problem solving. -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________ From nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!vnet.IBM.COM Mon May 24 14:14:38 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!vnet.IBM.COM Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <19930521.065558.721@almaden.ibm.com> From: russotto@vnet.IBM.COM (Matthew T. Russotto) Date: Fri, 21 May 93 09:45:13 EDT References: <1433@mavrick.UUCP> Disclaimer: This posting represents the poster's views, not those of IBM News-Software: UReply 3.1 Lines: 32 Xref: filly comp.unix.aix:23482 comp.unix.programmer:10957 comp.lang.c:37476 Status: O In Mike Coleman writes: >It's not the lack of intelligence or capability, it's the lack of information. >When a linker sees multiple conflicting external symbol definitions, it >doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. > >The AIX linker, on the other hand, silently makes a proxy decision about what >the programmer might have intended. > >A flag to disable (or better yet *enable*) this "feature" could easily be >added. Until it exists, I think this problem makes AIX unfit for software >development in C (at least). I think this is overreaction, to say the least. >Perhaps I am. Let me be explicit, the AIX 'ld' command does not do what >anyone who's used existing implementations of 'ld' on various flavors of Un*x >would expect. There is no standard for the behavior of 'ld', but common sense >suggests that AIX's new 'ld' has the potential to cause much unneeded effort. Personally, I think the "traditional" behavior of discarding symbol definitions if the symbols haven't yet been referenced causes much unneeded effort. >Also, I suspect that most compiled languages which have a concept of seperate >translation units and global objects also have the idea that global objects in >different translation units ought to be consistent. You might want to try the -qextchk option to the cc/xlc command. It might do some of what you want. (though, unfortunately, somewhat cryptically-- if you reference a symbol which has a different type than it expects, it considers the symbol undefined. And it won't distinguish between multiple compatible declarations of a symbol name.) From nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!torolab6.VNET.IBM.COM Mon May 24 14:14:38 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!cs.utexas.edu!uunet!torolab6.VNET.IBM.COM Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: <19930521.070546.904@almaden.ibm.com> From: ferreira@torolab6.VNET.IBM.COM (John Ferreira) Date: Fri, 21 May 93 09:50:12 EDT References: <1433@mavrick.UUCP> Organization: IBM Canada Disclaimer: This posting represents the poster's views, not those of IBM News-Software: UReply 3.0 Lines: 33 Xref: filly comp.unix.aix:23484 comp.unix.programmer:10958 comp.lang.c:37477 Status: O In Mike Coleman writes: >hook@chaco.aix.dfw.ibm.com (Gary R. Hook) writes: >I'm not sure what "the issue" is, but clearly a Un*x linker is capable of >flagging conflicting external symbol definitions. That nearly all Un*x >linkers in existence already do this proves that. > >I'm aware that C exists on non-Un*x platforms. As far as I am aware, linkers >on these platforms also typically flag conflicting symbol definitions, by >default. > ... > >It's not the lack of intelligence or capability, it's the lack of information. >When a linker sees multiple conflicting external symbol definitions, it >doesn't have a *clue* what it ought to be doing, so it drops dead. Or should. > >The AIX linker, on the other hand, silently makes a proxy decision about what >the programmer might have intended. > >A flag to disable (or better yet *enable*) this "feature" could easily be >added. Until it exists, I think this problem makes AIX unfit for software >development in C (at least). > The AIX linker does have an option that allows identification of duplicate symbols: -bh:2 If you compile two programs tmp1.c tmp2.c that contain duplicate a duplicate function, func1, cc tmp1.c tmp2.c -bh:2 You get the following message: 0706-224 WARNING: Duplicate symbol '.func1'. John Ferreira From nic.csu.net!csus.edu!wupost!howland.reston.ans.net!zaphod.mps.ohio-state.edu! Mon May 24 14:14:39 1993 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS V5.5-2; site nic.csu.net Path: nic.csu.net!csus.edu!wupost!howland.reston.ans.net!zaphod.mps.ohio-state.edu! malgudi.oar.net!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!chaco.aix.dfw.ibm.com!hook Newsgroups: comp.unix.aix,comp.unix.programmer,comp.lang.c Subject: Re: AIX Frequently Asked Questions (linker problems) Message-ID: From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook) Date: Fri, 21 May 1993 21:22:29 GMT Reply-To: hook@vnet.ibm.com Sender: news@hawnews.watson.ibm.com (NNTP News Poster) References: <1993May20.233700.2462@chpc.utexas.edu> Organization: AIX Benchmark & Conversion Services Disclaimer: This posting represents the poster's views, not necessarily those of IBM. Nntp-Posting-Host: chaco.aix.dfw.ibm.com Lines: 31 Xref: filly comp.unix.aix:23519 comp.unix.programmer:10966 comp.lang.c:37509 Status: O In article <1993May20.233700.2462@chpc.utexas.edu>, pefv700@chpc.utexas.edu (Christopher Phillips) writes: |> Well, here's one scenario that happened to me. Say you have a.c, b.c, |> lib1.a, and lib2.a. Further suppose that lib1.a and lib2.a both |> share an external function ``func.'' |> |> Now |> |> AIX31% cc a.o b.o -llib1 -llib2 |> |> complains about unresolved externals that are *clearly* in one of |> the two libraries. Try changing the order of a.o and b.o or |> -llib1 and -llib2. ld complains again, giving some of the same |> symbols as before and some new ones. |> |> It's one thing to complain. It's another thing to give misleading |> information. (Of course, if it hadn't complained, bad things |> -- hopefully -- would have happened at run time.) |> This is a side effect of the -bdelcsect flag that was the default on 3.1. Unfortunately, this behavior is woefully undocumented, and the change was made at 3.1.6 (I think) to default to nodelcsect. |> Chris -- ________________________________________________________________________ Gary R. Hook Si jeunesse savoit; si AIX Benchmark & Conversion Services vieillesse pouvoit. IBM Corporation, Southlake, Texas -- Henri Estienne All opinions expressed are mine alone. _______________________________