[Scons-users] SCons always uses relative path even when absolute path is set with LIBPATH

Matt,

If you can figure out the appropriate flags to the linker to resolve this
then it shouldn't be to difficult to make some changes to your build
Environment() to resolve this issue.

-Bill

Post by Matthew Bernard
Hello everyone,
I submitted an issue on GitHub a couple days ago at the link below which
provides some background on my issue as well as important outputs from my
build.
Currently developing on MacOS
python version: 2.7.14
scons versions: custom scons based on 2.1.0 and 3.0.1
https://github.com/SCons/scons/issues/3128
A brief history of my problem is that I develop a code which has used
scons to compile an application for many years. Recently, we started some
work which has required us to repackage our code to be compiled as a shared
library to be linked in with another code which uses make.
I was able to modify our scripts to output the dylib files but they won't
link into the higher program because all of the dependent dylibs are
registered using relative paths. In the brief discussion that I had on
GitHub, I was told this is expected behavior which puts me in a bind
because my code is comprised of 7 projects which depend on each other to
various degrees.
I have done quite a bit of research and found that there are tools
available for linux and Mac which can postprocess the shared libraries to
reregister the shared libraries using absolute paths but I would prefer to
do this work within scons if at all possible.
Thanks for your help
Matt
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Matthew Bernard

2018-05-25 15:49:38 UTC

Hey Bill,

It seems like scons already provides the interface to do this through the
LIBPATH and RPATH constructor variables. When I add them to the shared
library object it produces the correct linker flags, it is just that it
removes all of the directory structure that that I build up to have it
register the dylibs with eh absolute path.

Matt

Post by Bill Deegan
Matt,
If you can figure out the appropriate flags to the linker to resolve this
then it shouldn't be to difficult to make some changes to your build
Environment() to resolve this issue.
-Bill

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Bill Deegan

2018-05-25 16:04:16 UTC

So the flags are correct, but for your case the values provided to them are
incorrect?

Post by Matthew Bernard
Hey Bill,
It seems like scons already provides the interface to do this through the
LIBPATH and RPATH constructor variables. When I add them to the shared
library object it produces the correct linker flags, it is just that it
removes all of the directory structure that that I build up to have it
register the dylibs with eh absolute path.
Matt

Post by Matthew Bernard
Hello everyone,
I submitted an issue on GitHub a couple days ago at the link below which
provides some background on my issue as well as important outputs from my
build.
Currently developing on MacOS
python version: 2.7.14
scons versions: custom scons based on 2.1.0 and 3.0.1
https://github.com/SCons/scons/issues/3128
A brief history of my problem is that I develop a code which has used
scons to compile an application for many years. Recently, we started some
work which has required us to repackage our code to be compiled as a shared
library to be linked in with another code which uses make.
I was able to modify our scripts to output the dylib files but they
won't link into the higher program because all of the dependent dylibs are
registered using relative paths. In the brief discussion that I had on
GitHub, I was told this is expected behavior which puts me in a bind
because my code is comprised of 7 projects which depend on each other to
various degrees.
I have done quite a bit of research and found that there are tools
available for linux and Mac which can postprocess the shared libraries to
reregister the shared libraries using absolute paths but I would prefer to
do this work within scons if at all possible.
Thanks for your help
Matt
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Matthew Bernard

2018-05-25 18:08:52 UTC

That's right. in the sconscript I assign a build directory variable to be:
common_build_dir = '/Users/..../sConstructDir/build/common'

and then in the sharedlibrary call my code is

tpr_lib = env.SharedLibrary(target = 'dynamic_lib',
source = srcs,
LIBS = 'common',
LIBPATH= common_build_dir,
RPATH = common_build_dir
)

so that during the linker stage I would expect to see

gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files] -L/Users/..../sConstruct/build/common -lcommon

but during the linker stage in the build-cmds output it is reported as

gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files] -Lbuild/common -lcommon

In the github issues chat you suggested modifying my changing the type of
common_build_dir from a string to a Dir class which I did but it didn't
unfortunately it didn't change the build commands that were actually called.

Thanks Matt

Post by Bill Deegan
So the flags are correct, but for your case the values provided to them
are incorrect?

Post by Bill Deegan
Matt,
If you can figure out the appropriate flags to the linker to resolve
this then it shouldn't be to difficult to make some changes to your build
Environment() to resolve this issue.
-Bill
On Fri, May 25, 2018 at 8:42 AM, Matthew Bernard <

Post by Matthew Bernard
Hello everyone,
I submitted an issue on GitHub a couple days ago at the link below
which provides some background on my issue as well as important outputs
from my build.
Currently developing on MacOS
python version: 2.7.14
scons versions: custom scons based on 2.1.0 and 3.0.1
https://github.com/SCons/scons/issues/3128
A brief history of my problem is that I develop a code which has used
scons to compile an application for many years. Recently, we started some
work which has required us to repackage our code to be compiled as a shared
library to be linked in with another code which uses make.
I was able to modify our scripts to output the dylib files but they
won't link into the higher program because all of the dependent dylibs are
registered using relative paths. In the brief discussion that I had on
GitHub, I was told this is expected behavior which puts me in a bind
because my code is comprised of 7 projects which depend on each other to
various degrees.
I have done quite a bit of research and found that there are tools
available for linux and Mac which can postprocess the shared libraries to
reregister the shared libraries using absolute paths but I would prefer to
do this work within scons if at all possible.
Thanks for your help
Matt
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Mats Wichmann

2018-05-25 19:52:35 UTC

Post by Matthew Bernard
common_build_dir = '/Users/..../sConstructDir/build/common'
and then in the sharedlibrary call my code is
tpr_lib = env.SharedLibrary(target = 'dynamic_lib',
source = srcs,
LIBS = 'common',
LIBPATH= common_build_dir,
RPATH = common_build_dir
)
so that during the linker stage I would expect to see
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files] -L/Users/..../sConstruct/build/common -lcommon
but during the linker stage in the build-cmds output it is reported as
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files] -Lbuild/common -lcommon

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.

I know the Mac has funky extra stuff, look up @executable_path. Not a
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.

Bill Deegan

2018-05-27 17:57:30 UTC

What's the proper flag to specify RPATH?

Post by Matthew Bernard
That's right. in the sconscript I assign a build directory variable to
common_build_dir = '/Users/..../sConstructDir/build/common'
and then in the sharedlibrary call my code is
tpr_lib = env.SharedLibrary(target = 'dynamic_lib',
source = srcs,
LIBS = 'common',
LIBPATH= common_build_dir,
RPATH = common_build_dir
)
so that during the linker stage I would expect to see
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files] -L/Users/..../sConstruct/build/common -lcommon
but during the linker stage in the build-cmds output it is reported as
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files] -Lbuild/common -lcommon

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Matthew Bernard

2018-05-27 18:35:02 UTC

My problem is that rather than using scons to build an application as we
did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.

The external application can properly reference everything through the -L
flag as you said, but the top level shared library (which we used to just
compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.

We would prefer not to resort to using LD_ Library_path as it is not secure
and we will be installing this code onto clusters once these build problems
are resolved so we will not have the ability to control those flags anyway.

I know it is an odd use case but I would really prefer to keep using scons
for this special case because we have built up a large set of supported
configurations for our code when compiling a application. If it isnât
possible to do this through input, could you point me at the part of scons
that normalizes path strings?

Thanks
Matt

Post by Bill Deegan
What's the proper flag to specify RPATH?

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Bill Deegan

2018-05-27 18:46:00 UTC

It looks like you want the following in your command line for linking the
shared library:

gfortran -Wl,-rpath,$RPATH -o build/dynamic_lib/libdynamic_lib.dylib
-dynamiclib [objectfiles] -Lbuild/common -lcommon

Does that sound right?
(Where your RPATH is an absolute path)

Post by Matthew Bernard
My problem is that rather than using scons to build an application as we
did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.
The external application can properly reference everything through the -L
flag as you said, but the top level shared library (which we used to just
compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.
We would prefer not to resort to using LD_ Library_path as it is not
secure and we will be installing this code onto clusters once these build
problems are resolved so we will not have the ability to control those
flags anyway.
I know it is an odd use case but I would really prefer to keep using scons
for this special case because we have built up a large set of supported
configurations for our code when compiling a application. If it isnât
possible to do this through input, could you point me at the part of scons
that normalizes path strings?
Thanks
Matt

Post by Bill Deegan
What's the proper flag to specify RPATH?

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Matthew Bernard

2018-05-27 19:32:03 UTC

Yep. Thatâs right. That would resolve my issue by letting the external
application link my code and its dependent libraries from where the
external
Application is compiling.

Thanks for spending time on this.
Matt

Post by Bill Deegan
It looks like you want the following in your command line for linking the
gfortran -Wl,-rpath,$RPATH -o build/dynamic_lib/libdynamic_lib.dylib
-dynamiclib [objectfiles] -Lbuild/common -lcommon
Does that sound right?
(Where your RPATH is an absolute path)
On Sun, May 27, 2018 at 11:35 AM, Matthew Bernard <

Post by Matthew Bernard
My problem is that rather than using scons to build an application as we
did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.
The external application can properly reference everything through the -L
flag as you said, but the top level shared library (which we used to just
compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.
We would prefer not to resort to using LD_ Library_path as it is not
secure and we will be installing this code onto clusters once these build
problems are resolved so we will not have the ability to control those
flags anyway.
I know it is an odd use case but I would really prefer to keep using
scons for this special case because we have built up a large set of
supported configurations for our code when compiling a application. If it
isnât possible to do this through input, could you point me at the part of
scons that normalizes path strings?
Thanks
Matt

Post by Bill Deegan
What's the proper flag to specify RPATH?

Post by Matthew Bernard
That's right. in the sconscript I assign a build directory variable
common_build_dir = '/Users/..../sConstructDir/build/common'
and then in the sharedlibrary call my code is
tpr_lib = env.SharedLibrary(target = 'dynamic_lib',
source = srcs,
LIBS = 'common',
LIBPATH= common_build_dir,
RPATH = common_build_dir
)
so that during the linker stage I would expect to see
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files] -L/Users/..../sConstruct/build/common -lcommon
but during the linker stage in the build-cmds output it is reported as
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files] -Lbuild/common -lcommon

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Bill Deegan

2018-05-27 20:07:02 UTC

How are you installing gfortran on your mac? macports? brew? other?
(trying to replicated your environment)

Post by Matthew Bernard
Yep. Thatâs right. That would resolve my issue by letting the external
application link my code and its dependent libraries from where the
external
Application is compiling.
Thanks for spending time on this.
Matt

Post by Matthew Bernard
My problem is that rather than using scons to build an application as we
did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.
The external application can properly reference everything through the
-L flag as you said, but the top level shared library (which we used to
just compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.
We would prefer not to resort to using LD_ Library_path as it is not
secure and we will be installing this code onto clusters once these build
problems are resolved so we will not have the ability to control those
flags anyway.
I know it is an odd use case but I would really prefer to keep using
scons for this special case because we have built up a large set of
supported configurations for our code when compiling a application. If it
isnât possible to do this through input, could you point me at the part of
scons that normalizes path strings?
Thanks
Matt

Post by Bill Deegan
What's the proper flag to specify RPATH?

[object

Post by Matthew Bernard
files] -L/Users/..../sConstruct/build/common -lcommon
but during the linker stage in the build-cmds output it is reported

Post by Matthew Bernard
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib

[object

Post by Matthew Bernard
files] -Lbuild/common -lcommon

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Matthew Bernard

2018-05-27 20:12:46 UTC

GFortran (as a part of the gcc suite) is compiled from the MOOSE framework
which is the external application that my code is being merged with.

They exclusively use Make but my application is mostly Fortran so we really
rely on scons to resolve the dependencies.

Post by Bill Deegan
How are you installing gfortran on your mac? macports? brew? other?
(trying to replicated your environment)
On Sun, May 27, 2018 at 12:32 PM, Matthew Bernard <

Post by Bill Deegan
It looks like you want the following in your command line for linking
gfortran -Wl,-rpath,$RPATH -o build/dynamic_lib/libdynamic_lib.dylib
-dynamiclib [objectfiles] -Lbuild/common -lcommon
Does that sound right?
(Where your RPATH is an absolute path)
On Sun, May 27, 2018 at 11:35 AM, Matthew Bernard <

Post by Matthew Bernard
My problem is that rather than using scons to build an application as
we did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.
The external application can properly reference everything through the
-L flag as you said, but the top level shared library (which we used to
just compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.
We would prefer not to resort to using LD_ Library_path as it is not
secure and we will be installing this code onto clusters once these build
problems are resolved so we will not have the ability to control those
flags anyway.
I know it is an odd use case but I would really prefer to keep using
scons for this special case because we have built up a large set of
supported configurations for our code when compiling a application. If it
isnât possible to do this through input, could you point me at the part of
scons that normalizes path strings?
Thanks
Matt

Post by Bill Deegan
What's the proper flag to specify RPATH?

[object

Post by Matthew Bernard
files] -L/Users/..../sConstruct/build/common -lcommon
but during the linker stage in the build-cmds output it is reported

Post by Matthew Bernard
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib

[object

Post by Matthew Bernard
files] -Lbuild/common -lcommon

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Bill Deegan

2018-05-27 20:18:17 UTC

O.k try adding this:
env['__RPATH'] = '$_RPATH'

See if that resolves it.

Post by Matthew Bernard
GFortran (as a part of the gcc suite) is compiled from the MOOSE
framework which is the external application that my code is being merged
with.
They exclusively use Make but my application is mostly Fortran so we
really rely on scons to resolve the dependencies.

Post by Bill Deegan
How are you installing gfortran on your mac? macports? brew? other?
(trying to replicated your environment)
On Sun, May 27, 2018 at 12:32 PM, Matthew Bernard <

Post by Matthew Bernard
My problem is that rather than using scons to build an application as
we did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.
The external application can properly reference everything through the
-L flag as you said, but the top level shared library (which we used to
just compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.
We would prefer not to resort to using LD_ Library_path as it is not
secure and we will be installing this code onto clusters once these build
problems are resolved so we will not have the ability to control those
flags anyway.
I know it is an odd use case but I would really prefer to keep using
scons for this special case because we have built up a large set of
supported configurations for our code when compiling a application. If it
isnât possible to do this through input, could you point me at the part of
scons that normalizes path strings?
Thanks
Matt

Post by Bill Deegan
What's the proper flag to specify RPATH?

Post by Matthew Bernard
That's right. in the sconscript I assign a build directory
common_build_dir = '/Users/..../sConstructDir/build/common'
and then in the sharedlibrary call my code is
tpr_lib = env.SharedLibrary(target = 'dynamic_lib',
source = srcs,
LIBS = 'common',
LIBPATH= common_build_dir,
RPATH = common_build_dir
)
so that during the linker stage I would expect to see
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib

[object

Post by Matthew Bernard
files] -L/Users/..../sConstruct/build/common -lcommon
but during the linker stage in the build-cmds output it is

reported as

Post by Matthew Bernard
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib

[object

Post by Matthew Bernard
files] -Lbuild/common -lcommon

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Bill Deegan

2018-05-27 20:18:45 UTC

or at least gets the -W-l... flag on your command line.
(can you hop on the IRC channel?)

Post by Bill Deegan
env['__RPATH'] = '$_RPATH'
See if that resolves it.

Post by Bill Deegan
How are you installing gfortran on your mac? macports? brew? other?
(trying to replicated your environment)
On Sun, May 27, 2018 at 12:32 PM, Matthew Bernard <

Post by Matthew Bernard
My problem is that rather than using scons to build an application as
we did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.
The external application can properly reference everything through
the -L flag as you said, but the top level shared library (which we used to
just compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.
We would prefer not to resort to using LD_ Library_path as it is not
secure and we will be installing this code onto clusters once these build
problems are resolved so we will not have the ability to control those
flags anyway.
I know it is an odd use case but I would really prefer to keep using
scons for this special case because we have built up a large set of
supported configurations for our code when compiling a application. If it
isnât possible to do this through input, could you point me at the part of
scons that normalizes path strings?
Thanks
Matt
On Sun, May 27, 2018 at 1:57 PM Bill Deegan <

Post by Bill Deegan
What's the proper flag to specify RPATH?

[object

Post by Matthew Bernard
files] -L/Users/..../sConstruct/build/common -lcommon
but during the linker stage in the build-cmds output it is

reported as

Post by Matthew Bernard
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib

[object

Post by Matthew Bernard
files] -Lbuild/common -lcommon

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Matthew Bernard

2018-05-27 20:20:50 UTC

I will try once I get to my computer. I can be on in about 30 minutes I am
away from the computer at the moment.

Post by Bill Deegan
or at least gets the -W-l... flag on your command line.
(can you hop on the IRC channel?)

Post by Bill Deegan
env['__RPATH'] = '$_RPATH'
See if that resolves it.
On Sun, May 27, 2018 at 1:12 PM, Matthew Bernard <

Post by Bill Deegan
How are you installing gfortran on your mac? macports? brew? other?
(trying to replicated your environment)
On Sun, May 27, 2018 at 12:32 PM, Matthew Bernard <

Post by Matthew Bernard
My problem is that rather than using scons to build an application
as we did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.
The external application can properly reference everything through
the -L flag as you said, but the top level shared library (which we used to
just compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.
We would prefer not to resort to using LD_ Library_path as it is not
secure and we will be installing this code onto clusters once these build
problems are resolved so we will not have the ability to control those
flags anyway.
I know it is an odd use case but I would really prefer to keep using
scons for this special case because we have built up a large set of
supported configurations for our code when compiling a application. If it
isnât possible to do this through input, could you point me at the part of
scons that normalizes path strings?
Thanks
Matt
On Sun, May 27, 2018 at 1:57 PM Bill Deegan <

Post by Bill Deegan
What's the proper flag to specify RPATH?

[object

Post by Matthew Bernard
files] -L/Users/..../sConstruct/build/common -lcommon
but during the linker stage in the build-cmds output it is

reported as

Post by Matthew Bernard
gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib

[object

Post by Matthew Bernard
files] -Lbuild/common -lcommon

Having trouble understanding what the problem is... why do you want to
put an rpath into the library in the first place? that means you're
hardcoding a place the dynamic linker will look for the library's own
library dependencies - at runtime. If you made that the same as your
build location, that means the final binary will always need that build
area to be present, or the libraries won't be found. Unlikely to be
right for production. This is nothing to do with scons, and nothing to
do with whether the rpath is relative or absolute, although arguably the
problem is more complex if it's relative. If you use an rpath, it
should point to the place where the libraries are going to be
/installed/, not where they're built. This has nothing to do with
finding the dependent libraries at link time - when you do your second
link in the project using Make. That link has to have -L instructions
to point to where to find those libraries for linking purposes.
Mac user so don't know what's going on with that. Otherwise, instead of
rpath you can use LD_LIBRARY_PATH (with caution) on linux,
DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

_______________________________________________
Scons-users mailing list
https://pairlist4.pair.net/mailman/listinfo/scons-users

Matthew Bernard

2018-05-28 12:24:05 UTC

I made a git repo which demonstrates the behavior. Hopefully this can help
with the process.

https://github.com/msbm97/SConsLibBuild

Post by Matthew Bernard
I will try once I get to my computer. I can be on in about 30 minutes I am
away from the computer at the moment.

Post by Bill Deegan
or at least gets the -W-l... flag on your command line.
(can you hop on the IRC channel?)

Post by Bill Deegan
env['__RPATH'] = '$_RPATH'
See if that resolves it.
On Sun, May 27, 2018 at 1:12 PM, Matthew Bernard <

Post by Bill Deegan
How are you installing gfortran on your mac? macports? brew? other?
(trying to replicated your environment)
On Sun, May 27, 2018 at 12:32 PM, Matthew Bernard <

Post by Matthew Bernard
Yep. Thatâs right. That would resolve my issue by letting the
external application link my code and its dependent libraries from where
the external
Application is compiling.
Thanks for spending time on this.
Matt
On Sun, May 27, 2018 at 2:46 PM Bill Deegan <

Post by Bill Deegan
It looks like you want the following in your command line for
gfortran -Wl,-rpath,$RPATH -o build/dynamic_lib/libdynamic_lib.dylib
-dynamiclib [objectfiles] -Lbuild/common -lcommon
Does that sound right?
(Where your RPATH is an absolute path)
On Sun, May 27, 2018 at 11:35 AM, Matthew Bernard <

Post by Matthew Bernard
My problem is that rather than using scons to build an application
as we did in the past, I am now building a set of shared libraries for an
external application to reference. Scons is linking all of the libraries
together properly but because the dependent libraries are registered with a
relative path based on where the sconstruct file is, the external
application fails to properly link the libraries.
The external application can properly reference everything through
the -L flag as you said, but the top level shared library (which we used to
just compile as an application) canât find its dependent libraries which is
resolved if the files are registered with an absolute path.
We would prefer not to resort to using LD_ Library_path as it is
not secure and we will be installing this code onto clusters once these
build problems are resolved so we will not have the ability to control
those flags anyway.
I know it is an odd use case but I would really prefer to keep
using scons for this special case because we have built up a large set of
supported configurations for our code when compiling a application. If it
isnât possible to do this through input, could you point me at the part of
scons that normalizes path strings?
Thanks
Matt
On Sun, May 27, 2018 at 1:57 PM Bill Deegan <

Post by Bill Deegan
What's the proper flag to specify RPATH?