[opensuse] problems building perl 5.14.2 or 5.16.0 using RPMBUILD, build from tar or perlbrew (a cpan util)
I run into the same problems building 5.16.0 whether I run from perlbrew or rpmbuild. I'm sorta wondering how perl is built for the distribution if I am having such a hard time rebuilding it or building it on a suse system. This points to a problem I mentioned a few years back with the build system. If something only builds on a remote build system -- you end up with a proprietary build system that can't easily be reproduced to rebuild products. The whole idea of open source was to be able to fix things in it that were broken by building your own. If I can't do that -- easily -- on my own system, I'm beginning to wonder how well that fits the definition of 'open source'. Right now, I have 2 main failure modes depending on how I build. If I build from a fresh login -- a default config: sh Configure -de make make test That doesn't work -- Configure gets confused and drops in 'null' for programs (like make, rm, and maybe a few others). If I build from env -i (shell-dash/sh/bash) -- Configure will build, but the C compiler (cc or gcc) is broken: make `sh cflags "optimize='-O2'" perlmini.o` -DPERL_IS_MINIPERL -DPERL_EXTERNAL_GLOB perlmini.c CCCMD = gcc -DPERL_CORE -c -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O2 -Wall -ansi -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings gcc: error trying to exec 'cc1': execvp: No such file or directory cat >lin.c #include <stdio.h> main() { printf ("Hello World\n"); } $ gcc lin.c gcc: error trying to exec 'cc1': execvp: No such file or directory $ set IFS=' ' LINENO='' OLDPWD='/home/tools/perl' OPTIND='1' PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' PPID='27167' PS1='$ ' PS2='> ' PS4='+ ' PWD='/home/tools/perl/perl-5.16.0' _='lin.c' My path looks normal -- so what's the problem -- why can't I run the C compiler? Who knows why a normal login run of configure ends up with this: End of configuration questions. Stripping down executable paths... Creating config.sh... ./Configure: line 22748: -f: command not found ./Configure: line 23838: -f: command not found ./Configure: line 23844: -f: command not found Doing variable substitutions on .SH files... Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Not re-extracting config.h Extracting makedepend (with variable substitutions) Extracting Makefile (with variable substitutions) ./Makefile.SH: line 1600: -f: command not found Extracting myconfig (with variable substitutions) Extracting pod/Makefile (with variable substitutions) Extracting Policy.sh (with variable substitutions) ./Policy_sh.SH: line 147: -d: command not found ./Policy_sh.SH: line 174: -d: command not found Extracting runtests (with variable substitutions) Extracting utils/Makefile (with variable substitutions) Extracting x2p/cflags (with variable substitutions) Extracting x2p/Makefile (with variable substitutions) Run depend now? [y] ./Configure: line 23924: depend: command not found ./Configure: line 23937: -f: command not found ./Configure: line 23947: -f: command not found ./Configure: line 23953: -f: command not found ./Configure: line 23954: -rf: command not found I asked on the perl list, and they are confounded. FWIW,,, zypper ve, shows all dependencies are verified -- that my system is 'coherent'... So won't this build? (Have had problems rebuilding samba as well, so I don't think it is just perl). Building 5.14.2 --- fails in a different but consistent way -- one of the files processed when building a ".xs" file from a .c file puts a bogus "#line file" line in that is missing the line number.... Ideas? Time to get a new distro?....(that would suck!).... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Linda Walsh (suse@tlinx.org) [20120623 09:28]:
gcc: error trying to exec 'cc1': execvp: No such file or directory cat >lin.c
What's the output of »gcc --verbose --version« ? And what's the output of »rpm -qa | grep -F gcc«? Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Philipp Thomas wrote:
* Linda Walsh (suse@tlinx.org) [20120623 09:28]:
gcc: error trying to exec 'cc1': execvp: No such file or directory cat >lin.c
What's the output of »gcc --verbose --version« ? And what's the output of »rpm -qa | grep -F gcc«?
Philipp
When I can reproduce the error (from a fresh login the above doesn't happen only from env -i sh or env -i dash (but from a fresh login, Configure doesn't work correctly ...) I get sh-4.2$ gcc --verbose --version Using built-in specs. COLLECT_GCC=gcc gcc (SUSE Linux) 4.6.2 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.6 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.6 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.6.2 (SUSE Linux) COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' cc1 -quiet -v -iprefix ../lib64/gcc/x86_64-suse-linux/4.6/ help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --version -o /tmp/ccggVtI6.s gcc: error trying to exec 'cc1': execvp: No such file or directory rpm output: sh-4.2$ rpm -qa |grep -F gcc gcc-c++-4.6-15.1.3.x86_64 libgcc46-32bit-4.6.2_20111026-1.1.4.x86_64 libgcc46-4.6.2_20111026-1.1.4.x86_64 cross-ia64-gcc-icecream-backend-4.6.2_20111026-1.1.2.x86_64 gcc46-c++-4.6.2_20111026-1.1.4.x86_64 gcc46-4.6.2_20111026-1.1.4.x86_64 gcc46-32bit-4.6.2_20111026-1.1.4.x86_64 gcc46-info-4.6.2_20111026-1.1.4.noarch gcc-4.6-15.1.3.x86_64 gcc-32bit-4.6-15.1.3.x86_64 gcc-info-4.6-15.1.3.x86_64 libgcc46-debuginfo-4.6.2_20111026-1.1.4.x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Mon, 25 Jun 2012, Linda Walsh wrote:
gcc: error trying to exec 'cc1': execvp: No such file or directory
rpm output:
sh-4.2$ rpm -qa |grep -F gcc gcc-c++-4.6-15.1.3.x86_64 libgcc46-32bit-4.6.2_20111026-1.1.4.x86_64 libgcc46-4.6.2_20111026-1.1.4.x86_64 cross-ia64-gcc-icecream-backend-4.6.2_20111026-1.1.2.x86_64 gcc46-c++-4.6.2_20111026-1.1.4.x86_64 gcc46-4.6.2_20111026-1.1.4.x86_64 gcc46-32bit-4.6.2_20111026-1.1.4.x86_64 gcc46-info-4.6.2_20111026-1.1.4.noarch gcc-4.6-15.1.3.x86_64 gcc-32bit-4.6-15.1.3.x86_64 gcc-info-4.6-15.1.3.x86_64 libgcc46-debuginfo-4.6.2_20111026-1.1.4.x86_64
zypper in cpp46 HTH, -dnh -- CPAN is a medium because anything well done is rare." -- (mis)quoting Fred Allen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* David Haller (dnh@opensuse.org) [20120625 21:38]:
zypper in cpp46
As (mostly :) always David is dead on target. I didn't see that it was missing from the package list. One more reason to strongly advise the use of 'osc build' to properly set up the build environment. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Tue, 26 Jun 2012, Philipp Thomas wrote:
* David Haller (dnh@opensuse.org) [20120625 21:38]:
zypper in cpp46
As (mostly :) always David is dead on target.
*hrhrhrh* :)) I think: "usually", hopefully "mostly", but not definitely "always". But I do make (bad) mistakes sometimes and not every hunch is right ;) Um. If I'm real short (like "zypper in cpp46") or really explicit, explaining a lot, I'm (then) rather sure and usually right. Inbetween, you should check more like normal. But you should _always_ check what someone tells you anyway! Ok, in this case, a 'zypper in cpp46' should _not do any_ harm whatsoever, even if it were dead wrong ;)
I didn't see that it was missing from the package list. One more reason to strongly advise the use of 'osc build' to properly set up the build environment.
Well, spotting that "'cc1' is missing? What package _does_ that belong to?" problem does come from years of experience of wrangling and experimenting on stuff _by hand_ (gcc, make, autotools, etc. pp)... It's what you "notice" when reading a log ... If you've never come across that (or a similar) message, you won't notice it as probable as someone who has wrangled with errors like that ;) Or, probably, you were just tired or looking for something else while reading that log (I know the phenomenon, you look for error-type A and miss the blatant, obvious cause, error-type B. BTDT often enough (I usually "get" it on the 3rd run or so that I'm missing something... Unless my experience kicks me "you dumbass!" before that ;))) Using osc/build for too long makes you lazy, I can feel it already, that "rpmlint will catch it"-feeling ;) For anyone not wanting to know how gcc actually "does it's thing", I concur to Philipp and advise to use osc, which is easier than it looks. After creating an OBS account (so you can use the openSUSE repos (?), you may want to change in your ~/.oscrc: ==== ~/.oscrc ==== [general] apiurl = https://api.opensuse.org # su-wrapper from su to sudo su-wrapper = sudo ==== (by creating a /etc/sodoers entry like ==== /etc/sudoers ### edit with visudo, setting e.g. EDITOR=mcedit visudo ==== YOUR_USER localhost=(root) NOPASSWD:/usr/bin/build ==== which might be tuned for more safety, I use above, as this is an up-to-date, paranoically firewalled, one-user box behind a firewalling router... If in doubt, stay with the default 'su -c'. Set your build-root to taste, I have e.g. ==== ~/.oscrc === # still in [general] section build-root = /data/build/%(repo)s-%(arch)s-root ==== default is '/var/tmp/build/%(repo)...something' IIRC and then add your user info: ==== ~/.oscrc === [https://api.opensuse.org] user=YOUR_OBS_USER pass=YOUR_OBS_PASSWD ### dnh: I think this gets updated automatically, you'll be asked for ### dnh: "trust" once you need a project trusted_prj=openSUSE:Factory openSUSE:12.1 ==== Linda, feel free to ask on opensuse-buildservice (rather specific to OBS) or opensuse-programming (very low traffic, no worries ;) if you have further questions. Crap. I forgot where I got my oscrc-template from. Wasn't a package apparently. HTH, -dnh -- "Sexual harrassment in designated areas only" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Linda Walsh (suse@tlinx.org) [20120625 20:28]:
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' cc1 -quiet -v -iprefix ../lib64/gcc/x86_64-suse-linux/4.6/ help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --version -o /tmp/ccggVtI6.s gcc: error trying to exec 'cc1': execvp: No such file or directory
No wonder! Something like COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.6/ is missing in the output so it's no wonder the compiler driver doesn't find the languge specific compilers which reside in a version specific directory. Which version of SuSE is this, I assume 12.1? Is this the gcc that comes with that distribution? Why don't you use 'osc build' which will build the package locally but fetches all that's needed from the obs? Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Philipp Thomas wrote:
* Linda Walsh (suse@tlinx.org) [20120625 20:28]:
COLLECT_GCC_OPTIONS='-v' '--version' '-mtune=generic' '-march=x86-64' cc1 -quiet -v -iprefix ../lib64/gcc/x86_64-suse-linux/4.6/ help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --version -o /tmp/ccggVtI6.s gcc: error trying to exec 'cc1': execvp: No such file or directory
No wonder! Something like COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.6/ is missing in the output so it's no wonder the compiler driver doesn't find the languge specific compilers which reside in a version specific directory. Which version of SuSE is this, I assume 12.1? Is this the gcc that comes with that distribution?
Why don't you use 'osc build' which will build the package locally but fetches all that's needed from the obs?
Philipp
---- Why doesn't the compiler look where it needs to when it is run? Seems like using a special build system to get around a GCC bug is missing the point. What variables is GCC not setting so it can call it's "cc1" phase"? My PATH is set ok, but we never used to have to set internal paths for compilers for them to work. Seriously -- this is a good reason NOT to build on obs -- because things like this don't get discovered. You didn't see Ritchie using obs when he build "Hello World" -- But at that point I couldn't even write "Hello World " and have it work -- that's pretty bad. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
[please no crossposting and a reply to the list is sufficient]] * Linda Walsh (suse@tlinx.org) [20120626 19:24]:
Philipp Thomas wrote:
Why doesn't the compiler look where it needs to when it is run?
It would if you had installed all neccessary parts. But as cpp46 is missing, you won't succeed
Seems like using a special build system to get around a GCC bug is missing the point.
There is no GCC bug, just PEBKAC. Obs a) makes sure you build in a defined environment and b) resolves all requirements if stated correctly.
What variables is GCC not setting so it can call it's "cc1" phase"?
It's not a "phase" but the actual C compiler. The gcc binary is just a driver that calls the right compiler for the sources given with the right flags and afterwards passes the neccessay internal libraries to the linker.
My PATH is set ok, but we never used to have to set internal paths for compilers for them to work.
You were just missing a package.
You didn't see Ritchie using obs when he build "Hello World" -- But at that point I couldn't even write "Hello World " and have it work -- that's pretty bad.
It's like building a house: if you are missing essential pieces you won't be able to complete it. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Philipp Thomas wrote:
[please no crossposting and a reply to the list is sufficient]]
* Linda Walsh (suse@tlinx.org) [20120626 19:24]:
Philipp Thomas wrote:
Why doesn't the compiler look where it needs to when it is run?
It would if you had installed all neccessary parts. But as cpp46 is missing, you won't succeed
Seems like using a special build system to get around a GCC bug is missing the point.
There is no GCC bug, just PEBKAC. Obs a) makes sure you build in a defined environment and b) resolves all requirements if stated correctly.
What variables is GCC not setting so it can call it's "cc1" phase"?
It's not a "phase" but the actual C compiler. The gcc binary is just a driver that calls the right compiler for the sources given with the right flags and afterwards passes the neccessay internal libraries to the linker.
When I login fresh it calls a different compiler than when I start with a fresh environment??
My PATH is set ok, but we never used to have to set internal paths for compilers for them to work.
You were just missing a package.
??? Why does it work in the more normal case? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Philipp Thomas wrote:
[please no crossposting and a reply to the list is sufficient]]
* Linda Walsh (suse@tlinx.org) [20120626 19:24]:
Philipp Thomas wrote:
Why doesn't the compiler look where it needs to when it is run?
It would if you had installed all neccessary parts. But as cpp46 is missing, you won't succeed You mean this cpp46: rpm -q cpp46 cpp46-4.6.2_20111026-1.1.4.x86_64 ==== Hmmm rpm -V cpp46
--- It verifies as being there... Where did I say that cpp46 was missing?
Seems like using a special build system to get around a GCC bug is missing the point.
There is no GCC bug, just PEBKAC. Obs a) makes sure you build in a defined environment and b) resolves all requirements if stated correctly.
What is PEBKAC and how is it not a GCC bug? PEBKAC seems to involve you making incorrect assumptions about my build environment. OBS causes problems. RPM makes sure you build with defined prerequisites. The OBS environment is suspect -- since it produces products that can't be rebuilt with normal tools except with itself. Of course last time I tried to use OBS it kept timing out and no one was able to figure out why. It was unable to create projects (and still is as far as I can tell) from the command line... It also didn't work with HTTPS addresses -- only HTTP addresses. I don't care to debug OBS any further.
What variables is GCC not setting so it can call it's "cc1" phase"?
It's not a "phase" but the actual C compiler. The gcc binary is just a driver that calls the right compiler for the sources given with the right flags and afterwards passes the neccessay internal libraries to the linker.
--- Well after the cc1 'compiler' [sic] applies macros and tokenizes the input, into GIMPLE, -- that is passed through a pipe to something called the compiler that works on a generic intermediate format -- then another phase is called the optimizer, which is optional, then there is the back-end which produces the object format your platform needs. It's not very accurate to think of cc1 as a compiler any more than the 'BEGIN' stage in perl.
My PATH is set ok, but we never used to have to set internal paths for compilers for them to work.
You were just missing a package.
---- ???? Doesn't seem to be the case -- I'm not sure where you got that idea.
You didn't see Ritchie using obs when he build "Hello World" -- But at that point I couldn't even write "Hello World " and have it work -- that's pretty bad.
It's like building a house: if you are missing essential pieces you won't be able to complete it.
--- If I am missing essential pieces, why are they only missing when I start with a clean environment? Usually, when pieces are missing, you don't get working behavior more than half the time -- whereas I said it only happens when I call "env -i dash " make (cc1 missing). If I start with a dirty environment, it works -- do the pieces magically appear with a dirty envionment, but disappear when you only start with basics like PATH? cc1 isn't in the PATH, it's in a lib -- so gcc has to know where to find it -- but it doesn't. How is that not a bug? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/06/12 10:06, Linda Walsh wrote:
What is PEBKAC
Problem Exists Between Keyboard And Chair ;) Bob -- Bob Williams System: Linux 3.1.10-1.13-desktop Distro: openSUSE 12.1 (x86_64) with KDE Development Platform: 4.8.4 (4.8.4) "release 511" Uptime: 18:00pm up 5 days 8:54, 4 users, load average: 0.50, 0.78, 1.62 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Bob Williams wrote:
On 28/06/12 10:06, Linda Walsh wrote:
What is PEBKAC
Problem Exists Between Keyboard And Chair ;)
Bob
Ah...thank you. The previous person seemed to assume I didn't have the correct path (it was a standard path) and/or I didn't have the package cpp46 package installed (I did/do), It was on his assumption that one of those held true that condition PEBKAC = True. Both of his assumptions were FALSE, therefore It seems the original responder jumped to unsupported conclusions and when he arrived, he promptly went into freefall and we haven't seen him since. Weird. Guess it's another good example of not jumping to unsupported conclusions. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday 25 June 2012 11:28:09 Linda Walsh wrote:
Philipp Thomas wrote:
* Linda Walsh (suse@tlinx.org) [20120623 09:28]:
gcc: error trying to exec 'cc1': execvp: No such file or directory
cat >lin.c
What's the output of »gcc --verbose --version« ? And what's the output of »rpm -qa | grep -F gcc«?
Philipp
---- When I can reproduce the error (from a fresh login the above doesn't happen only from env -i sh or env -i dash (but from a fresh login, Configure doesn't work correctly ...)
I don't know what a "fresh login" means, but your gcc problem comes from the env -i, something about $PWD stop doing env -i or env -i dash cd /usr/bin gcc --verbose --version Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday 01 July 2012 04:20:11 Anders Johansson wrote:
On Monday 25 June 2012 11:28:09 Linda Walsh wrote:
Philipp Thomas wrote:
* Linda Walsh (suse@tlinx.org) [20120623 09:28]:
gcc: error trying to exec 'cc1': execvp: No such file or directory
cat >lin.c
What's the output of »gcc --verbose --version« ? And what's the output of »rpm -qa | grep -F gcc«?
Philipp
---- When I can reproduce the error (from a fresh login the above doesn't happen only from env -i sh or env -i dash (but from a fresh login, Configure doesn't work correctly ...)
I don't know what a "fresh login" means, but your gcc problem comes from the env -i, something about $PWD
Actually it seems to be a problem with $PATH, for some reason gcc is not inheriting it, so it looks for its binary with a search path of .
stop doing env -i
This is still true. It is a silly thing
or
env -i dash cd /usr/bin
PATH=/usr/bin:/usr/sbin:/bin export PATH gcc --verbose --version I suspect the point is that the shell variable you get when you do echo $PATH is not a part of the environment and so doesn't get inherited on execve() - if you do env instead of echo $PATH you can see what your inheritable environment looks like. By explicitly doing the export you put it into the environment and so it gets inherited. To sum up: stop doing env -i Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday 01 July 2012 04:56:54 Anders Johansson wrote:
PATH=/usr/bin:/usr/sbin:/bin export PATH
Last response to myself, I promise. Since the shell variable PATH is already set, simply export PATH will also make things work. No need to reset the shell variable if it already has a value Not doing env -i is the simpler solution Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Linda Walsh (suse@tlinx.org) [20120623 09:28]:
That doesn't work -- Configure gets confused and drops in 'null' for programs (like make, rm, and maybe a few others).
Path not set? Programs not installed? Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Philipp Thomas wrote:
* Linda Walsh (suse@tlinx.org) [20120623 09:28]:
That doesn't work -- Configure gets confused and drops in 'null' for programs (like make, rm, and maybe a few others).
Path not set? Programs not installed?
Philipp
Since this was posted after your response, but not to your response, you may have missed it. Philipp Thomas wrote: Regarding program not installed:
It would if you had installed all neccessary parts. But as cpp46 is missing, you won't succeed
You mean this cpp46:
rpm -q cpp46 cpp46-4.6.2_20111026-1.1.4.x86_64 ==== Hmmm rpm -V cpp46
It verifies as being there... Where did I say that cpp46 was missing? Regarding not in path: It works from a login -- just not a clean path set via env -i dash: Ishtar:packages> env -i dash $ set IFS=' ' LINENO='' OPTIND='1' PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' PPID='11854' PS1='$ ' PS2='> ' PS4='+ ' PWD='/home/packages' Notice the path has all the standard parts in it. I assume this means there is a bug in GCC covered up by the build system OBS? As far as having some preset environment -- rpmbuild has that facility -- it's called "pre-reqs"... it makes sure packages needed for build are installed (in fact most OpenSuse RPM's make use of this feature)... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Philipp Thomas wrote:
* Linda Walsh (suse@tlinx.org) [20120623 09:28]:
That doesn't work -- Configure gets confused and drops in 'null' for programs (like make, rm, and maybe a few others).
Path not set? Programs not installed?
Philipp
In fact, I get even more weirdness when I use dash with the -l switch: shtar:/tmp> cat world.c #include <stdio.h> #include <stdlib.h> void main(void) { printf("Hello world\n") ; } ------------------------------------------------------------------------------- Here's w/ default "dirty" (uncontrolled) environment: note. It works. dash -c "test -f a.out && { echo rm a.out;rm a.out ;} ; gcc world.c && a.out" rm a.out Hello world ------------------------------------------------------------------------------- Here's with a clean env: Ishtar:/tmp> rm -f a.out; env -i dash -c "set;gcc world.c && a.out" IFS=' ' LINENO='' OPTIND='1' PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' PPID='18920' PS1='$ ' PS2='> ' PS4='+ ' PWD='/tmp' gcc: error trying to exec 'cc1': execvp: No such file or directory Notice gcc doesn't load cc1. -------------------------------------------------------------------------------- Here's using "-l" with dash": Ishtar:/tmp> rm -f a.out; env -i dash -lc "gcc world.c && a.out" Inconsistency detected by ld.so: dl-lookup.c: 877: _dl_setup_hash: Assertion `(bitmask_nwords & (bitmask_nwords - 1)) == 0' failed! -------------------------------------------------------------------------------- If you want to try with further theories I won't hold your previous assumptions that I'm simply stupid, against you.... I am at LEAST!! 'complexly stupid'. (i.e. when I screw up, it's _usually_ in some rather arcane manner, (though not always))... ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Notice gcc doesn't load cc1.
--------------------------------------------------------------------------------
Here's using "-l" with dash": Ishtar:/tmp> rm -f a.out; env -i dash -lc "gcc world.c && a.out" Inconsistency detected by ld.so: dl-lookup.c: 877: _dl_setup_hash: Assertion `(bitmask_nwords & (bitmask_nwords - 1)) == 0' failed!
--------------------------------------------------------------------------------
If you want to try with further theories I won't hold your previous assumptions that I'm simply stupid, against you.... I am at LEAST!! 'complexly stupid'. (i.e. when I screw up, it's _usually_ in some rather arcane manner, (though not always))...
I told you to ask on the gcc-help@gcc.gnu.org mailing list, did you do that? This is not an openSUSE specific problem so please ask on the upstream list. It's the best place to get answers to your problems. Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Anders Johansson -
Bob Williams -
David Haller -
Linda Walsh -
Philipp Thomas -
Philipp Thomas