Bill Dunlap bill at insightful.com
Wed May 17 18:44:11 CEST 2006

On Wed, 17 May 2006, Martin Maechler wrote:

> >>>>> "TL" == Thomas Lumley <tlumley at u.washington.edu>
> >>>>>     on Tue, 16 May 2006 10:15:11 -0700 (PDT) writes:
>     TL> On Tue, 16 May 2006, Prof Brian Ripley wrote:
>     >> It is possible to do things like
>     >>
>     >> env PKG_LIB="-L/opt/foo/lib -lbar" R CMD SHLIB *.c
>     >>
>     >> to add libraries to the creation of a shared object, but
>     >> I have from time to time wondered if we should allow
>     >>
>     >> R CMD SHLIB *.c -L/opt/foo/lib -lbar
>     >>
>     >> not least as users seems to expect it to work.  It looks
>     >> simple to do (at least under Unix) if we pass -L* -l* *.a
>     >> directly to the link command.
>     >>
>     >> Would this be worthwhile?
>     TL> Yes.
>     TL> My only reservation is that users may then expect all
>     TL> compiler/linker flags to work, not just -L/-l
> I had exactly the same thought.
> Maybe Brian's proposal can be extended into
>   "all switches that are not recognized by 'R CMD SHLIB' are
>    passed to compiler / linker  ...."
> hmm, or maybe not, since the question quickly become *which* are
> passed to compiler and which to linker (and which to both ?) ...

I'd rather have SHLIB complain if it sees a -flag
that SHLIB doesn't recognize.  Otherwise we get
portability problems.  E.g., when using the Microsoft
C compiler and linker a SHLIB that knows about the
-l and -L flags can translate
    -lfoo -L/dir/subdir
into LDFLAGS that link.exe knows about:
    foo.lib /libpath:\dir\subdir

If you need other linker flags, could they be in compiler/platform-
specific Makevars-<compiler/platform>?  I think other
ones are not very common.

Bill Dunlap
Insightful Corporation
bill at insightful dot com

 "All statements in this message represent the opinions of the author and do
 not necessarily reflect Insightful Corporation policy or position."

More information about the R-devel mailing list