manpath change for ports ?

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

manpath change for ports ?

Baptiste Daroussin-2
Hi all,

I would like to propose a change in the localbase hier for ports

I think we should add /usr/local/share/man in the manpath along with at first
and maybe instead of in long term.

The reason is:
- /usr/local/share/man seems more consistent to me with base which have:
  /usr/share/man
- It will remove lots of patches from the ports tree where were we need to patch
  upstream build system to install in a non usual path.

My proposal is to add to the manpath /usr/local/share/man in default man(1)
command in FreeBSD 12 (MFCed to 11-STABLE)

and either provide an errata for 11.0/10.3 or a
/usr/local/etc/man.d/something.conf via a port or something like that for those
two, what do you think?

For the same reason I would like to allow porters to stop patching (with pathfix
or anything else) the path for pkgconfig files and allow
/usr/local/lib/pkgconfig along with the current
/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig

Which will also remove tons of hacks from the ports tree.

What do you think?

Best regards,
Bapt

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Alfred Perlstein-2


On 3/6/17 3:56 PM, Baptiste Daroussin wrote:

> Hi all,
>
> I would like to propose a change in the localbase hier for ports
>
> I think we should add /usr/local/share/man in the manpath along with at first
> and maybe instead of in long term.
>
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which have:
>    /usr/share/man
> - It will remove lots of patches from the ports tree where were we need to patch
>    upstream build system to install in a non usual path.
>
> My proposal is to add to the manpath /usr/local/share/man in default man(1)
> command in FreeBSD 12 (MFCed to 11-STABLE)
>
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that for those
> two, what do you think?
>
> For the same reason I would like to allow porters to stop patching (with pathfix
> or anything else) the path for pkgconfig files and allow
> /usr/local/lib/pkgconfig along with the current
> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>
> Which will also remove tons of hacks from the ports tree.
>
> What do you think?
>
> Best regards,
> Bapt
Yes please.  Reducing the required changes to port software to FreeBSD
is a good thing.

-Alfred
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Jan Beich-5
In reply to this post by Baptiste Daroussin-2
Baptiste Daroussin <[hidden email]> writes:

> Hi all,
>
> I would like to propose a change in the localbase hier for ports
>
> I think we should add /usr/local/share/man in the manpath along with at first
> and maybe instead of in long term.
>
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which have:
>   /usr/share/man
> - It will remove lots of patches from the ports tree where were we need to patch
>   upstream build system to install in a non usual path.

Can you also move /usr/local/info to /usr/local/share/info? texinfo is
gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
try to encroach on GNU defaults.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Baptiste Daroussin-2
On Tue, Mar 07, 2017 at 06:29:19AM +0000, Jan Beich wrote:

> Baptiste Daroussin <[hidden email]> writes:
>
> > Hi all,
> >
> > I would like to propose a change in the localbase hier for ports
> >
> > I think we should add /usr/local/share/man in the manpath along with at first
> > and maybe instead of in long term.
> >
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we need to patch
> >   upstream build system to install in a non usual path.
>
> Can you also move /usr/local/info to /usr/local/share/info? texinfo is
> gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
> try to encroach on GNU defaults.
Yes would be a good one

Best regards,
Bapt

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Diane Bruce
In reply to this post by Jan Beich-5
On Tue, Mar 07, 2017 at 06:29:19AM +0000, Jan Beich wrote:

> Baptiste Daroussin <[hidden email]> writes:
>
> > Hi all,
> >
> > I would like to propose a change in the localbase hier for ports
> >
> > I think we should add /usr/local/share/man in the manpath along with at first
> > and maybe instead of in long term.
> >
> > The reason is:
> > - /usr/local/share/man seems more consistent to me with base which have:
> >   /usr/share/man
> > - It will remove lots of patches from the ports tree where were we need to patch
> >   upstream build system to install in a non usual path.
>
> Can you also move /usr/local/info to /usr/local/share/info? texinfo is
> gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
> try to encroach on GNU defaults.

A big yes from me for both of these proposals.

--
- [hidden email] [hidden email] http://www.db.net/~db
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Eric van Gyzen-5
In reply to this post by Baptiste Daroussin-2
On 03/06/2017 17:56, Baptiste Daroussin wrote:
> Hi all,
>
> I would like to propose a change in the localbase hier for ports

[...]

> Which will also remove tons of hacks from the ports tree.
>
> What do you think?

This sounds good to me.

I seem to recall that most(?) Linux distros used /usr/man many years
ago, but they switched to /usr/share/man, I think in the early 2000s.
If that's correct, then I consider our /usr/local/man path a historical
curiosity that should finally be changed to /usr/local/share/man.

Eric
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Chris H-2
In reply to this post by Baptiste Daroussin-2
On Tue, 7 Mar 2017 00:56:10 +0100 Baptiste Daroussin <[hidden email]> wrote

> Hi all,
>
> I would like to propose a change in the localbase hier for ports
>
> I think we should add /usr/local/share/man in the manpath along with at first
> and maybe instead of in long term.
>
> The reason is:
> - /usr/local/share/man seems more consistent to me with base which have:
>   /usr/share/man
> - It will remove lots of patches from the ports tree where were we need to
> patch   upstream build system to install in a non usual path.
>
> My proposal is to add to the manpath /usr/local/share/man in default man(1)
> command in FreeBSD 12 (MFCed to 11-STABLE)
>
> and either provide an errata for 11.0/10.3 or a
> /usr/local/etc/man.d/something.conf via a port or something like that for
> those two, what do you think?
>
> For the same reason I would like to allow porters to stop patching (with
> pathfix or anything else) the path for pkgconfig files and allow
> /usr/local/lib/pkgconfig along with the current
> /usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig
>
> Which will also remove tons of hacks from the ports tree.
>
> What do you think?
+1 please do.
I can't think of any (good) reason not to.

Thanks!

--Chris
>
> Best regards,
> Bapt


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Tijl Coosemans-4
In reply to this post by Eric van Gyzen-5
On Tue, 7 Mar 2017 09:51:14 -0600 Eric van Gyzen <[hidden email]> wrote:

> On 03/06/2017 17:56, Baptiste Daroussin wrote:
>> I would like to propose a change in the localbase hier for ports  
>
> [...]
>
>> Which will also remove tons of hacks from the ports tree.
>>
>> What do you think?  
>
> This sounds good to me.
>
> I seem to recall that most(?) Linux distros used /usr/man many years
> ago, but they switched to /usr/share/man, I think in the early 2000s.
> If that's correct, then I consider our /usr/local/man path a historical
> curiosity that should finally be changed to /usr/local/share/man.

Yes, we used PREFIX/man because that's what software developed for
Linux used at the time.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Renato Botelho-3
In reply to this post by Diane Bruce
On 07/03/17 12:24, Diane Bruce wrote:

> On Tue, Mar 07, 2017 at 06:29:19AM +0000, Jan Beich wrote:
>> Baptiste Daroussin <[hidden email]> writes:
>>
>>> Hi all,
>>>
>>> I would like to propose a change in the localbase hier for ports
>>>
>>> I think we should add /usr/local/share/man in the manpath along with at first
>>> and maybe instead of in long term.
>>>
>>> The reason is:
>>> - /usr/local/share/man seems more consistent to me with base which have:
>>>   /usr/share/man
>>> - It will remove lots of patches from the ports tree where were we need to patch
>>>   upstream build system to install in a non usual path.
>> Can you also move /usr/local/info to /usr/local/share/info? texinfo is
>> gone since 11.0-RELEASE (or r276551) but hier(7) and BSD.usr.dist still
>> try to encroach on GNU defaults.
> A big yes from me for both of these proposals.
>

+1

--
Renato Botelho

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Dag-Erling Smørgrav
In reply to this post by Baptiste Daroussin-2
Baptiste Daroussin <[hidden email]> writes:
> I would like to propose a change in the localbase hier for ports
>
> I think we should add /usr/local/share/man in the manpath along with
> at first and maybe instead of in long term.

2) plus info -> share/info as suggested by jbeich

3) plus libdata/pkgconfig -> lib/pkgconfig

These three items will ensure that "./configure --prefix=/usr/local &&
make install" will do the right thing out of the box - by changing our
definition of "the right thing" to match what the GNU autotools have
been doing for at least 15 years.

4) Remove the hardcoded library path in lang/gcc*

This makes it possible to work on software that includes both libraries
and programs while an earlier copy of the same software is already
installed.  With the current state of gcc, the programs you are working
on will be linked against the version of the library that's already
installed instead of the version you just compiled, and there is nothing
you can do to prevent it.  You won't notice anything if all you ever do
is "make && make install", because the new library will replace the old,
but if you try to run your program directly from the build tree, it will
use the wrong library.  This can be incredibly frustrating if you're not
aware of it - imagine you're trying to fix a bug in that library and no
matter what you do, your regression test keeps failing...

DES
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Julian Elischer-5
On 8/3/17 11:39 pm, Dag-Erling Smørgrav wrote:

> Baptiste Daroussin <[hidden email]> writes:
>> I would like to propose a change in the localbase hier for ports
>>
>> I think we should add /usr/local/share/man in the manpath along with
>> at first and maybe instead of in long term.
> 2) plus info -> share/info as suggested by jbeich
>
> 3) plus libdata/pkgconfig -> lib/pkgconfig
>
> These three items will ensure that "./configure --prefix=/usr/local &&
> make install" will do the right thing out of the box - by changing our
> definition of "the right thing" to match what the GNU autotools have
> been doing for at least 15 years.
>
> 4) Remove the hardcoded library path in lang/gcc*
>
> This makes it possible to work on software that includes both libraries
> and programs while an earlier copy of the same software is already
> installed.  With the current state of gcc, the programs you are working
> on will be linked against the version of the library that's already
> installed instead of the version you just compiled, and there is nothing
unless you use --sysroot=...
> you can do to prevent it.  You won't notice anything if all you ever do
> is "make && make install", because the new library will replace the old,
> but if you try to run your program directly from the build tree, it will
> use the wrong library.  This can be incredibly frustrating if you're not
> aware of it - imagine you're trying to fix a bug in that library and no
> matter what you do, your regression test keeps failing...
>
> DES


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Dag-Erling Smørgrav
Julian Elischer <[hidden email]> writes:
> Dag-Erling Smørgrav <[hidden email]> writes:
> > This makes it possible to work on software that includes both
> > libraries and programs while an earlier copy of the same software is
> > already installed.  With the current state of gcc, the programs you
> > are working on will be linked against the version of the library
> > that's already installed instead of the version you just compiled,
> > and there is nothing
> unless you use --sysroot=...

Sure, if you have a copy of every single library your project depends on
in your build tree.

Is it really unreasonable to expect this to work out of the box?

DES
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Tijl Coosemans-4
In reply to this post by Dag-Erling Smørgrav
On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav <[hidden email]> wrote:

> 4) Remove the hardcoded library path in lang/gcc*
>
> This makes it possible to work on software that includes both libraries
> and programs while an earlier copy of the same software is already
> installed.  With the current state of gcc, the programs you are working
> on will be linked against the version of the library that's already
> installed instead of the version you just compiled, and there is nothing
> you can do to prevent it.  You won't notice anything if all you ever do
> is "make && make install", because the new library will replace the old,
> but if you try to run your program directly from the build tree, it will
> use the wrong library.  This can be incredibly frustrating if you're not
> aware of it - imagine you're trying to fix a bug in that library and no
> matter what you do, your regression test keeps failing...

Are you talking about gcc implicitly searching /usr/local/include and
/usr/local/lib?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Warner Losh
On Wed, Mar 8, 2017 at 10:21 AM, Tijl Coosemans <[hidden email]> wrote:

> On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav <[hidden email]> wrote:
>> 4) Remove the hardcoded library path in lang/gcc*
>>
>> This makes it possible to work on software that includes both libraries
>> and programs while an earlier copy of the same software is already
>> installed.  With the current state of gcc, the programs you are working
>> on will be linked against the version of the library that's already
>> installed instead of the version you just compiled, and there is nothing
>> you can do to prevent it.  You won't notice anything if all you ever do
>> is "make && make install", because the new library will replace the old,
>> but if you try to run your program directly from the build tree, it will
>> use the wrong library.  This can be incredibly frustrating if you're not
>> aware of it - imagine you're trying to fix a bug in that library and no
>> matter what you do, your regression test keeps failing...
>
> Are you talking about gcc implicitly searching /usr/local/include and
> /usr/local/lib?

That's currently inconsistent between base gcc, clang, binutils and
ports versions. I forget which ones do and which ones don't search
automatically. IMHO, they all should.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Jan Beich-5
In reply to this post by Dag-Erling Smørgrav
Dag-Erling Smørgrav <[hidden email]> writes:

> Baptiste Daroussin <[hidden email]> writes:
>
>> I would like to propose a change in the localbase hier for ports
>>
>> I think we should add /usr/local/share/man in the manpath along with
>> at first and maybe instead of in long term.
>
> 2) plus info -> share/info as suggested by jbeich
>
> 3) plus libdata/pkgconfig -> lib/pkgconfig
>
> These three items will ensure that "./configure --prefix=/usr/local &&
> make install" will do the right thing out of the box - by changing our
> definition of "the right thing" to match what the GNU autotools have
> been doing for at least 15 years.
/usr/local is *the* default location according to GNU[1] and reinforced
by FHS[2] which want it "safe from being overwritten when the system
software is updated". Not on FreeBSD where site-local stuff like your
example above and ports/packages trample on each other. NetBSD avoided
the issue by moving /usr/local to /usr/pkg.

[1] https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Tijl Coosemans-4
In reply to this post by Dag-Erling Smørgrav
On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav <[hidden email]> wrote:

> 4) Remove the hardcoded library path in lang/gcc*
>
> This makes it possible to work on software that includes both libraries
> and programs while an earlier copy of the same software is already
> installed.  With the current state of gcc, the programs you are working
> on will be linked against the version of the library that's already
> installed instead of the version you just compiled, and there is nothing
> you can do to prevent it.  You won't notice anything if all you ever do
> is "make && make install", because the new library will replace the old,
> but if you try to run your program directly from the build tree, it will
> use the wrong library.  This can be incredibly frustrating if you're not
> aware of it - imagine you're trying to fix a bug in that library and no
> matter what you do, your regression test keeps failing...

If you want to run a program from its build directory and the program
links to a library also in the build directory then you have to run the
program with LD_LIBRARY_PATH environment variable set to the build
directory.  Or, you could link the program with -rpath <builddir>, but
then you should relink it before installation.  It's one of the things
libtool takes care of automatically.

If this is the problem you have then it has nothing to do with gcc.  If
you're not using libtool then your program probably does not have any
rpath or runpath so it falls back on rtld/ldconfig which may find it in
/usr/local/lib.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Tijl Coosemans-4
In reply to this post by Warner Losh
On Wed, 8 Mar 2017 10:31:32 -0700 Warner Losh <[hidden email]> wrote:
> On Wed, Mar 8, 2017 at 10:21 AM, Tijl Coosemans <[hidden email]> wrote:
>> Are you talking about gcc implicitly searching /usr/local/include and
>> /usr/local/lib?  
>
> That's currently inconsistent between base gcc, clang, binutils and
> ports versions. I forget which ones do and which ones don't search
> automatically.

It's only ports binutils and ports gcc that search /usr/local.

> IMHO, they all should.

I used to think this too, but now I think it should be possible to use
any compiler to compile something from base or something that should only
depend on things from base, for testing purposes or perhaps because it
needs to be deployed on some other machine.  Compilers shouldn't search
/usr/local implicitly then.  It's easy enough to add -I and -L flags
(perhaps using pkg-config) but it's not easy to remove built-in -I and
-L flags.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Dag-Erling Smørgrav
In reply to this post by Tijl Coosemans-4
Tijl Coosemans <[hidden email]> writes:

> If you want to run a program from its build directory and the program
> links to a library also in the build directory then you have to run the
> program with LD_LIBRARY_PATH environment variable set to the build
> directory.  Or, you could link the program with -rpath <builddir>, but
> then you should relink it before installation.  It's one of the things
> libtool takes care of automatically.
>
> If this is the problem you have then it has nothing to do with gcc.  If
> you're not using libtool then your program probably does not have any
> rpath or runpath so it falls back on rtld/ldconfig which may find it in
> /usr/local/lib.

You are correct in theory, but I am using libtool and it doesn't work.

Here's a series of emails I wrote to the maintainer a little over six
months ago explaining the problem:

1)

| I discovered that lang/gcc48 (and presumably the other gcc ports as
| well) not only have /usr/local/include in their default include path,
| but actually place it ahead of /usr/include.  This is causing me no end
| of grief with software that uses iconv, because GNU libiconv's <iconv.h>
| f*s up your namespace so the build fails unless you explicitly link with
| GNU libiconv instead of using the libc version.  [...]

2)

|                              [...] I realized over the weekend that the
| situation is even worse than I initially thought.  Basically, ports gcc
| is unusable for any other purpose than to build ports which don't
| support clang.  Let me explain with a hypothetical scenario:
|
| You are developing a library which is important enough that you need to
| have the stable version installed on your development system.  It is
| installed in /usr/local as usual.  You've been working on fixing a bug,
| and have written a unit test which exercises the relevant code and
| verified that it can deterministically trigger the bug.  You fix the bug
| and 'make check' again, all green.  Then you clean out your working
| copy, re-run configure with CC=gcc and 'make check' again.  Your tests
| fail.
|
| What happened is that when you built your code with gcc, the tests were
| linked and run with the stable version of the library, where the bug is
| not fixed.  You can build with LDFLAGS=-L$(top_builddir)/lib, you can
| even specify the full path to the library in LDADD for each individual
| test, it doesn't matter.  It will *always* pick the installed version
| first.  The only way to get your tests to pass is to not have the
| library installed.
|
| Real-world example - a 10.3 system with upstream OpenPAM installed
| because it uses OpenPAM's OATH implementation:
|
| with base clang:
|
| des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
| /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
| libpam.so.2 => /home/des/src/openpam/trunk/lib/libpam/.libs/libpam.so.2 (0x800822000)
| liboath.so.2 => /home/des/src/openpam/trunk/lib/liboath/.libs/liboath.so.2 (0x800a34000)
| libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
| libc.so.7 => /lib/libc.so.7 (0x80102f000)
|
| with lang/gcc:
|
| des@desk ~/src/openpam/trunk% pkg which =gcc
| /usr/local/bin/gcc was installed by package gcc-4.8.5_2
| des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
| /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
| libpam.so.2 => /usr/local/lib/libpam.so.2 (0x800822000)
| liboath.so.2 => /usr/local/lib/liboath.so.2 (0x800a34000)
| libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
| libc.so.7 => /lib/libc.so.7 (0x80102f000)
| libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x8013dc000)
| libthr.so.3 => /lib/libthr.so.3 (0x8017e9000)
|
| (and don't ask me why the gcc version is linked with two different
| versions of libcrypto!)

3)

| I honestly thought this was a recent change, but I realize now that the
| recent change is that I switched from developing on systems that still
| had gcc in base (without /usr/local in the search path) to systems that
| don't, and therefore use gcc from ports.
|
| The correct solution, in my opinion, is to remove /usr/local from all
| search paths.  There is no need for it, even for ports, because most
| ports add /usr/local to CPPFLAGS and LDFLAGS, either explicitly or
| implicitly (by passing --prefix=${LOCALBASE} to the configure script).
| If there are gcc-only ports which *don't* do it, they can easily be
| fixed.
|
| I initially thought that merely changing the library search order would
| be sufficient, but apparently gcc somehow forces /usr/local/lib to take
| precedence even over ${LD_LIBRARY_PATH}, which is what causes my unit
| tests to fail.  Here is an example from another project where I modified
| the libtool wrapper to show its environment and run ldd before executing
| the binary:
|
| des@desk ~/src/cryb-to% ./t/t_core
| PATH=/home/des/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
| LD_LIBRARY_PATH=/home/des/src/cryb-to/lib/test/.libs:/home/des/src/cryb-to/lib/core/.libs
| /home/des/src/cryb-to/t/.libs/t_core:
| libcryb-test.so.0 => /usr/local/lib/libcryb-test.so.0 (0x80081f000)
| libcryb-core.so.0 => /usr/local/lib/libcryb-core.so.0 (0x800a26000)
| libc.so.7 => /lib/libc.so.7 (0x800c2a000)
| 1..2
| not ok 1 - version
| ok 2 - no memory leaked
|
| This is a skeleton test which only verifies that the library it's linked
| with has the same version as the one it was compiled with.  Here's the
| same test, with the same modifications, built with clang:
|
| des@desk ~/src/cryb-to% ./t/t_core  
| PATH=/home/des/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
| LD_LIBRARY_PATH=/home/des/src/cryb-to/lib/test/.libs:/home/des/src/cryb-to/lib/core/.libs
| /home/des/src/cryb-to/t/.libs/t_core:
| libcryb-test.so.0 => /home/des/src/cryb-to/lib/test/.libs/libcryb-test.so.0 (0x80081f000)
| libcryb-core.so.0 => /home/des/src/cryb-to/lib/core/.libs/libcryb-core.so.0 (0x800a27000)
| libc.so.7 => /lib/libc.so.7 (0x800c2c000)
| 1..2
| ok 1 - version
| ok 2 - no memory leaked
|
| Please understand that the *only* way I can think of to work around this
| is to set --nostdinc and --nostdlib and explicitly pass the correct
| search path and list of libraries (-lgcc -lc) to gcc, and even then I'm
| not sure it would work.  I don't find that reasonable at all.
|
| Note that I am not sure whether this problem is limited to gcc or if ld
| is also involved.  The iconv problem which I originally reported is
| caused by gcc picking up iconv.h from /usr/local/include instead of over
| /usr/include, but I'm not sure whether the linking problem is caused by
| gcc passing its search path on to ld, or to ld having its own incorrect
| search path.  I tried explicitly setting LD=/usr/bin/ld, but that
| doesn't make any difference since libtool uses gcc as a linker instead
| of calling ${LD} directly.

DES
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Dag-Erling Smørgrav
In reply to this post by Jan Beich-5
[hidden email] (Jan Beich) writes:
> /usr/local is *the* default location according to GNU[1] and reinforced
> by FHS[2] which want it "safe from being overwritten when the system
> software is updated". Not on FreeBSD where site-local stuff like your
> example above and ports/packages trample on each other. NetBSD avoided
> the issue by moving /usr/local to /usr/pkg.

All correct, but I don't really see the relevance...

DE
--
Dag-Erling Smørgrav - [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: manpath change for ports ?

Tijl Coosemans-4
In reply to this post by Dag-Erling Smørgrav
On Thu, 09 Mar 2017 09:29:42 +0100 Dag-Erling Smørgrav <[hidden email]> wrote:

> Tijl Coosemans <[hidden email]> writes:
>> If you want to run a program from its build directory and the program
>> links to a library also in the build directory then you have to run the
>> program with LD_LIBRARY_PATH environment variable set to the build
>> directory.  Or, you could link the program with -rpath <builddir>, but
>> then you should relink it before installation.  It's one of the things
>> libtool takes care of automatically.
>>
>> If this is the problem you have then it has nothing to do with gcc.  If
>> you're not using libtool then your program probably does not have any
>> rpath or runpath so it falls back on rtld/ldconfig which may find it in
>> /usr/local/lib.  
>
> You are correct in theory, but I am using libtool and it doesn't work.
>
> Here's a series of emails I wrote to the maintainer a little over six
> months ago explaining the problem:
>
> 1)
>
> | I discovered that lang/gcc48 (and presumably the other gcc ports as
> | well) not only have /usr/local/include in their default include path,
> | but actually place it ahead of /usr/include.  This is causing me no end
> | of grief with software that uses iconv, because GNU libiconv's <iconv.h>
> | f*s up your namespace so the build fails unless you explicitly link with
> | GNU libiconv instead of using the libc version.  [...]

Right, to use libc iconv(3) with -I/usr/local/include and GNU libiconv
installed you have to compile with -DLIBICONV_PLUG.

> 2)
>
> |                              [...] I realized over the weekend that the
> | situation is even worse than I initially thought.  Basically, ports gcc
> | is unusable for any other purpose than to build ports which don't
> | support clang.  Let me explain with a hypothetical scenario:
> |
> | You are developing a library which is important enough that you need to
> | have the stable version installed on your development system.  It is
> | installed in /usr/local as usual.  You've been working on fixing a bug,
> | and have written a unit test which exercises the relevant code and
> | verified that it can deterministically trigger the bug.  You fix the bug
> | and 'make check' again, all green.  Then you clean out your working
> | copy, re-run configure with CC=gcc and 'make check' again.  Your tests
> | fail.
> |
> | What happened is that when you built your code with gcc, the tests were
> | linked and run with the stable version of the library, where the bug is
> | not fixed.  You can build with LDFLAGS=-L$(top_builddir)/lib, you can
> | even specify the full path to the library in LDADD for each individual
> | test, it doesn't matter.  It will *always* pick the installed version
> | first.  The only way to get your tests to pass is to not have the
> | library installed.
> |
> | Real-world example - a 10.3 system with upstream OpenPAM installed
> | because it uses OpenPAM's OATH implementation:
> |
> | with base clang:
> |
> | des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
> | /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
> | libpam.so.2 => /home/des/src/openpam/trunk/lib/libpam/.libs/libpam.so.2 (0x800822000)
> | liboath.so.2 => /home/des/src/openpam/trunk/lib/liboath/.libs/liboath.so.2 (0x800a34000)
> | libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
> | libc.so.7 => /lib/libc.so.7 (0x80102f000)
> |
> | with lang/gcc:
> |
> | des@desk ~/src/openpam/trunk% pkg which =gcc
> | /usr/local/bin/gcc was installed by package gcc-4.8.5_2
> | des@desk ~/src/openpam/trunk% libtool exec ldd ./t/t_openpam_dispatch
> | /home/des/src/openpam/trunk/t/.libs/t_openpam_dispatch:
> | libpam.so.2 => /usr/local/lib/libpam.so.2 (0x800822000)
> | liboath.so.2 => /usr/local/lib/liboath.so.2 (0x800a34000)
> | libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c39000)
> | libc.so.7 => /lib/libc.so.7 (0x80102f000)
> | libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x8013dc000)
> | libthr.so.3 => /lib/libthr.so.3 (0x8017e9000)
> |
> | (and don't ask me why the gcc version is linked with two different
> | versions of libcrypto!)

Here you can probably get things working by adding -Wl,--enable-new-dtags
to LDFLAGS in the configure script (or to AM_LDFLAGS in Makefile.am).
Clang runs ld(1) with this flag by default, gcc does not.  With clang the
program has DT_RUNPATH /usr/local/lib, which rtld(1) checks after
LD_LIBRARY_PATH, and with gcc the program has DT_RPATH /usr/local/lib which
rtld checks *before* LD_LIBRARY_PATH.

(The gold(1) linker also enables this flag by default.)

The reason it links to libcrypto twice is because liboath.so.2 pulls in
libcrypto.so.7 while gcc has linked libpam with libcrypto.so.8 because of
the implicit -L/usr/local/lib.

> 3)
>
> | I honestly thought this was a recent change, but I realize now that the
> | recent change is that I switched from developing on systems that still
> | had gcc in base (without /usr/local in the search path) to systems that
> | don't, and therefore use gcc from ports.
> |
> | The correct solution, in my opinion, is to remove /usr/local from all
> | search paths.  There is no need for it, even for ports, because most
> | ports add /usr/local to CPPFLAGS and LDFLAGS, either explicitly or
> | implicitly (by passing --prefix=${LOCALBASE} to the configure script).
> | If there are gcc-only ports which *don't* do it, they can easily be
> | fixed.

I agree.

> | I initially thought that merely changing the library search order would
> | be sufficient, but apparently gcc somehow forces /usr/local/lib to take
> | precedence even over ${LD_LIBRARY_PATH}, which is what causes my unit
> | tests to fail.  Here is an example from another project where I modified
> | the libtool wrapper to show its environment and run ldd before executing
> | the binary:
> |
> | des@desk ~/src/cryb-to% ./t/t_core
> | PATH=/home/des/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
> | LD_LIBRARY_PATH=/home/des/src/cryb-to/lib/test/.libs:/home/des/src/cryb-to/lib/core/.libs
> | /home/des/src/cryb-to/t/.libs/t_core:
> | libcryb-test.so.0 => /usr/local/lib/libcryb-test.so.0 (0x80081f000)
> | libcryb-core.so.0 => /usr/local/lib/libcryb-core.so.0 (0x800a26000)
> | libc.so.7 => /lib/libc.so.7 (0x800c2a000)
> | 1..2
> | not ok 1 - version
> | ok 2 - no memory leaked
> |
> | This is a skeleton test which only verifies that the library it's linked
> | with has the same version as the one it was compiled with.  Here's the
> | same test, with the same modifications, built with clang:
> |
> | des@desk ~/src/cryb-to% ./t/t_core  
> | PATH=/home/des/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
> | LD_LIBRARY_PATH=/home/des/src/cryb-to/lib/test/.libs:/home/des/src/cryb-to/lib/core/.libs
> | /home/des/src/cryb-to/t/.libs/t_core:
> | libcryb-test.so.0 => /home/des/src/cryb-to/lib/test/.libs/libcryb-test.so.0 (0x80081f000)
> | libcryb-core.so.0 => /home/des/src/cryb-to/lib/core/.libs/libcryb-core.so.0 (0x800a27000)
> | libc.so.7 => /lib/libc.so.7 (0x800c2c000)
> | 1..2
> | ok 1 - version
> | ok 2 - no memory leaked
> |
> | Please understand that the *only* way I can think of to work around this
> | is to set --nostdinc and --nostdlib and explicitly pass the correct
> | search path and list of libraries (-lgcc -lc) to gcc, and even then I'm
> | not sure it would work.  I don't find that reasonable at all.
> |
> | Note that I am not sure whether this problem is limited to gcc or if ld
> | is also involved.  The iconv problem which I originally reported is
> | caused by gcc picking up iconv.h from /usr/local/include instead of over
> | /usr/include, but I'm not sure whether the linking problem is caused by
> | gcc passing its search path on to ld, or to ld having its own incorrect
> | search path.  I tried explicitly setting LD=/usr/bin/ld, but that
> | doesn't make any difference since libtool uses gcc as a linker instead
> | of calling ${LD} directly.

Note that -rpath /usr/local/lib isn't added by gcc but by libtool
because it assumes rtld will not search that directory automatically.
If you run './configure CC=gcc --prefix=/usr && make check' the tests
should succeed (without --enable-new-dtags) because -rpath isn't used
then.

You can examine rpath differences with 'objdump -p program | grep PATH'.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
12
Loading...