FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
games/lm-solve  | 0.8.4   | 0.10.1
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

INDEX build failed for 10.x

[Ports Index build]

INDEX build failed with errors:
Generating INDEX-10 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---
--- describe.astro ---
--- describe.audio ---
--- describe.benchmarks ---
--- describe.biology ---
--- describe.cad ---
--- describe.chinese ---
--- describe.comms ---
--- describe.converters ---
--- describe.databases ---
--- describe.deskutils ---
--- describe.devel ---
--- describe.dns ---
--- describe.editors ---
--- describe.emulators ---
--- describe.finance ---
--- describe.french ---
--- describe.ftp ---
[...]
--- describe.print ---
--- describe.russian ---
--- describe.science ---
--- describe.security ---
--- describe.shells ---
--- describe.sysutils ---
--- describe.textproc ---
--- describe.ukrainian ---
--- describe.vietnamese ---
--- describe.www ---
--- describe.x11 ---
--- describe.x11-clocks ---
--- describe.x11-drivers ---
--- describe.x11-fm ---
--- describe.x11-fonts ---
--- describe.x11-servers ---
--- describe.x11-themes ---
--- describe.x11-toolkits ---
--- describe.x11-wm ---
 Done.
make_index: /home/indexbuild/tindex/ports/math/vtk6: no entry for 
/home/indexbuild/tindex/ports/devel/libc++

Committers on the hook:
 bjk stephen 

Most recent SVN update was:
Updating '.':
Unet/openafs/Makefile
Unet/openafs/distinfo
Unet/openafs/files/patch-configure
Unet/openafs/files/patch-doc-man-pages-Makefile.in
Unet/openafs/files/patch-src-packaging-FreeBSD-Makefile.man
Unet/openafs/files/patch-src-rx-rx_kernel.h
Unet/openafs/files/patch-src__kauth__Makefile.in
Unet/openafs/pkg-plist
Umath/vtk6/Makefile
Amath/vtk6/files/patch-ThirdParty_hdf5_vtkhdf5_CMakeInstallation.cmake
Updated to revision 435820.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Benjamin Kaduk]

On Thu, Mar 09, 2017 at 12:35:32PM +0100, Tijl Coosemans wrote:
> 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.

Sounds like a bug in the libtool packaging, then?

-Ben
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Issue with re-installation of bash and Sudo ...

[Miroslav Lachman]

Uma Somasundaram wrote on 2017/03/09 07:13:

Hi ,


I have upgraded FF version from : 24.3.0_2,1 -> 45.6.0_3,1 in
Free BSD 9.2 version,

How do I reinstall the Sudo or bash? which I lost after the Browser upgrade
,
While adding the package Iam getting below error ,


FreeBSD 9.2 is unsupported version sou old packages are no longer 
available. You should upgrade your system to 10.3 or 11.0 and then 
upgrade all installed packages.


Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Issue with re-installation of bash and Sudo ...

[Walter Schwarzenfeld]

Sometimes the dependencies not proper cleaned. Try make clean-depends.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[John Baldwin]

On Wednesday, March 08, 2017 04:39:50 PM Dag-Erling Smørgrav wrote:
> Baptiste Daroussin  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...

+1 on all these.  I think that ports compilers should not have
/usr/local/include or /usr/local/lib as implicit paths either as others
have stated.

I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
so long as our default MANPATH included both if that means applying fewer
patches to ports.

-- 
John Baldwin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Anton Yuzhaninov]

On 03/06/17 18:56, Baptiste Daroussin wrote:

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.


1. During transition period having two trees for man pages - 
/usr/local/share/man and /usr/share/man will be additional headache.


2. When /usr/local/man will be removed some ports should be patched to 
use /usr/local/share/man instead /usr/local/man and we almost back to 
square one (with fewer ports to patch).


3. Patching man path is trivial comparing other challenges during 
porting software to FreeBSD. For me current situation with man path is 
not a big issue.


4. Linux Filesystem Hierarchy Standard has

/usr/share/man
but
/usr/local/man

Given all above I don't think this change is worth benefits it will have.

Also when/if you will add /usr/local/share/man, please submit patch to 
cmake:

https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/GNUInstallDirs.cmake#L273
Currently cmake defines CMAKE_INSTALL_MANDIR to $PREFIX/man on FreeBSD.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Best way to cause synth to ignore rebuilding of a port??

[Bob Willcox]

On Wed, Mar 08, 2017 at 10:21:55PM -0600, Matthew D. Fuller wrote:
> On Wed, Mar 08, 2017 at 03:13:37PM -0600 I heard the voice of
> Bob Willcox, and lo! it spake thus:
> > 
> > Hmm, the plugin/addon I use and would be lost without is for tab
> > groups.  Do they still work in 52?
> 
> I'm pretty sure it's 57 (or 58?) that they're getting broken.
> Certainly they work fine here on the current 52 out of ports.

That's good to know. If/when tab groups don't work any longer is when I stop
updating firefox. They are the thing miss the most when using other browsers.

> 
> 
> -- 
> Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
>On the Internet, nobody can hear you scream.

-- 
Bob Willcox| If a program is useful, it will be changed.
b...@immure.com |
Austin, TX |
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Dimitry Andric]

On 9 Mar 2017, at 09:29, Dag-Erling Smørgrav  wrote:
...
> 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 
> | 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.

Please pin this email for re-use the next time a discussion is started
about adding /usr/local to the default include and library paths for the
base system compiler...  It's been more than a year now, so I expect
it to be regurgitated any time soon. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: manpath change for ports ?

[Dag-Erling Smørgrav]

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

I didn't have -I/usr/local/include, gcc forced it on me.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Tijl Coosemans]

On Thu, 09 Mar 2017 09:29:42 +0100 Dag-Erling Smørgrav  wrote:
> Tijl Coosemans  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 , 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 
> | 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 

Re: Writing a port that simply installs a bunch of files

[Matthew Seaman]

On 2017/03/09 10:58, Andrea Venturoli wrote:
> Now files have correct permissions, owner and group in ${STAGEDIR};
> however the group is lost in ${PREFIX} after "make install".
> 
> Is specifying "@group" in pkg-plist the only way to keep that?

Yes, you need to specify what user or group ownership and what
permissions you want for files within the pkg-plist.  Unless they should
have the default root:wheel ownership and mode 755 for dirs and
executables or 644 for data and other non-executable files.

That's because the ports will build software, install it to staging and
create a package from it as a non-root user.  So the ownership and modes
of files in staging may well be nothing like what the files should have
when installed in production.  With the exception that the execute
permission bit setting does seem to be derived from what's in staging.
If that seems annoyingly inconsistent to you, consider what it would
take to update all of the pkg-plist files or equivalent port Makefile
entries to explicitly set the file modes for every executable that might
be installed by the ports, and to get there from here without breaking
everything while that work is in progress.

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: manpath change for ports ?

[scratch65535]

On Wed, 8 Mar 2017 20:47:31 -0800, Kevin Oberman
 wrote:

>On Wed, Mar 8, 2017 at 12:35 PM,  wrote:
>
>> On Tue, 7 Mar 2017 00:56:10 +0100, 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
>>
>> I would argue that the same principle should be followed with
>> *everything*:  if it's at or applies to the application level, it
>> should be in /usr/local/, no exceptions.
>>
>> And if that conflicts with the native product documentation (e.g.
>> MySQL, MariaDB), the local mods should be right up at the top of
>> the relevant man page, not on some special web site or in some
>> special documentation hiding in the weeds somewhere.  Nobody
>> should have to chase down necessary information; if the man pages
>> are the canonical documentation, then all the facts should be on
>> the man page.
>>
>> And if something is not at the application level, then perhaps
>> this is the right time and place to have a conversation about
>> whether there should be a separate subtree for the layer between
>> the apps and the kernel, too.
>>
>> The desire for long-term stability, predictability, and freedom
>> from bugs is not a joke or a wish for a pony.  It's a basic
>> sine-qua-non necessity for production-quality software,
>> especially servers.   Would splitting off the middle layer from
>> the kernel help or hinder that goal?  The question must be worth
>> a conversation, and the sooner the better.
>>
>
>Wait a second! I don't think Bapt or anyone else was suggesting that ports
>install in any part of the tree other than /usr/local. Tr-read what he said.
>
>The discussion is whether to move from /usr/local/man to
>/usr/local/share/man as well as other directories that normally in
>/usr/[share|info||libexe] under Linux systems.

I wasn't suggesting that Bapt or anyone was suggesting that,
honest.  

I'm only arguing for greater consistency and simplicity than is
now the case.

Anyone who looks at fbsd (unix) from a human-factors standpoint
sees an incoherent picture made up of the (joking-but-not-
really-funny) "a phd hack, three master's theses, and a thousand
undergraduate term projects".  It lacks integrity and simplicity,
and consequently is needlessly hard to use, hard to maintain,
hard to love, and impossible to promote to the larger world.

We shouldn't be doing *anything* for the sake of consistency with
linux.  No change should be made for any reason other than the
result would be obviously *better* from a human-factors
standpoint.  If that means we steal some stuff from linux, fine. 
But doing anything for the sake of being "more like linux" is
barking nuts!  Linux is already as much like linux as anything
can be, so if our only goal is to make fbsd "more like linux",
then let's just grab a copy of some linux distro and call it
fbsd.  Voila!, instant 100% linux compatibility with 99.999% less
work.  Everyone could relax!

But that would be a going-out-of-business strategy, and I'm
certainly not suggesting it seriously.

What we should be doing for real is moving toward *replacing*
linux AND windows.  Make *them* go obsolete by becoming
less-obnoxious and more understandable.  We're already sturdier.

And a nice first step would be to start cleaning up the craziness
in the tree by moving *all* the apps-layer stuff to /usr/local.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Writing a port that simply installs a bunch of files

[Andrea Venturoli]

On 03/06/17 17:45, Andrea Venturoli wrote:


post-install:
@${TAR} -xf ${FILESDIR}/input.tgz -C ${STAGEDIR}
@${FIND} ${STAGEDIR} -type f | \
${SED} "s|^${STAGEDIR}||" >> ${TMPPLIST}

.include 


Guess this is what I was looking for (just the ${TAR} part)... basically
overriding the "extract" phase.
I modified ${STAGEDIR} to ${STAGEDIR}/${PREFIX}.


That should be "${STAGEDIR}${PREFIX}", anyway.

Now files have correct permissions, owner and group in ${STAGEDIR}; 
however the group is lost in ${PREFIX} after "make install".


Is specifying "@group" in pkg-plist the only way to keep that?

 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Dag-Erling Smørgrav]

jbe...@freebsd.org (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 - d...@des.no
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: manpath change for ports ?

[Dag-Erling Smørgrav]

Tijl Coosemans  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 , 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 
| 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
| 

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
graphics/opencollada| 1.6.37  | v1.6.43
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"