I would like to get a list of all versions since some date but excluding versions .../0
But this ...
cleartool find \frdcc_hyb_sw\ -version "{created_since(20190201) && !(version(.../0))}" -print
gives me error:
cleartool: Error: Malformed branch pathname: "\...".
Am I doing somethig wrong or this is simply not possible?
Thank you very much
version(.../0) should reference a branch version, not directly the version number itself, as part of version selector.
The ... is an ellipsis wildcard.
So:
!(version(.../myBranch/0))
Since there is not wildcard for the branch, you might as well remove the version selector, and grep the result to exlude any /0 version.
ct find \frdcc_hyb_sw\ -version "{created_since(20190201)}" -print | grep -v "/0"
Related
After compiling gcc and using it to compile a simple c program:
echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
grep -B4 '^ /usr/include' dummy.log
the result is:
ignoring nonexistent directory "/tools/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/tools/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
but according to Linux From Scratch guide 9.1 in section 6.25 "Verify that the compiler is searching for the correct header files:" the following is expected (ignoring the *linux-gnu paths...):
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed
/usr/include
What's even worse is that
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
is:
SEARCH_DIR("/usr/lib");
but should be:
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
I've tried to add all paths to /etc/ld.so.conf and recompiled gcc pass 2, but nothing changed.
So what exactly determines the SEARCH_DIR entries in an ELF file?
EDIT1: I backtracked and found out that the previous step make -k clean did not finish because it's missing autogen, which is not covered at all in the LFS guide 9.1 it seems.
I restarted LFS 9.1 and followed the instruction with more care, now the output is as expected!
There are two things I did differently:
In my first attempt I ignored the advice on chapter 5 to remove extracted tarballs after each section:
For each package:
Using the tar program, extract the package to be built. In Chapter 5, ensure you are the lfs user when extracting the package.
Change to the directory created when the package was extracted.
Follow the book's instructions for building the package.
Change back to the sources directory.
Delete the extracted source directory unless instructed otherwise.
When I reinstalled the host OS I didn't create it with lfs as first user. Instead I created it with lfshost user and created the user lfs as described in section 4.3
When we start working on a new release we usually put a new label, for example REL2, on all elements with label REL1. This means that in the beginning of developing a new release, these two versions are identical. As the development progress and elements are checked in, REL2 will be moved to a newer version.
At the end of the development, REL2 can differ a lot from REL1.
My question is, how do I get all elements where REL2 are not the same version as REL1?
You would need to look for visible versions which have the REL2 label but not the REL1 label.
cleartool find . -cview -version "{!lbtype(REL1) && lbtype(REL2)} -print
See more examples at "Additional examples of the cleartool find command".
I am trying to implement 'whereis' command in C. But I was able to implement it partially. When I ever I try 'whereis' in Linux shell, lets say for e.g. whereis ls .. I get the following results
$ whereis ls
/bin/ls
/usr/share/man/man1p/ls.1p.gz
/usr/share/man/man1/ls.1.gz
I am able to get the first path using the PATH env.variable. But I have no clue how to find the other two paths. Any pointers how to find those paths.
On Linux (but not on all systems, e.g. Mac OS), whereis searches in $MANPATH (or some other default places) for matching files, which for ls are something like this:
$MANPATH/man(.+)/ls\.\1(\.gz)?
If you really need to know how whereis works, you can simply look at its source....
man whereis (Ubuntu 11.04) mentions the following paths:
/{bin,sbin,etc}
/usr/{lib,bin,old,new,local,games,include,etc,src,man,sbin,X386,TeX,g++-include}
/usr/local/{X386,TeX,X11,include,lib,man,etc,bin,games,emacs}
Another option generally available is which. It will return the fully-qualified path and executable name for the executable. For example:
$ which ls
/usr/bin/ls
It may help you in your whereis endevour and is also useful for portability in scripts to set the executable where it may be located in different places on different distributions:
my_ls=$(which ls 2>/dev/null)
[ -x "$my_ls" ] || {
echo "ls not found"
exit 1
}
I am trying to compile phpcompiler from source using this configure command.
./configure --prefix=/opt/phc-0.3.0.1/ --with-php=/opt/php-5.3.17/
The configure error was,
checking for exit in -lboost_regex-mt... no
checking for exit in -lboost_regex-mt... (cached) no
checking for exit in -lboost_regex... no
checking for exit in -lboost_regex... (cached) no
checking for exit in -lboost_regex... (cached) no
configure: error: Could not link against boost_regex
Thats completely wrong as I have both boost and boost_regex packages installed. Both libs and header files. Then I dug this in the config.log file
configure:17053: g++ -o conftest -g -O2 -L/lib/php5 -L/usr/lib/php5 conftest.cpp /usr/lib/libCrun.so.1 -lphp5 -L/opt/php-5.3.17//lib -R/opt/php-5.3.17//lib -ldl >&5
g++-4.6.real: error: /usr/lib/libCrun.so.1: No such file or directory
g++-4.6.real: error: unrecognized option '-R'
So, for this unrecognized option '-R' error, many -lboost_regex checks were failed!
How can I fix this? is there any file that I can edit to fix it? And why -R is used? I think it would be -L flag.
As your comment indicates that this -R option comes from configure, the following line in m4/php-embed.m4 appears to be the most likely source:
LIBS="-lphp5 -L${PHP_INSTALL_PATH}/lib -R${PHP_INSTALL_PATH}/lib $LIBS"
If you look at configure, all other occurrences of -R will write that as ${wl}-R, where ${wl} will most likely expand to -Wl,. So one way to fix this would be adding the ${wl} before -R in the above line and running autogen.sh to recreate configure.
You may whish to file a bug for this, after checking existing ones.
You can see a similar error (and resolution) in Git 2.23 (Q2 2019) where -R has been removed.
The way of specifying the path to find dynamic libraries at runtime
has been simplified.
The old default to pass -R/path/to/dir has been replaced with the new default to pass -Wl,-rpath,/path/to/dir, which is the more recent GCC uses.
See commit 0f50c8e (17 May 2019) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 51d6c0f, 13 Jun 2019)
Makefile: remove the NO_R_TO_GCC_LINKER flag
Change our default CC_LD_DYNPATH invocation to something GCC likes
these days.
Since the GCC 4.6 release unknown flags haven't been passed through to ld(1). Thus our previous default of CC_LD_DYNPATH=-R would cause an error on modern GCC unless NO_R_TO_GCC_LINKER was set.
Our use of "-R" dates back to 455a7f3 ("More portability.",
2005-09-30, Git v0.99.8a).
Soon after that in bbfc63d ("gcc does not necessarily pass runtime libpath with -R", 2006-12-27, Git v1.5.0-rc1) the NO_R_TO_GCC flag was added, allowing optional use of "-Wl,-rpath=".
Then in f5b904d ("Makefile: Allow CC_LD_DYNPATH to be overriden",
2008-08-16, Git v1.6.1-rc1) the ability to override this flag to something else
entirely was added, as some linkers use neither "-Wl,-rpath," nor "-R".
From what I can tell we should, with the benefit of hindsight, have
made this change back in 2006.
GCC & ld supported this type of invocation back then, or since at least binutils-gdb.git's.
a1ad915dc4 ("[...]Add support for -rpath[...]", 1994-07-20).
Further reading and prior art can be found at:
tsuna/boost.m4 issue 15
Gnome issue 641416
Building cURL passing the -R option to linker
Making a plain "-R" an error seems from reading those reports to have been
introduced in GCC 4.6 released on March 25, 2011, but I couldn't
confirm this with absolute certainty, its release notes are ambiguous
on the subject, and I couldn't be bothered to try to build & bisect it
against GCC 4.5.
I need to build gcc-4.3.4 in a non-standard location (NFS mounted). I configured:
../gcc-4.3.4/configure --prefix={install dir} --with-gmp={install dir} --with-mpfr={install dir} --with-local-prefix={install dir} --disable-shared
I ran make -j1. But I keep getting:
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
In x86_64-unknown-linux-gnu/libgcc/config.log, I can see:
/home/panthdev/apps/gcc-4.3.4-compliant/compiler/objdir/./gcc/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory
libmpfr.so.1 is there in {install dir}/lib. Also if I set LD_LIBRARY_PATH to {install dir}/lib, then it finds the libmpfr.so.1 but config.log starts complaining:
/tmp/cce9YhFK.s: Assembler messages:
/tmp/cce9YhFK.s:16: Error: bad register name `%rbp'
/tmp/cce9YhFK.s:18: Error: bad register name `%rsp'
As I read here you have 32bit binutils where as gcc is trying to do a 64bit build. Make sure your binutils & gcc has the same configuration.
You should maybe try using --with-sysroot instead of --prefix.
In the GCC 4.5.2 configure script (I have that available, but not 4.3.4), at around line 4500 (of 15.5K lines), there is the stanza:
rm -f conftest.$ac_ext
EXEEXT=$ac_cv_exeext
ac_exeext=$EXEEXT
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for suffix of object files" >&5
$as_echo_n "checking for suffix of object files... " >&6; }
if test "${ac_cv_objext+set}" = set; then :
$as_echo_n "(cached) " >&6
else
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
_ACEOF
rm -f conftest.o conftest.obj
if { { ac_try="$ac_compile"
case "(($ac_try" in
*\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
*) ac_try_echo=$ac_try;;
esac
eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
$as_echo "$ac_try_echo"; } >&5
(eval "$ac_compile") 2>&5
ac_status=$?
$as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; then :
for ac_file in conftest.o conftest.obj conftest.*; do
test -f "$ac_file" || continue;
case $ac_file in
*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf | *.dSYM ) ;;
*) ac_cv_objext=`expr "$ac_file" : '.*\.\(.*\)'`
break;;
esac
done
else
$as_echo "$as_me: failed program was:" >&5
sed 's/^/| /' conftest.$ac_ext >&5
{ { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
as_fn_error "cannot compute suffix of object files: cannot compile
See \`config.log' for more details." "$LINENO" 5; }
fi
rm -f conftest.$ac_cv_objext conftest.$ac_ext
fi
Basically, the script is trying to compile 'conftest.c' and trying to find the extension of the object file created - and, for some reason, your compiler is not creating a conftest.o.
This isn't the first test it does on the compiler, so there seems to be something rather odd going on in your environment.
I've built GCC numerous times over the years - on Solaris and MacOS X - and I've always used the --prefix option. That is not the problem. The GMP, MPFR, MPC directories are necessary; the only option you've used that I'm not familiar with is the --with-local-prefix.
Are you specifying the bootstrap compiler somehow? Consider trying your current configure line with the addition of CC=/usr/bin/gcc or something similar, identifying a fully working compiler on your machine. I'm not convinced that'll solve the problem, but there is something funny about the way the compiler is behaving, or about the object file extensions that it produces. I assume you have several GB of spare space on the disk system? You'll need that.
Poking around the 'Installing GCC: Configuration' page, I find:
--with-local-prefix=dirname
Specify the installation directory for local include files. The default is /usr/local. Specify this option if you want the compiler to search directory dirname/include for locally installed header files instead of /usr/local/include.
You should specify --with-local-prefix only if your site has a different convention (not /usr/local) for where to put site-specific files.
The default value for --with-local-prefix is /usr/local regardless of the value of --prefix. Specifying --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.
The purpose of --prefix is to specify where to install GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in another directory which is based on the --prefix value.)
Both the local-prefix include directory and the GCC-prefix include directory are part of GCC's “system include” directories. Although these two directories are not fixed, they need to be searched in the proper order for the correct processing of the include_next directive. The local-prefix include directory is searched before the GCC-prefix include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.
Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed packages' headers are searched. When directory is one of GCC's system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.
GCC automatically searches for ordinary libraries using GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is installed as a system compiler in /usr.
Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the --program-prefix, --program-suffix and --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries (e.g., with LIBRARY_PATH).
The same value can be used for both --with-local-prefix and --prefix provided it is not /usr. This can be used to avoid the default search of /usr/local/include.
Do not specify /usr as the --with-local-prefix! The directory you use for --with-local-prefix must not contain any of the system's standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header file corrections made by the fixincludes script.
Indications are that people who use this option use it based on mistaken ideas of what it is for. People use it as if it specified where to install part of GCC. Perhaps they make this assumption because installing GCC creates the directory.
Are you sure you're using that correctly? You probably are since you have to search to find the option -- ../gcc-4.x.y/configure --help does not mention the option.