On 05/08/2015 03:47 PM, Erik Schnetter wrote:
> On Fri, May 8, 2015 at 8:41 AM, Bruno Coutinho Mundim <[email protected]>
> wrote:
>
>> On 05/06/2015 04:26 AM, Erik Schnetter wrote:
>>> On Tue, May 5, 2015 at 8:05 PM, Bruno Coutinho Mundim <
>> [email protected]>
>>> wrote:
>>>
>>>> Hi Frank:
>>>>
>>>> On 05/05/2015 06:55 PM, Frank Loeffler wrote:
>>>>> Hi,
>>>>>
>>>>> Doesn't this patch always set BOOST_*_DIRS to some multi-arch
>>>>> directory (if gcc is found), even if it was installed in a standard
>>>>> location (/usr or /usr/local)? Shouldn't it only set these if a
>>>>> multi-arch directory is actually found?
>>>>>
>>>> I see your point. I updated the patch with Erik's changes and
>>>> add ${BOOST_DIR}/lib. However I don't see the reason to single out
>>>> /usr and /usr/local to do nothing with respect to setting BOOST_*_DIRS
>>>> as it was before. Do you know the rationale for that?
>>>>
>>>
>>> /usr and /usr/local are system directories. That means (a) they are
>>> searched by default, and (b) they contain many libraries, possibly ones
>>> that we don't want. If we use Boost from /usr/lib, and Boost were to add
>>> /usr/lib to the search path, and if /usr/lib also contains HDF5, but we
>>> want to use our own HDF5 library instead, then using Boost may cause the
>>> linker to pick up HDF5 from /usr/lib instead of our own version. Thus we
>>> don't add standard library paths to the search path, neither for include
>>> nor for lib directories.
>>>
>>> -erik
>>>
>>
>> Thanks for pointing this out. It seems quite tricky. I have two
>> comments with this regard:
>>
>> 1) Wouldn't the -I<dir> option passed to the preprocessor guarantee
>> that the system directories are searched last? The man page of cpp
>> (preprocessor used by all simfactory optionlists) states the following:
>>
>> "
>> Directories named by -I are searched before the standard system
>> include directories. If the directory dir is a standard system
>> include directory, the option is ignored to ensure that the default
>> search order for system directories and the special treatment of
>> system headers are not defeated .
>> "
>>
>> That would make the following flesh script unnecessary, no?
>>
>
> If you use GNU cpp, and if you use a version that is recent enough.
I see.
Note
> that we preprocess using the compiler, not with cpp. The compiler most
> likely doesn't call cpp.
>
Some parts of the build does seem to use cpp directly. I suspect this
happens only for fortran files:
...
cpp -M -traditional -fopenmp -Wall
-I"/home/bruno/tmp/ET_git_dev/Cactus/arrangements/LSUThorns/SummationByParts/src"
...
-DFCODE -DF90CODE
/home/bruno/tmp/ET_git_dev/Cactus/arrangements/LSUThorns/SummationByParts/src/Poisoning.F90
> Poisoning.F90.d
...
>
>> ${CCTK_HOME}/lib/sbin/strip-incdirs.sh
>>
>> also that script doesn't include all system directories. We could
>> query cpp for the list of system directories if we really don't
>> trust it will be searched last as follows:
>>
>> $ cpp -x c++ -v
>> Using built-in specs.
>> COLLECT_GCC=cpp
>> Target: x86_64-linux-gnu
>> ...
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/include/c++/4.8
>> /usr/include/x86_64-linux-gnu/c++/4.8
>> /usr/include/c++/4.8/backward
>> /usr/lib/gcc/x86_64-linux-gnu/4.8/include
>> /usr/local/include
>> /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
>> /usr/include/x86_64-linux-gnu
>> /usr/include
>> End of search list.
>>
>>
>> then parse these paths and add to a list in strip-incdirs.sh.
>> An extra script would then add them all at the end of the command line.
>>
>> 2) On the other hand when searching for library directories we do have
>> to set the order explicitly to avoid the problem you mentioned, and
>> that's the idea behind the script
>>
>> ${CCTK_HOME}/lib/sbin/strip-libdirs.sh
>>
>> a -L/usr/lib before the other external libraries settings could pick
>> the system library instead of our settings, as you mentioned. Note
>> however that that script doesn't strip all search directories, which
>> might be different in different systems. Why not update that script
>> to make a complete directory list based on the output of ld:
>>
>> $ ld --verbose | grep SEARCH_DIR
>> SEARCH_DIR("/usr/x86_64-linux-gnu/lib64");
>> SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu");
>> SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib/x86_64-linux-gnu");
>> SEARCH_DIR("=/lib64"); SEARCH_DIR("=/usr/lib/x86_64-linux-gnu");
>> SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib");
>> SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");
>>
>
> On my system:
>
> $ ld --verbose
>
> ld: unknown option: --verbose
>
> That's OS X. Cray, AIX will also have their own ld implementation, and
> obtaining the standard library paths is difficult.
>
I am wondering if there is no POSIX solution to this problem.
> Now said that, I am really puzzled why the system hdf5 libraries
>> were not found in the first place, which motivated me to set this
>> multiarch library path in the HDF5 and Boost thorns. As you can see
>> from the output of ld above, /usr/lib/x86_64-linux-gnu is part of the
>> directories searched and my patch would be unnecessary. Any idea what
>> could be broken?
>>
>
> Cactus doesn't use ld to look for the libraries, it looks in a certain set
> of paths. x86_64-linux-gnu is not among them.
>
Is this default system directories hard coded somewhere in the flesh?
or is it left to the compiler to decide?
Thanks,
Bruno.
> -erik
>
> Thanks,
>> Bruno.
>>
>>
>>
>>
>>
>>> Thanks,
>>>> Bruno.
>>>>
>>>>> Frank
>>>>>
>>>>> On Tue, May 05, 2015 at 04:34:27PM +0000, [email protected] wrote:
>>>>>> User: bmundim
>>>>>> Date: 2015/05/05 11:34 AM
>>>>>>
>>>>>> Modified:
>>>>>> /trunk/
>>>>>> configure.sh
>>>>>>
>>>>>> Log:
>>>>>> Define multiarch library directory.
>>>>>>
>>>>>> See discussions at https://trac.einsteintoolkit.org/ticket/1769
>>>>>>
>>>>>> File Changes:
>>>>>>
>>>>>> Directory: /trunk/
>>>>>> ==================
>>>>>>
>>>>>> File [modified]: configure.sh
>>>>>> Delta lines: +11 -1
>>>>>> ===================================================================
>>>>>> --- trunk/configure.sh 2014-05-29 20:47:04 UTC (rev 6)
>>>>>> +++ trunk/configure.sh 2015-05-05 16:34:26 UTC (rev 7)
>>>>>> @@ -151,9 +151,19 @@
>>>>>> # Configure Cactus
>>>>>>
>>>>
>> ################################################################################
>>>>>>
>>>>>> +# Set library directory name for machine architecture:
>>>>>> +gcc -dumpversion > /dev/null 2>&1
>>>>>> +
>>>>>> +if [ $? -eq 0 ]; then
>>>>>> + MACHINE=${MACHINE:=`gcc -dumpmachine`}
>>>>>> +else
>>>>>> + MACHINE=${MACHINE:=""}
>>>>>> +fi
>>>>>> +
>>>>>> # Set options
>>>>>> if [ "${BOOST_DIR}" = '/usr' -o "${BOOST_DIR}" = '/usr/local' ]; then
>>>>>> - : # do nothing
>>>>>> + BOOST_INC_DIRS="${BOOST_DIR}/include"
>>>>>> + BOOST_LIB_DIRS="${BOOST_DIR}/lib/${MACHINE}"
>>>>>> else
>>>>>> BOOST_INC_DIRS="${BOOST_DIR}/include"
>>>>>> if [ -d ${BOOST_DIR}/lib64 ]; then
>>>>>>
>>>>>> _______________________________________________
>>>>>> Commits mailing list
>>>>>> [email protected]
>>>>>> http://cactuscode.org/mailman/listinfo/commits
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> [email protected]
>>>>>> http://cactuscode.org/mailman/listinfo/users
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [email protected]
>>>> http://cactuscode.org/mailman/listinfo/users
>>>>
>>>
>>>
>>>
>>
>>
>
>
_______________________________________________
Users mailing list
[email protected]
http://cactuscode.org/mailman/listinfo/users
