Re: automatic link specification

[Alan Woodland]

AlfC wrote:
> On Sep 17, 5:51 pm, Paul Pluzhnikov <ppluzhnikov-...@charter.net>
> wrote:
>> AlfC <alfredo.cor...@gmail.com> writes:
>>>> Why do you think it's a good idea to be able to do this?
>>> For example, suppose  that you write a header file that uses
>>> boost_filesystem internally, from them on you will need *always* to
>>> compile with the option -lboost_filesystem.
>> Yes. So you add it to your makefile and go on with your life.
> 
>  and then I have to mantain a makefile. ok, one gets used to this.
> 
>>> Let's say that you give your source code that is "script-like" to
>>> someone else
>> I have no clue what a 'script-like source code' is.
> 
> yes you do: a small code with few docen of lines, that does a simple
> task, like renaming files, inspects them, do this and that .
>>
>> If she doesn't have Boost installed, the compilation will give
>> awful errors about compiling.
> 
> at least it will tell what  files are missing.
> 
>> Should gcc be able to also:
>>
>>   #install_boost_if_necessary
>>   #add_correct_include_flags
>>   #add_correct_define_flags
>> to 'automagically' resolve compilation problems as well?
> 
> yes, and make a cup of coffee,
> no, I am talking about some simple task that involves gcc only, after
> all I what looking for something that suggest gcc what to look for,
> something that can be easily switched off or overwritten.
>>
>>> besides it is not standard, why do you think it is a *bad* idea to be
>>> able to do this?
>> It's a bad idea because it hides the fact that you need libboost
>> inside the object file. UNIX users to do not expect this command:
>>
>>   gcc main.o
>>
>> to 'magically' search for any library besides libc.
>>
> so, after all gcc writers accepted that libc should be linked by
> default, basically I am asking for something that by default links to
> certain libraries.
> 
>> It's also a bad idea because UNIX linkers do not use $LIB environment
>> variable to find libraries. If you need libboost.so, and there are
>> 4 different versions installed on the system, which one should the
>> linker pick? The one in /usr/lib may not be the right one.
> 
> I understand, but that is why if implemented it should be as some
> suggestion to the compiler that can be ignored if let say there are
> more than one version of the file.
> Following the example, what if there is more than one version of libc?
> g++ won't cry, will it?
> 
>> It's also a bad idea because users will be confused when main.o
>> needs one version of libboost, but foo.o needs another (possibly
>> incompatible) version.
> 
> beginners are confused anyway.
> 
>> I see this on windows all the time:
>>
>>   link foo.obj bar.lib zork.lib /nodefaultlib:libc.lib
>>     /nodefaultlib:libcmt.lib /nodefaultlib:libcd.lib msvcrt.lib
>>
> I didn't think about that, good point.
> It seems that Windows can do it (see response from Pedro) with its
> problems, gcc just can't.
> ok, I just wanted to make sure I wasn't missing something with gcc.
> Boost people apparently would smile if something like this is
> implemented (see Pedro's link), at least it will simplify their
> Getting Started page.
> Don't get me wrong I still will use g++.
> 
> Thank you very much for your answer, this autolinking may be wasn't a
> great idea after all.
pkg-config largely solves these problem, and runs with more compilers
than just gcc - all you have to do is write mylib.pc that gets passed
around with your library, and knows that your library depends upon
boost/kitchen_sink etc.

Alan