Re: order dependence of -l option

On Thu, Feb 9, 2012 at 17:05, Brad Finney <[EMAIL PROTECTED]> wrote:
>
>
> On 2/8/2012 10:31 PM, Steve Kargl wrote:
>>
>> On Wed, Feb 08, 2012 at 10:19:23PM -0800, Brad Finney wrote:
>>>
>>> Why must the -l<library>  argument be placed after the fortran source
>>> file name when compiling with gfortran.
>>>
>>> The following does not find object codes in libutil.a
>>>
>>> gfortran -Llib -lutil a.f90
>>>
>>> but the following works as expected
>>>
>>> gfortran -Llib a.f90 -lutil
>>>
>>> I understand that the order of -l arguments matter is there are multiple
>>> libraries, but I do not understand why gfortran doesn't just pass the
>>> -l<library>  arguments on to the linker after creating a.o.
>>>
>>
>> a) history
>> b) simplicity
>> c) causality
>> d) all of the above
>>
>> How is the loader to know that _foo in -lutil is
>> needed by the code in a.f90?  Or, are you suggesting
>> that the loader should retain all symbols in -lutil?
>>
> No, I am expecting exactly what happens.  The loader scans for missing
> symbols in library libutil.a which is found either in the working directory
> or the directory identified as lib.  The question is why is the order of the
> -l option critical when most other options can be in any order.  Obviously I
> am missing some key feature/characteristic of the process.  I don't have any
> problem following the "rule", but understanding the why is helpful.  Sorry
> to trouble you with the question.

Wrt. ordering, there's no difference whether you're linking libraries
(.a/.so) or plain object files (.o) (compiling a source file without
the -c option can roughly be seen as first compiling it with the -c
option thus creating an object file, then linking the object file to
the other objects provided on the command line), the same rules apply
(as a result of the GNU linker being single-pass).

-- 
Janne Blomqvist