missing 32-bit symlinks for readline and fontconfig in x86_64 SLC4
Hi, In the x86_64 build of SL(C)4, it looks like the "final" symbolic links (i.e. /usr/lib/libfontconfig.so and /usr/lib/libreadline.so) are missing for the 32-bit compatibility libraries, see (a) below. Are they intentionally left out or is it just an oversight? If it is just an oversight, would it be possible to add the fix? The missing links make it difficult to build Qt and sqlite in 32-bit mode on 64-bit SL(C)4 machines, which is needed at CERN these days for the newest machines, without some ugly hacks... (The archive libraries also seem to be missing, but that is perhaps less important if the "final" link for the shared libraries could be added.) thanks, Pete (a) lxbuild063> cat /etc/redhat-release Scientific Linux CERN SLC release 4.4 (Beryllium) lxbuild063> uname -a Linux lxbuild063.cern.ch 2.6.9-42.0.8.EL.cernsmp #1 SMP Fri Feb 2 11:50:49 CET 2007 x86_64 x86_64 x86_64 GNU/Linux lxbuild063> ls -l /usr/lib/libfontconfig* lrwxrwxrwx 1 root root 22 Jan 26 13:47 /usr/lib/libfontconfig.so.1 -> libfontconfig.so.1.0.4 -rwxr-xr-x 1 root root 152756 Feb 17 2005 /usr/lib/libfontconfig.so.1.0.4 lxbuild063> ls -l /usr/lib64/libfontconfig* -rw-r--r-- 1 root root 311132 Mar 14 2005 /usr/lib64/libfontconfig.a lrwxrwxrwx 1 root root 22 Jan 26 13:51 /usr/lib64/libfontconfig.so -> libfontconfig.so.1.0.4 lrwxrwxrwx 1 root root 22 Jan 26 13:47 /usr/lib64/libfontconfig.so.1 -> libfontconfig.so.1.0.4 -rwxr-xr-x 1 root root 203888 Mar 14 2005 /usr/lib64/libfontconfig.so.1.0.4 lxbuild063> ls -l /usr/lib/libreadline* lrwxrwxrwx 1 root root 18 Jan 26 14:02 /usr/lib/libreadline.so.4 -> libreadline.so.4.3 -rwxr-xr-x 1 root root 170236 Feb 17 2005 /usr/lib/libreadline.so.4.3 lxbuild063> ls -l /usr/lib64/libreadline* -rw-r--r-- 1 root root 426172 Mar 14 2005 /usr/lib64/libreadline.a lrwxrwxrwx 1 root root 18 Jan 26 13:51 /usr/lib64/libreadline.so -> libreadline.so.4.3 lrwxrwxrwx 1 root root 18 Jan 26 13:46 /usr/lib64/libreadline.so.4 -> libreadline.so.4.3 -rwxr-xr-x 1 root root 229816 Mar 14 2005 /usr/lib64/libreadline.so.4.3 ----- Peter Elmer E-mail: [EMAIL PROTECTED] Phone: +41 (22) 767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland -
Re: missing 32-bit symlinks for readline and fontconfig in x86_64 SLC4
Hi Jan,
On Thu, Jun 07, 2007 at 09:18:15AM +0200, Jan Iven wrote:
> Intentionally in the sense that the RPM that would provide them hasn't
> been installed. Both libfoo.so and libfoo.a are part of the respective
> -devel package, and the 32bit version simply hasn't been installed on
> your machine (lxbuild063):
> $ rpm -qa --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" fontconfig-devel
> fontconfig-devel-2.2.3-7.x86_64
Excellent, thanks. It hadn't occured to me that just this "final"
link was in the -devel package.
Pete
-----
Peter Elmer E-mail: [EMAIL PROTECTED] Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-
Re: gcc 4.1.2 corrupted symbol reporting in errors?
Hi Matthew,
On Tue, Apr 07, 2009 at 03:05:10PM -0500, Matthew Jones wrote:
> I recently installed SL5.2, which generally works well, but gcc is unable
> to
> report the symbols that it is having difficulty compiling...
>
> For example, if I compile the following program:
>
> int main() {
> double d = 1.5;
> e = d + 2;
> }
>
> I get the following:
>
> $ g++ junk.cc
> junk.cc: In function â:
> junk.cc:3: error: â was not declared in this scope
>
I tried it with my (64bit) SL5 machine and do not see the problem:
prompt> cat /etc/redhat-release
Scientific Linux SL release 5.1 (Boron)
prompt> gcc -v
Using built-in specs.
<...>
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
prompt> cat test.cc
int main() {
double d = 1.5;
e = d + 2;
}
prompt> g++ test.cc
test.cc: In function âint main()â:
test.cc:3: error: âeâ was not declared in this scope
Hmm, I suspect you'll see mangled non-printable characters from my
cut/paste (while it looked fine on my screen), which brings me to the other
observation I have: the gcc 4.1.2 build we have made standalone (for use
also on SLC4) machines _does_ have the kind of problem you mention. It is
some bad interaction with the LANG (and terminal?) setting, I think, and
I've not had time to track it down (would be great if someone here has some
suggestion!), but I've found that if I use the workaround:
unsetenv LANG
our gcc 4.1.2 build will print the errors properly. (Normally this is
en_US.UTF-8.)
Pete
-
Peter Elmer E-mail: peter.el...@cern.ch Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-
Re: No, yum, gcc43 not gcc44
Hi Brett,
On Fri, Mar 19, 2010 at 03:47:39PM -0400, Brett Viren wrote:
> This is probably a FAQ but I couldn't find the answer.
>
> I want to install gcc43 packages on SL 5.3 64bit so I do:
>
> yum install gcc43 gcc43-c++ gcc43-gfortran
>
> But yum ignores my command and says that "gcc43 is obsoleted by gcc44"
> and instead installs gcc44! Complete insolence.
>
> How can I tell yum to actually do what I tell it to do?
I can't answer your specific question about yum, but note that the "gcc43"
build in SL5(/RHEL5) was a "preview" build and not meant for "production"
use (however you want to interpret that). In particular they appear to have
dumbed down the libstdc++ version to patch that of the standard system
compiler (gcc412) instead of using the version that comes with gcc4.3 itself.
There were also other oddities about the "gcc43 preview" build, e.g.
difficulties building boost, that caused the LHC experiments to reject it
in favor of our own build(s) of the stock gcc43x. (Subsequent to that decision
the "preview" switched to gcc4.4...)
Pete
-
Peter Elmer E-mail: peter.el...@cern.ch Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-
Re: No, yum, gcc43 not gcc44
Hi Brett,
On Fri, Mar 19, 2010 at 04:27:16PM -0400, Brett Viren wrote:
> Peter Elmer writes:
>
> > There were also other oddities about the "gcc43 preview" build, e.g.
> > difficulties building boost, that caused the LHC experiments to reject it
> > in favor of our own build(s) of the stock gcc43x. (Subsequent to that
> > decision
> > the "preview" switched to gcc4.4...)
>
> Funny you should say this! I'm trying to get gcc43 installed just so I
> can match what is on the nodes on our RACF farm which are heavily
> influenced by ATLAS's needs. However, I see that the stock
> gcc43-4.3.2-7.el5 packages installed. FWIW, we also rely on Boost and
> I've built it (v1.38) with gcc43 and didn't see any problems.
IIRC, it failed to build of the subsequent versions (1.39, IIRC) and
digging through my mail I see that came from something in the libstdc++
compatibility changes they made in the RH "preview" gcc43. The
"gcc43-4.3.2-7.el5" packages you see installed are probably the "preview"
build, I believe, and not "stock" gcc43x (by which I mean what you get if you
download the gcc43{1,2,3,4} source tarball yourself and build it, unhacked to
back up libstdc++).
I'm pretty certain that Atlas isn't using the OS-install of the "preview"
build, but rather a build of the compiler in their own software area, but
you should check with someone from Atlas in case I am missing something.
They were part of the discussions that chose to use the stock GNU gcc43 over
the RHEL5 "preview" gcc43. (I'm 100% certain that CMS isn't using it, but
that doesn't help you... ;-)
Pete
-
Peter Elmer E-mail: peter.el...@cern.ch Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-
Re: Memory footprint on 64bit SL vs. 32bit
Hi, On Apr 28, 2010, at 18:58, Stephan Wiesand wrote: > On Apr 27, 2010, at 00:15 , Brett Viren wrote: >> We recently started running our C++ analysis code on 64bit SL5.3 and >> have been surprised to find the memory usage is about 2x what we are >> used when running it on 32 bits. Comparing a few basic applications >> like sleep(1) show similar memory usage. Others, like sshd, show only a >> 30% size increase (maybe that is subject to configuration differences >> between the two hosts). >> >> I understand that pointers must double in size but the bulk of our >> objects are made of ints and floats and these are 32/64 bit-invariant. >> I found[1] that poorly defined structs containing pointers can bloat >> even on non-pointer data members due the padding needed to keep >> everything properly aligned. It would kind of surprise me if this is >> what is behind what we see. >> >> Does anyone have experience in understanding or maybe even combating >> this increase in a program's memory footprint when going to 64 bits? > > Is it real or virtual memory usage that's increasing beyond expectations? > > Example: glibc's locale handling code will behave quite differently in the > 64-bit case. In 32-bit mode, even virtual address space is a scarce resource, > while in 64-bit mode it isn't. So in the latter case, they simply mmap the > whole file providing the info for the locale in use, while in the former they > use a small address window they slide to the appropriate position. The 64-bit > case is simpler and thus probably less code, more robust and easier to > maintain. And it's probably faster. The 32-bit case uses less *virtual* > memory - but *real* memory usage is about the same, since only those pages > actually read will ever be paged in. This has a dramatic effect on the VSZ of > "hello world in python". It does not on anything that really matters - in > particular, checking the memory footprints of sleep & co. is not very useful > because they're really small compared to typical HEP analysis apps anyway. You can work around the locale thing for any batch application (for which that usually should not matter) by setting the LANG envvar to "C". For a single process this will only be about 50MB, though. The big difference most of us saw was due to the linker forcing shared libraries text/data to align to 2MB, while we have very many very small (<<2MB) libraries. You should see this explicitly if you do a 'pmap' of your process once it is running and has loaded all libraries. You'll see memory sections with no permissions next to those corresponding to libraries. Assuming you aren't using huge memory pages in your application there is a linker option (don't recall off the top of my head the name) in SL5 binutils ld which allows you to reduce this. But what both of these things say is that VSIZE for 64bit is not a very good measure of how much memory an app really needs. Taking out fake accounting things like the two above our estimate is that our (CMS) applications typically only need 20-25% more memory at 64bit relative to 32bit. (From the small code size increase, data type increases for ptr's and whatnot and some increase from overhead/alignment for live objects in the heap..) We are actually preparing some proposals/recommendations about measuring memory use, as in addition to this VSIZE/64bit confusion the introduction of "multicore" applications which share memory also misleads people... Pete
Re: what does this cc1plus error mean?
Hi, On Wed, Jun 25, 2014 at 10:03:54PM -0700, ToddAndMargo wrote: > rpmbuild --rebuild librecad-2.0.4-1.fc20.src.rpm > ... > cc1plus: error: unrecognized command line option > "-std=c++11"cc1plus: error: unrecognized command line option > "-std=c++11" It means that you are rebuilding a package with a compiler version which is too old to support the -std=c++11 flag. (IIRC, it was -std=c++0x for a long time in gcc. I don't recall which gcc version added the new flag, but almost certainly it was later than gcc4.4, for example.) I guess you are backporting this package? Pete ----- Peter Elmer E-mail: peter.el...@cern.ch Phone: +41 (22) 767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland -
Re: what does this cc1plus error mean?
Hi, On Thu, Jun 26, 2014 at 07:42:39AM -0400, Nico Kadel-Garcia wrote: > On Thu, Jun 26, 2014 at 3:14 AM, ToddAndMargo wrote: > > Ye old out-of-date strikes again. Probably will have > > to wait for SL7. Rats! > > > > Thank you for helping me with this, > > Or you could "rpm -U file.src.rpm", edit the resulting .spec file to > manipulate the CFLAGS or other relevant options, and see if that > builds and runs. I've found in backporting that a lot of complex > CFLAGS and other build options are optional tuning for performance or > cross platform compatibility and can be lived without for day to day > compilation. > > But it's hard to tell without actually trying them out. You've got the > source tarball in the SRPM, perhaps you could run some tests with > building from that source tarball, or even tweak that .spec file as > needed? Note that bug-free c++11 functionalities were deployed "by successive iterations" through the last N gcc major releases. Depending on specifically which c++11 features they used it may or may not work with any given compiler version (or with gcc4.4). But perhaps it is worth a try, and you'll be lucky... Pete - Peter Elmer E-mail: peter.el...@cern.ch Phone: +41 (22) 767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland -
