Discuss

discuss@lists.centos.org

34753 discussions

Centos 3 samba upgrade
by Colht, Charles 20 Sep '05

20 Sep '05

I want to upgrade my samba installation from 3.0.9-1.3E.3 to 3.0.20 without breaking anything along the way :) Any suggestions about order of installation? It looks like I will have to nodeps at least some of the packages. I have everything working with our AD environment so I don't want to disturb it if possible. Thanks in advance, Chuck *********************************************************************************** This transmittal may contain confidential information intended solely for the addressee. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, distribution or copying of this transmittal is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone (collect at 907-564-1000) and ask to speak with the message sender. In addition, please immediately delete this message and all attachments. Thank you. ACS

3 2

[3.5 Server] Problem with libjpeg.a or absence of
by Sean Rima 20 Sep '05

20 Sep '05

Hello CentOS, I am trying to compile zoneminder which requires libjpeg.a I jave libjpeg.so installed okay. Is there a package or do I have to recompile the libjpeg package Sean -- +---------------------------------------------------+ |VOIP= FreeWorldDial: 689482 VOIPBUSTER: thecivvie | |GPG Key http://thecivvie.fastmail.fm/thecivvie.asc | +---------------------------------------------------+ Strange things happen under the midnight sun when Men and Dogs go hunting for gold

2 2

Re: [CentOS] upgrade problem
by Brian T. Brunner 20 Sep '05

20 Sep '05

>>>>mike.mccarty(a)sbcglobal.net 09/20/05 11:16AM >>> > ***pedantic*** I have to get the compiler to compile the code, the language definition won't do that. > ***pragmatic*** I'm here to drain the swamp, not analyze the alligators. > ***overall** How did the compilers change in what they tolerate. Certainly. I didn't mean something silly like "Well, the compiler is broken today. I guess I'll go home and watch TV." ***Good... because I don't have one (Troglodyte!)*** If the compiler is broken, then it will soon be fixed. ***Until then I gotta adapt code that worked with one broken compiler to another broken compiler. > Also, the C Language did not recently change. > > ***the compiler is the cop, the language definition is the law*** Cops which break the law go to jail just like everyone else. Eventually, the cops enforce the law as written. ***I'm going to guess: you're white, male, and economically rather well off. ***Because of this, your "world" basically "works" and crooked cops are the exception that get brought to justice for breaking the rules. ***(some) Cops ignoring (some of) the law is the way things are; in some places that *is* the rule the judges uphold. BTDT. ***It isn't what's wanted, it's what is. All compilers are partly broken, yes? ***Microsoft fixes theirs faster because they're a bigger corporation, Yes? Or is it a law unto itself immune to outside judgment? ***GCC will improve. It will go from broken to broken-differently. ***It is (truthfully) believed that the subsequent implementations are broken less where they were broken before, and increases in breakage come in part from new technology (HT/MP/SSE/etc) ***A summary of the brokenness in 2.96 addressed in 3.4 is what's wanted. what you had looks like it should have worked. But the compiler seems to have an internal problem. If "{0}" works, then "{((MsgIdT)0)}" should also work. *** We agree. When theory meets reality, theory ALWAYS wins, and reality NEVER cares. I'd suggest creating a minimal file which reproduces the problem and filing an error report. In the meantime, I'd change the source to look like this: *** I'll have to do this: experiment my way around this newer, differently-broken compiler. ***Why? Because the summary-of-changes I seek appears to not have been created. >>Why the compiler decided we can't initialize an auto union with a >>type-cast scalar when we used to do so with no problem >>*should* have been recorded somewhere, if so, that document >>*should* give me other clues about what's making the 3.x compiler >>barf on this 2.96-happy code. I find the "-D_GCC_" to be highly suspicious for these reasons (at least) **Trimming the compiler option line is one thing I'll try. I wouldn't duplicate the message id like that, ***It allows testing the message ID whether you've got a pointer-to-the-union OR a pointer-to-a-subordinate-structure. The message you reported sounds like an internal error. ***The "can't find register to spill" came from other code. Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated

1 0

Re: [CentOS] upgrade problem
by Brian T. Brunner 20 Sep '05

20 Sep '05

My mailer has no quoted-text-prefix capability. ***embedded replies*** Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 >>> mike.mccarty(a)sbcglobal.net 09/20/05 11:16AM >>> Brian T. Brunner wrote: > My desire is NOT to remain rooted in the past. Hence > my interest in changing my code to meet the compiler of today. You should not use what some compiler accepts as your guide for writing code. You should use the Language Definition. ***pedantic*** I have to get the compiler to compile the code, the language definition won't do that. ***pragmatic*** I'm here to drain the swamp, not analyze the alligators. ***overall** How did the compilers change in what they tolerate. See below. > If I'm killing the 3.x compiler with code that 2.96 accepted, > it ought to be from well-known (by now) reasons like > Also, the C Language did not recently change. ***the compiler is the cop, the language definition is the law*** > Known problem and solution: (amended to clarify my mumbling, for which I apologize) > > We have typedef char MsgIdT > We use a message that is a union comprising a > MsgIdT MsgId; > and the > 117 message structures, (each of which has a MsgIdT MsgId as the first element); > we had a null message number macro #define MSG_NULL ((MsgIdT)0) > under 2.96 we could allocate a message union, and initialize it with > union msgstructT msg = {MSG_NULL}; // the 3.x compiler barfs on this but 2.96 didn't care > so now we say > union msgstructT msg = {0}; // the 3.x compiler is happy with this. So is 2.96 > > Why the compiler decided we can't initialize an auto union with a > type-cast scalar when we used to do so with no problem > *should* have been recorded somewhere, if so, that document > *should* give me other clues about what's making the 3.x compiler > barf on this 2.96-happy code. Your guide to writing proper code should not be what a compiler accepts, but what the language definition specifies. ***the compiler creates the marketable product, that's what I have to please.*** ***As a theorist, the C and C++ language definitions (law) are fascinating*** ***As an engineer porting 2.96 code to a 3.4 compiler, the (get this)*** ***LANGUAGE DEFINITION IS UTTERLY IRRELEVANT*** ***I've met plenty of cops to whom the law is irrelevant, we do things his way or there's trouble.*** ***the compiler is my cop. He's the one I have to please.*** gcc --ansi --pedantic -Wall to get maximum conformance and portability of my code. ***this is what I inherited: ***COMPILER_OPTIONS = -D_GCC_ -g -g3 -pipe -march=i586 -fstack-check -fcse-follow-jumps -fexpensive-optimizations -fcse-skip-blocks -fforce-mem -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fshort-enums -fstrength-reduce -fthread-jumps -fverbose-asm -O2 -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wconversion -Winline -Wpointer-arith -Wshadow -Wwrite-strings *** probably more than I need, I might take a (sub) project of stripping this list down to just those needed to get in-spec performance of the object code. ** neither ansi nor pedantic are currently in the list of options. should be reported as a defect. ***My mission is to get the code running under the new compiler. The code pleased the 2.96 compiler. Things worked! ***Now, the new compiler is really displeased with my code. ***I'd like to know what the differences are in the two compiler versions relative to what (possibly) non-conforming code is no longer tolerated. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated

2 1

Re: [CentOS] upgrade problem
by Brian T. Brunner 20 Sep '05

20 Sep '05

Currently we have RH7.3 with compiler gcc 2.96.x My mission, should I choose to accept it, involves moving our embedded application to CentOS 4.1 with gcc 3.x Problem is that about 1/2 million lines of code that gcc 2.96 accepts gives fatal fits to the gcc 3.x compiler from CentOS 4.1 I don't know how many fatal fits, as some disguise others etc. "Can't find register to spill" is a common exit-barf from gcc 3.x. What I'd like to find is a comparison of gcc 2.96.x to 3.x from the perspective of porting something from RH7.x to CentOS/RHEL 4.x What I did was make a fresh install of CentOS 4.1 and then load the source code for the application and try to make. What gcc 2.96 compiler assumed about the underlying OS, and what gcc 3.x assumes about the underlying OS, may be relatively skew. Whether any of the application code assumes a 2.96 set of assumptions, where this set of assumptions is broken under 3.x, is unknown (and is the kind of detail I'd like to see in the above-hinted-at porting guide). Links? Pointers? Tips? Clues? Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated

4 3

Re: [CentOS] OT - where to buy linux HW
by Doug Ferrell 20 Sep '05

20 Sep '05

I usually pick up dell severs cheap (check out the wall street journal for discounts) and have had all flavors running on them. Just Installed CentOS _BQ on one the other day and it's working like a champ. ...DOUG

1 0

Re: [CentOS] upgrade problem
by Brian T. Brunner 20 Sep '05

20 Sep '05

My desire is NOT to remain rooted in the past. Hence my interest in changing my code to meet the compiler of today. If I'm killing the 3.x compiler with code that 2.96 accepted, it ought to be from well-known (by now) reasons like (I'm making this up for an example) "memset used to be a routine but now it is a macro ..:. don't give it macro parameters." Known problem and solution: We use a message that is a union comprising a char MsgIdT and the 117 message structures, (each of which has a char MsgIdT as the first element); we had a null message number macro #define MSG_NULL ((MsgIdT)0) under 2.96 we could allocate a message union, and initialize it with union msgstructT msg = {MSG_NULL}; // the 3.x compiler barfs on this so now we say union msgstructT msg = {0}; // the 3.x compiler is happy with this. Why the compiler decided we can't initialize an auto union with a type-cast scalar when we used to do so with no problem *should* have been recorded somewhere, if so, that document *should* give me other clues about what's making the 3.x compiler barf on this 2.96-happy code. Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 >>> mike.mccarty(a)sbcglobal.net 09/19/05 05:39PM >>> Brian T. Brunner wrote: > Currently we have RH7.3 with compiler gcc 2.96.x > > My mission, should I choose to accept it, involves moving > our embedded application to CentOS 4.1 with gcc 3.x > > Problem is that about 1/2 million lines of code that gcc 2.96 > accepts gives fatal fits to the gcc 3.x compiler from CentOS 4.1 > > I don't know how many fatal fits, as some disguise others etc. > "Can't find register to spill" is a common exit-barf from gcc 3.x. Frankly, that sounds like an internal error in the compiler. Either the register allocater, the temporary creator, or the register spiller seems to be failing to do its job. This does not appear to me to be a porting problem, but a defective compiler. Is there any reason you must use the later compiler? [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated

2 1

Repositories
by Sam Drinkard 20 Sep '05

20 Sep '05

Being very new to yum, I have to ask the question, where do you locate the various yum repositories, and once you know where they are, is there a standard configure file per-se, that needs to be added to the yum.conf. Any pointers appreciated. Sam -- Snowman

6 6

Re: [CentOS] upgrade problem
by Brian T. Brunner 20 Sep '05

20 Sep '05

As to whether C or C++ changed between when 2.96 came out and Centos 4.1, there is another conundrum: Does the compiler define the language, or vice versa? Acknowledging the human factor in the implementation of the compiler, we ought to stipulate that both 2.96 and 3.x are B - R - O - K - E - N; the question I've asked is in what way is 3.x different in how it's broken compared to 2.96 2.96 allowed some things not strictly kosher under the C/C++ language definitions, some of these are no longer winked at by the 3.x compiler. I'm looking for a pragmatic answer, not a theorist answer, about the differences between 2.96 and 3.x. Since nothing is coming to mind among the Notable Ones here, I'll take my question to the compiler groups... Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 >>> mike.mccarty(a)sbcglobal.net 09/20/05 10:33AM >>> Brian T. Brunner wrote: > This advice completely misses my point. I think you missed the point. >>What I'd like to find is a comparison of gcc 2.96.x to 3.x from the >>perspective of porting something from RH7.x to CentOS/RHEL 4.x > > > I don't want my code to stay rooted in The Dead Past. > I want to know what kinds of things changed to give me clues > how to CHANGE MY CODE TO FIT TODAY. The C programming language did not change. The most likely reason your code won't compile is that the compiler is B-R-O-K-E-N. [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated

1 0

Re: [CentOS] upgrade problem
by Brian T. Brunner 20 Sep '05

20 Sep '05

This advice completely misses my point. > What I'd like to find is a comparison of gcc 2.96.x to 3.x from the > perspective of porting something from RH7.x to CentOS/RHEL 4.x I don't want my code to stay rooted in The Dead Past. I want to know what kinds of things changed to give me clues how to CHANGE MY CODE TO FIT TODAY. Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 Brian Brunner brian.t.brunner(a)gai-tronics.com (610)796-5838 >>> mailing-lists(a)hughesjr.com 09/19/05 04:46PM >>> On Mon, 2005-09-19 at 11:53 -0700, Brian T. Brunner wrote: > Currently we have RH7.3 with compiler gcc 2.96.x > > My mission, should I choose to accept it, involves moving > our embedded application to CentOS 4.1 with gcc 3.x > > Problem is that about 1/2 million lines of code that gcc 2.96 > accepts gives fatal fits to the gcc 3.x compiler from CentOS 4.1 > > I don't know how many fatal fits, as some disguise others etc. > "Can't find register to spill" is a common exit-barf from gcc 3.x. > > What I'd like to find is a comparison of gcc 2.96.x to 3.x from the > perspective of porting something from RH7.x to CentOS/RHEL 4.x > > What I did was make a fresh install of CentOS 4.1 and then load > the source code for the application and try to make. What gcc 2.96 > compiler assumed about the underlying OS, and what gcc 3.x > assumes about the underlying OS, may be relatively skew. Whether > any of the application code assumes a 2.96 set of assumptions, where > this set of assumptions is broken under 3.x, is unknown (and is the > kind of detail I'd like to see in the above-hinted-at porting guide). > > Links? Pointers? Tips? Clues? Brian, There is a compat-libstdc++-296-2.96-132.7.2 ... so you might be able to install that and run your applications. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss