Gentoo Forums :: View topic

gcc upgrade

View unanswered posts
View posts from last 24 hours

Goto page 1, 2 Next

Gentoo Forums Forum Index

Portage & Programming

View previous topic :: View next topic

Author

Message

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Mon Mar 12, 2018 12:44 am Post subject: gcc upgrade

Hi, ALL,
I recently upgraded one of my laptops from KDE4 to KDE5. I also updated gcc from version 5.4 to 6.4.0.
Unfortunately the gcc upgrade broke the compilation of my program:

Code:

/home/igor/wxWidgets/include/wx/math.h:95:31: error: 'isnan' was not declared in this scope
#define wxIsNaN(x) isnan(x)

Is there anything I can do besides defining the macro myself? Does it fixed in more recent version of gcc headers?

Thank you.

ali3nx
l33t
l33t

Joined: 21 Sep 2003
Posts: 722
Location: Winnipeg, Canada

Posted: Mon Mar 12, 2018 12:49 am Post subject: Re: gcc upgrade

ONEEYEMAN wrote:

I also updated gcc from version 5.4 to 6.4.0.

Did you do a full world rebuild after the gcc 6.4 update? How long has it been since you recompiled your entire install?

I'm immediately unable to locate the gentoo news advisory regarding the gcc 6.4 update however you might also check which portage profile your using. If you switched to the 17.0 portage profile and did not rebuild world that would cause some quirky toolchain issues as the 17.0 profile defaults to -fPIE gcc. the -fPIE gcc default may be an additional complication you may need to address in your code.

https://bpaste.net/show/fd5f5817ec6a

I vagely recall from when I initially upgraded to gcc 6 that certain version of wxwidgets wouldn't compile or cooperate with gcc 6.
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper!

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Mon Mar 12, 2018 1:07 am Post subject:

Hi, No, I did't. Just recompiled libtool as explained in this. Do I have to? Thank you.

ali3nx
l33t
l33t

Joined: 21 Sep 2003
Posts: 722
Location: Winnipeg, Canada

Posted: Mon Mar 12, 2018 1:17 am Post subject:

ONEEYEMAN wrote:

Hi,
No, I did't. Just recompiled libtool as explained in this.

Do I have to?

Thank you.

Being an old hat with gentoo doing redundant things like world rebuilds when something unusual really doesn't want to cooperate i find fixes many annoyances. System consistency throughout by rebuilding world time to time has for me been an overall benefit. A Gentoo install is akin to a Jenga tower. if the bottom is unsteady the top will surely become worse.

If you've never done a full world rebuild with your current install it may be worth considering or potentially be overdue and be necessary with the 17.0 profile update. there has been two major gcc ABI upgrades within the past three years as well as -fstack-protector defaults in toolchain since gcc 4.7 and -fpie added to default with 17.0 profile in gcc 6.4.

Code:

[2] N 2014-06-15 GCC 4.8.3 defaults to -fstack-protector
[3] N 2014-10-26 GCC 4.7 Introduced the New C++11 ABI
[4] N 2015-02-02 New portage plug-in sync system
[5] N 2015-07-25 Python 3.4 enabled by default
[6] N 2015-08-13 OpenSSH 7.0 disables ssh-dss keys by default
[7] N 2015-10-22 GCC 5 Defaults to the New C++11 ABI

Only rebuilding libtool may be insufficient depending on how long it's been since you did a world consistency rebuild and the 17.0 portage profile update requires a full world rebiuld anyways for -fpie toolchain defaults
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper!

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Mon Mar 12, 2018 1:39 am Post subject:

Hi, What is the best way to recompile world? Thank you.

ali3nx
l33t
l33t

Joined: 21 Sep 2003
Posts: 722
Location: Winnipeg, Canada

Posted: Mon Mar 12, 2018 1:49 am Post subject:

ONEEYEMAN wrote:

Hi,
What is the best way to recompile world?
Thank you.

If you are considering a world rebuild changing to the 17.0 portage profile before a world rebuild would be ideal. ensure your system is fully updated before changing profiles. i find doing this eliminates any potential inconsistency issues that could arise due to differences in portage profiles.

1) Complete any outstanding world updates with emerge -uDN world (check beforehand with emerge -uDNpv world)

2) Switch your portage profile to the appropriate 17.0 portage profile closest matching your current in use system portage profile using eselect profile <foo>

This gentoo install i'm currently tinkering with uses kde plasma and systemd.

Code:

avatar ~ # eselect profile list
Available profile symlink targets:
[1] default/linux/amd64/13.0 (stable)
[2] default/linux/amd64/13.0/selinux (dev)
[3] default/linux/amd64/13.0/desktop (stable)
[4] default/linux/amd64/13.0/desktop/gnome (stable)
[5] default/linux/amd64/13.0/desktop/gnome/systemd (stable)
[6] default/linux/amd64/13.0/desktop/plasma (stable)
[7] default/linux/amd64/13.0/desktop/plasma/systemd (stable)
[8] default/linux/amd64/13.0/developer (stable)
[9] default/linux/amd64/13.0/no-multilib (stable)
[10] default/linux/amd64/13.0/systemd (stable)
[11] default/linux/amd64/13.0/x32 (dev)
[12] default/linux/amd64/17.0 (stable)
[13] default/linux/amd64/17.0/selinux (stable)
[14] default/linux/amd64/17.0/hardened (stable)
[15] default/linux/amd64/17.0/hardened/selinux (stable)
[16] default/linux/amd64/17.0/desktop (stable)
[17] default/linux/amd64/17.0/desktop/gnome (stable)
[18] default/linux/amd64/17.0/desktop/gnome/systemd (stable)
[19] default/linux/amd64/17.0/desktop/plasma (stable)
[20] default/linux/amd64/17.0/desktop/plasma/systemd (stable) *
[21] default/linux/amd64/17.0/developer (stable)
[22] default/linux/amd64/17.0/no-multilib (stable)
[23] default/linux/amd64/17.0/no-multilib/hardened (stable)
[24] default/linux/amd64/17.0/no-multilib/hardened/selinux (stable)
[25] default/linux/amd64/17.0/systemd (stable)
[26] default/linux/amd64/17.0/x32 (dev)
[27] default/linux/amd64/17.1 (exp)
[28] default/linux/amd64/17.1/selinux (exp)
[29] default/linux/amd64/17.1/hardened (exp)
[30] default/linux/amd64/17.1/desktop (exp)
[31] default/linux/amd64/17.1/desktop/gnome (exp)
[32] default/linux/amd64/17.1/desktop/gnome/systemd (exp)
[33] default/linux/amd64/17.1/desktop/plasma (exp)
[34] default/linux/amd64/17.1/desktop/plasma/systemd (exp)
[35] default/linux/amd64/17.1/developer (exp)
[36] default/linux/amd64/17.1/no-multilib (exp)
[37] default/linux/amd64/17.1/no-multilib/hardened (exp)
[38] default/linux/amd64/17.1/no-multilib/hardened/selinux (exp)
[39] default/linux/amd64/17.1/systemd (exp)
[40] hardened/linux/amd64 (stable)
[41] hardened/linux/amd64/selinux (stable)
[42] hardened/linux/amd64/no-multilib (stable)
[43] hardened/linux/amd64/no-multilib/selinux (stable)
[44] hardened/linux/amd64/x32 (dev)
[45] default/linux/musl/amd64 (exp)
[46] hardened/linux/musl/amd64 (exp)
[47] default/linux/musl/amd64/x32 (exp)
[48] hardened/linux/musl/amd64/x32 (exp)
[49] default/linux/amd64/17.0/musl (exp)
[50] default/linux/amd64/17.0/musl/hardened (exp)
[51] default/linux/uclibc/amd64 (exp)
[52] hardened/linux/uclibc/amd64 (exp)

3) After switching the portage profile follow the directions in the portage news advisory about proceeding with the gcc 6.4/17.0 portage profile updgrade. as you have already rebuilt libtool you may be able to skip this step or do the redundant thing for added assurance because doing redundant things with Gentoo i've discoverd has benefits

Code:

2017-11-30-new-17-profiles
Title New 17.0 profiles in the Gentoo repository
Author Andreas K. Hüttel <dilfridge@gentoo.org>
Posted 2017-11-30
Revision 1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
This change is mostly relevant to Gentoo developers. It also
means, however, that compilers earlier than GCC 6 are masked
and not supported for use as a system compiler anymore. Feel
free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
executables (PIE) by default. This improves the overall
security fingerprint. The switch from non-PIE to PIE binaries,
however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
profile tree. Now they are moving into the 17.0 profile
as a feature there, similar to "no-multilib" and "systemd".

Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps:
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
. /etc/profile
* Re-emerge libtool
emerge -1 sys-devel/libtool
Then,
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
emerge -1 sys-devel/gcc:6.4.0
emerge -1 sys-devel/binutils
emerge -1 sys-libs/glibc
* Rebuild your entire system
emerge -e @world

Switching the profile from 13.0 to 17.0 modifies the settings of
GCC 6 to generate PIE executables by default; thus, you need to do
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.

4) After the 17.0 profile upgrade steps are completed run emerge -e world to recompile everything with the new -FPIE toolchain defaults
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper!

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21631

Posted: Mon Mar 12, 2018 3:30 am Post subject:

Why do you believe this to be a gcc bug? Are you sure that the proper header for isnan is included in that translation unit?

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Mon Mar 12, 2018 10:13 pm Post subject:

Hi,
Doing the very first step fails:

Code:

IgorDellGentoo /home/igor/dbhandler # emerge baselayout
* Last emerge --sync was 112d 4h 51m 19s ago.

* IMPORTANT: 2 config files in '/etc/portage' need updating.
* See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
* sections of the emerge man page to learn how to update config files.
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-apps/baselayout-2.4.1-r2::gentoo
* baselayout-2.4.1.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
* Converting /usr/local/lib from a dir to a symlink
* ERROR: sys-apps/baselayout-2.4.1-r2::gentoo failed (setup phase):
* non-empty dir found where we needed a symlink: /usr/local/lib
*
* Call stack:
* ebuild.sh, line 124: Called pkg_setup
* baselayout-2.4.1-r2.ebuild, line 18: Called multilib_layout
* baselayout-2.4.1-r2.ebuild, line 67: Called die
* The specific snippet of code:
* die "non-empty dir found where we needed a symlink: ${prefix}lib"
*
* If you need support, post the output of `emerge --info '=sys-apps/baselayout-2.4.1-r2::gentoo'`,
* the complete build log and the output of `emerge -pqv '=sys-apps/baselayout-2.4.1-r2::gentoo'`.
* The complete build log is located at '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/temp/die.env'.
* Working directory: '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/homedir'
* S: '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/work/baselayout-2.4.1'

>>> Failed to emerge sys-apps/baselayout-2.4.1-r2, Log file:

>>> '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/temp/build.log'

* Messages for package sys-apps/baselayout-2.4.1-r2:

* Converting /usr/local/lib from a dir to a symlink
* ERROR: sys-apps/baselayout-2.4.1-r2::gentoo failed (setup phase):
* non-empty dir found where we needed a symlink: /usr/local/lib
*
* Call stack:
* ebuild.sh, line 124: Called pkg_setup
* baselayout-2.4.1-r2.ebuild, line 18: Called multilib_layout
* baselayout-2.4.1-r2.ebuild, line 67: Called die
* The specific snippet of code:
* die "non-empty dir found where we needed a symlink: ${prefix}lib"
*
* If you need support, post the output of `emerge --info '=sys-apps/baselayout-2.4.1-r2::gentoo'`,
* the complete build log and the output of `emerge -pqv '=sys-apps/baselayout-2.4.1-r2::gentoo'`.
* The complete build log is located at '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/temp/die.env'.
* Working directory: '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/homedir'
* S: '/var/tmp/portage/sys-apps/baselayout-2.4.1-r2/work/baselayout-2.4.1'

Should I post more? Or this looks familiar?

Thank you.

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Mon Mar 12, 2018 11:57 pm Post subject:

Hu, Because everything was compiling properly on gcc 5.4. Thank you.

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Tue Mar 13, 2018 12:45 am Post subject:

Interesting,

Code:

tony@CASTI ~/test $ cat test.c
#include <math.h>

int main ()
{
if (isnan(3.0)) return 3;
if (_isnan(4.0)) return 4;
if (__isnan(5.0)) return 1;
return 0;
}
tony@CASTI ~/test $ gcc test.c
test.c: In function 'main':
test.c:6:5: warning: implicit declaration of function '_isnan'; did you mean 'isnan'? [-Wimplicit-function-declaration]
if (_isnan(4.0)) return 4;
^~~~~~
isnan
/tmp/ccXouxq2.o: In function `main':
test.c:(.text+0x1e): undefined reference to `_isnan'
collect2: error: ld returned 1 exit status

So isnan with no underscore is OK and isnan with two underscores is OK, but not with one underscore.

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Tue Mar 13, 2018 12:49 am Post subject:

On another system with an old old gcc:

Code:

k6 ~/test # gcc test.c
/tmp/ccK9t8sU.o: In function `main':
test.c:(.text+0x21): undefined reference to `_isnan'
collect2: error: ld returned 1 exit status
k6 ~/test # gcc-config -l
[1] i486-pc-linux-gnu-4.8.4
[2] i486-pc-linux-gnu-4.9.4 *

Looks more like a bug in wxwidgets to me. They should be defining their alias as either isnan or __isnan, but not _isnan.
Unless some other include defines _isnan as isnan or __isnan.

It's not C vs C++ and a standard change either:

Code:

k6 ~/test # g++ -std=gnu++98 test.cpp
test.cpp: In function 'int main()':
test.cpp:6:15: error: '_isnan' was not declared in this scope
if (_isnan(4.0)) return 4;

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Tue Mar 13, 2018 1:08 am Post subject:

Hu wrote:

Why do you believe this to be a gcc bug? Are you sure that the proper header for isnan is included in that translation unit?

Hu, when I grepped for isnan, the headers installed by gentoo all defined the WX version to _isnan. Oneeyedman's header, correctly defining to isnan without an underscore is in his local directory.

I admit I have not reinstalled WxGTK for a long time, but I do do eix-sync && emerge -auvND weekly.

wxwidgets is such a blizzard of macros that it might be hard to figure out what is going on. If I have time, I will build a test file using a wxwidgets developtool like wxdev++ or codeblocks and see if it behaves differently.

But it's not a gcc bug, unless maybe a documentation bug that should have been listed in the change list.

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21631

Posted: Tue Mar 13, 2018 1:59 am Post subject:

ONEEYEMAN wrote:

Code:

To save asturm the trouble (and because I agree with him): you should address these before you proceed. Portage calls them out for a reason.

ONEEYEMAN wrote:

Code:

* Converting /usr/local/lib from a dir to a symlink
* ERROR: sys-apps/baselayout-2.4.1-r2::gentoo failed (setup phase):
* non-empty dir found where we needed a symlink: /usr/local/lib

That is enough. Based on the error message, you have a problem with your /usr/local. What is the output of ls -l /usr/local{,/lib/}?

ONEEYEMAN wrote:

Because everything was compiling properly on gcc 5.4.

What does that prove? Compiler bugs get fixed. Compilers change behaviors when not constrained by the standard. Based on the information in this thread, my analysis would be that:

The translation unit in question includes some gcc-provided header H.
In gcc-5.4, H happens to include <cmath> or similar as an implementation detail. The standard did not require H to include <cmath>.
In gcc-6.4, H no longer includes <cmath>. Perhaps it was never needed. Perhaps some change in H removed the need for it. Regardless, if the standard does not require H to include <cmath>, it's not a compiler bug that gcc-6.4 no longer incidentally includes <cmath> via H.

I do not dispute that isnan is the proper name. I question whether the author of that file has followed the standard-prescribed method (including <cmath> or appropriate) for making that symbol available in this translation unit.

Tony0945 wrote:

Hu, when I grepped for isnan, the headers installed by gentoo all defined the WX version to _isnan. Oneeyedman's header, correctly defining to isnan without an underscore is in his local directory.

The compiler ought not be reporting an error for the #define using a symbol, since the symbol is not used in the C phase until that #define is expanded somewhere. I suspect that the original error was paraphrased a bit.

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Tue Mar 13, 2018 3:03 am Post subject:

Hu wrote:

I assumed that the macro was used somewhere in the code for that reason. I did find the single underscore in wxGTK-2.8.11, wxGTK-2.9 and wxGTK-3.0
I don't understand why I can't find it anywhere else on my system. I'm thinking that it is a little used macro, just giving a different name to a little used function (in 40 years of C programming I never ran across it) or perhaps it has a single underscore on OSX or Windows since wxwidgets is a multi-platform suite.

ali3nx
l33t
l33t

Joined: 21 Sep 2003
Posts: 722
Location: Winnipeg, Canada

Posted: Tue Mar 13, 2018 3:36 am Post subject:

ONEEYEMAN wrote:

Hi,
Doing the very first step fails:

Code:

IgorDellGentoo /home/igor/dbhandler # emerge baselayout
* Last emerge --sync was 112d 4h 51m 19s ago.

This may be something needing an update as well

Also thanks to Hu and Tony for the assist with many things toolchain I've not understood with as much depth.
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper!

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Tue Mar 13, 2018 3:24 pm Post subject:

test program:

Code:

#include <wx/init.h>
#include <wx/math.h>

int main(int argc, char **argv)
{
wxInitializer init;

double x;
if ( wxIsNaN(x) ) return 1;

return 0;
}

results:

Code:

MSI test # g++ `wx-config --cxxflags` -o out *.cpp `wx-config --libs`
MSI test #

No error! That's with gcc-6.4.0

Code:

MSI test # grep -r wxIsNaN /usr/include
/usr/include/wx-3.0-gtk3/wx/math.h: #define wxIsNaN(x) std::isnan(x)
/usr/include/wx-3.0-gtk3/wx/math.h: #define wxIsNaN(x) _isnan(x)
/usr/include/wx-3.0-gtk3/wx/math.h: #define wxIsNaN(x) isnan(x)
/usr/include/wx-3.0-gtk3/wx/math.h: #define wxIsNaN(x) ((x) != (x))
/usr/include/wx-3.0/wx/math.h: #define wxIsNaN(x) std::isnan(x)
/usr/include/wx-3.0/wx/math.h: #define wxIsNaN(x) _isnan(x)
/usr/include/wx-3.0/wx/math.h: #define wxIsNaN(x) isnan(x)
/usr/include/wx-3.0/wx/math.h: #define wxIsNaN(x) ((x) != (x))
/usr/include/wx-2.8/wx/math.h: #define wxIsNaN(x) _isnan(x)
/usr/include/wx-2.8/wx/math.h: #define wxIsNaN(x) isnan(x)
/usr/include/wx-2.8/wx/math.h: #define wxIsNaN(x) ((x) != (x))

Multiple definitions! Only _isnan should fail.
std:isnan definition is in a block "#if __cplusplus >= 201103" #else /* C++98 */

Aha! Failing (on Gentoo) definition is HERE:

Code:

#if defined(__VISUALC__)||defined(__BORLAND__)
#define wxIsNaN(x) _isnan(x)
#elif defined(__GNUG__)||defined(__GNUWIN32__)||defined(__DJGPP__)|| \
defined(__SGI_CC__)||defined(__SUNCC__)||defined(__XLC__)|| \
defined(__HPUX__)
#define wxIsNaN(x) isnan(x)
#else
#define wxIsNaN(x) ((x) != (x))
#endif

#endif /* C++11/C++98 */

So, it's for Windows.

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Tue Mar 13, 2018 3:27 pm Post subject:

ONEEYEMAN, your local copy of wxwidgets in your home directory is out of date/broken. emerge a copy from the tree and junk your local copy.

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Thu Mar 15, 2018 12:36 am Post subject:

Hu,

Code:

IgorDellGentoo /home/igor/dbhandler # ls -la /usr/local
total 28
drwxr-xr-x 7 root root 4096 Mar 16 2016 .
drwxr-xr-x 14 root root 4096 Apr 7 2016 ..
drwxr-xr-x 2 root root 4096 Nov 25 05:32 bin
drwxr-xr-x 19 root root 4096 Jul 30 2016 include
drwxr-xr-x 2 root root 4096 Nov 25 05:32 lib
drwxr-xr-x 2 root root 4096 May 28 2014 sbin
drwxr-xr-x 7 root root 4096 Mar 16 2016 share

IgorDellGentoo /home/igor/dbhandler # ls -la /usr/local/lib
total 113568
drwxr-xr-x 2 root root 4096 Nov 25 05:32 .
drwxr-xr-x 7 root root 4096 Mar 16 2016 ..
-rw-r--r-- 1 root root 8 Nov 25 05:32 libdbinterface.a
-rw-r--r-- 1 root root 961562 Nov 25 05:32 libdbloader.a
-rwxr-xr-x 1 root root 1446 Nov 25 05:32 libdbloader.la
lrwxrwxrwx 1 root root 20 Nov 25 05:32 libdbloader.so -> libdbloader.so.0.0.0
lrwxrwxrwx 1 root root 20 Nov 25 05:32 libdbloader.so.0 -> libdbloader.so.0.0.0
-rwxr-xr-x 1 root root 632512 Nov 25 05:32 libdbloader.so.0.0.0
-rw-r--r-- 1 root root 17033626 Nov 25 05:32 libdbwindow.a
-rwxr-xr-x 1 root root 1475 Nov 25 05:32 libdbwindow.la
lrwxrwxrwx 1 root root 20 Nov 25 05:32 libdbwindow.so -> libdbwindow.so.0.0.0
lrwxrwxrwx 1 root root 20 Nov 25 05:32 libdbwindow.so.0 -> libdbwindow.so.0.0.0
-rwxr-xr-x 1 root root 5157704 Nov 25 05:32 libdbwindow.so.0.0.0
-rw-r--r-- 1 root root 13065538 Nov 25 05:32 libdialogs.a
-rwxr-xr-x 1 root root 1637 Nov 25 05:32 libdialogs.la
lrwxrwxrwx 1 root root 19 Nov 25 05:32 libdialogs.so -> libdialogs.so.0.0.0
lrwxrwxrwx 1 root root 19 Nov 25 05:32 libdialogs.so.0 -> libdialogs.so.0.0.0
-rwxr-xr-x 1 root root 4259704 Nov 25 05:32 libdialogs.so.0.0.0
-rw-r--r-- 1 root root 1850622 Nov 25 05:32 libfieldswindow.a
-rwxr-xr-x 1 root root 1225 Nov 25 05:32 libfieldswindow.la
lrwxrwxrwx 1 root root 24 Nov 25 05:32 libfieldswindow.so -> libfieldswindow.so.0.0.0
lrwxrwxrwx 1 root root 24 Nov 25 05:32 libfieldswindow.so.0 -> libfieldswindow.so.0.0.0
-rwxr-xr-x 1 root root 758488 Nov 25 05:32 libfieldswindow.so.0.0.0
-rw-r--r-- 1 root root 1635576 Nov 25 05:32 libmysql_lib.a
-rwxr-xr-x 1 root root 993 Nov 25 05:32 libmysql_lib.la
lrwxrwxrwx 1 root root 21 Nov 25 05:32 libmysql_lib.so -> libmysql_lib.so.0.0.0
lrwxrwxrwx 1 root root 21 Nov 25 05:32 libmysql_lib.so.0 -> libmysql_lib.so.0.0.0
-rwxr-xr-x 1 root root 1026752 Nov 25 05:32 libmysql_lib.so.0.0.0
lrwxrwxrwx 1 igor igor 20 May 25 2017 libmysqlclient.so -> libmysqlclient.so.18
lrwxrwxrwx 1 root root 22 Aug 9 2017 libmysqlclient.so.18 -> libmysqlclient.so.18.4
-rwxrwxrwx 1 root root 7183184 Aug 9 2017 libmysqlclient.so.18.4
-rw-r--r-- 1 root root 1770536 Nov 25 05:32 libodbc_lib.a
-rwxr-xr-x 1 root root 1032 Nov 25 05:32 libodbc_lib.la
lrwxrwxrwx 1 root root 20 Nov 25 05:32 libodbc_lib.so -> libodbc_lib.so.0.0.0
lrwxrwxrwx 1 root root 20 Nov 25 05:32 libodbc_lib.so.0 -> libodbc_lib.so.0.0.0
-rwxr-xr-x 1 root root 1118416 Nov 25 05:32 libodbc_lib.so.0.0.0
-rw-r--r-- 1 root root 1613198 Nov 25 05:32 libpostgres.a
-rwxr-xr-x 1 root root 980 Nov 25 05:32 libpostgres.la
lrwxrwxrwx 1 root root 20 Nov 25 05:32 libpostgres.so -> libpostgres.so.0.0.0
lrwxrwxrwx 1 root root 20 Nov 25 05:32 libpostgres.so.0 -> libpostgres.so.0.0.0
-rwxr-xr-x 1 root root 1002064 Nov 25 05:32 libpostgres.so.0.0.0
-rw-r--r-- 1 root root 4116756 Nov 25 05:32 libpropertypages.a
-rwxr-xr-x 1 root root 1339 Nov 25 05:32 libpropertypages.la
lrwxrwxrwx 1 root root 25 Nov 25 05:32 libpropertypages.so -> libpropertypages.so.0.0.0
lrwxrwxrwx 1 root root 25 Nov 25 05:32 libpropertypages.so.0 -> libpropertypages.so.0.0.0
-rwxr-xr-x 1 root root 1584192 Nov 25 05:32 libpropertypages.so.0.0.0
-rw-r--r-- 1 root root 30632622 Nov 25 05:32 libshapeframework.a
-rwxr-xr-x 1 root root 1180 Nov 25 05:32 libshapeframework.la
lrwxrwxrwx 1 root root 26 Nov 25 05:32 libshapeframework.so -> libshapeframework.so.0.0.0
lrwxrwxrwx 1 root root 26 Nov 25 05:32 libshapeframework.so.0 -> libshapeframework.so.0.0.0
-rwxr-xr-x 1 root root 8990248 Nov 25 05:32 libshapeframework.so.0.0.0
-rw-r--r-- 1 root root 3483340 Nov 25 05:32 libsqlite_lib.a
-rwxr-xr-x 1 root root 989 Nov 25 05:32 libsqlite_lib.la
lrwxrwxrwx 1 root root 22 Nov 25 05:32 libsqlite_lib.so -> libsqlite_lib.so.0.0.0
lrwxrwxrwx 1 root root 22 Nov 25 05:32 libsqlite_lib.so.0 -> libsqlite_lib.so.0.0.0
-rwxr-xr-x 1 root root 2397160 Nov 25 05:32 libsqlite_lib.so.0.0.0
-rw-r--r-- 1 root root 4268158 Nov 25 05:32 libtablewindow.a
-rwxr-xr-x 1 root root 1176 Nov 25 05:32 libtablewindow.la
lrwxrwxrwx 1 root root 23 Nov 25 05:32 libtablewindow.so -> libtablewindow.so.0.0.0
lrwxrwxrwx 1 root root 23 Nov 25 05:32 libtablewindow.so.0 -> libtablewindow.so.0.0.0
-rwxr-xr-x 1 root root 1647496 Nov 25 05:32 libtablewindow.so.0.0.0

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Thu Mar 15, 2018 12:39 am Post subject:

Tony0945, My local copy of wx is not old/outdated, but it might be broken. I am going to rebuild it after my system becomes "sane". Thank you.

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21631

Posted: Thu Mar 15, 2018 1:18 am Post subject:

That output confirms the error message is correct. You have a /usr/local/lib, it is not a symbolic link, and it is not empty. That looks like a bug in a whole host of packages (or perhaps they were simply configured incorrectly). Either way, the fix is to move it to the proper name, and place a symlink behind, as the ebuild expected to occur. You should also consider cleaning out your /usr/local. At least some of those libraries definitely correspond to in-tree packages.

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Thu Mar 15, 2018 3:19 am Post subject:

Hu, Yes, I have /usr/local/lib. Now some files there are coming from my program I'm developing with Anjuta. Apparently their Makefile places so libraries in /usr/local/lib. However I was surprised to see some other libraries there, because the only custpme build software I have is wxGTK, which I do not install - using local copy since I am using a version later than the one in Portage. Now I'm not sure where the symlink should be coming from? Can you help? Thank you. [EDIT] Actually upon reviewing the list of libraries I can say that all of them are part of my software that I'm working on. So now I don't think this should be gone. And I don't believe this directory should be a symlink from anything. It is explicitly designed to be for the manual install. And so the question is - how to correct the baselayout install. [/EDIT]

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Fri Mar 16, 2018 2:54 pm Post subject:

Hu, I can probably try to temporary rename the /usr/local to install the package and then put it back. Just curious though - what would be the right fix to that? Thank you.

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21631

Posted: Sat Mar 17, 2018 12:46 am Post subject:

ONEEYEMAN wrote:

Now some files there are coming from my program I'm developing with Anjuta. Apparently their Makefile places so libraries in /usr/local/lib.

That does not make them right.

The standard is that libraries go in $libdir, where $libdir depends on the architecture and sometimes (rarely) which distribution you ask. On Gentoo amd64, $libdir is lib32, libx32, or lib64, for -m32, -mx32, and (default) -m64, respectively. Those paths may not be universally true, but you will save yourself a lot of trouble if you respect local convention.

ONEEYEMAN wrote:

However I was surprised to see some other libraries there, because the only custpme build software I have is wxGTK, which I do not install - using local copy since I am using a version later than the one in Portage.

Why not use an overlay to provide the appropriate later version?

ONEEYEMAN wrote:

Now I'm not sure where the symlink should be coming from? Can you help?

On my system, it is unowned. I assume that means it came from the stage tarball I used. As I understand it, and the baselayout ebuild seems to agree with my understanding, current convention on Gentoo amd64 is that lib be a symbolic link to lib64. That is no longer true on profile 17.1

ONEEYEMAN wrote:

[EDIT]
Actually upon reviewing the list of libraries I can say that all of them are part of my software that I'm working on.

Some, but not all. I see libraries that belong to mysql in there. Are you bundling MySQL with your program? If yes, you should stop that. If no, then why are there unmanaged MySQL libraries here?

Also, if all the libraries there not otherwise traceable to a Portage package are yours, why do their names have nothing in common? That is almost asking for file collisions.

ONEEYEMAN wrote:

So now I don't think this should be gone. And I don't believe this directory should be a symlink from anything. It is explicitly designed to be for the manual install.
And so the question is - how to correct the baselayout install.[/EDIT]

Yes, /usr/local is for unmanaged system-wide installations. I and many other users on the Gentoo forum have a long history of condemning the use of this area for many purposes, on the basis that installing a package to /usr/local when that package is also available through Portage will almost inevitably lead to problems.

You're welcome to keep /usr/local/lib as a directory, but the baselayout ebuild will not tolerate it and I rather doubt you will convince anyone that baselayout is wrong in this regard. I stand by my earlier analysis. You should move lib to lib64 and, if not on profile 17.1, create a symlink named lib that points to lib64.

ONEEYEMAN
Advocate

Joined: 01 Mar 2005
Posts: 3610

Posted: Sat Mar 17, 2018 1:46 am Post subject:

Hu,

Hu wrote:

ONEEYEMAN wrote:

Now some files there are coming from my program I'm developing with Anjuta. Apparently their Makefile places so libraries in /usr/local/lib.

That does not make them right.

The only problem - like I said - I didn't make this tree, Anjuta install script did.

Hu wrote:

ONEEYEMAN wrote:

Now I'm not sure where the symlink should be coming from? Can you help?

Interesting.
I think I have an old profile, but I never touched the "/usr/local" directory. Since I'm developing in Anjuta their install script may did something.

Hu wrote:

ONEEYEMAN wrote:

[EDIT]
Actually upon reviewing the list of libraries I can say that all of them are part of my software that I'm working on.

Because my software is cross-database. And its still in development. When its ready I will fix it.

Hu wrote:

ONEEYEMAN wrote:

OK, so the proper fix would be to set /usr/local/lib as a symlink to /usr/lib{64}. Is it right?

Thank you.

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21631

Posted: Sat Mar 17, 2018 4:06 am Post subject:

ONEEYEMAN wrote:

The only problem - like I said - I didn't make this tree, Anjuta install script did.

Then either their install script is broken or it was called incorrectly, depending on whether it is hardcoded to write to lib (broken) or takes the directory from the caller (and was called incorrectly).

ONEEYEMAN wrote:

I think I have an old profile, but I never touched the "/usr/local" directory. Since I'm developing in Anjuta their install script may did something.

This seems weird to me. How could their install script have written to an area that only root is permitted to write? As an aside, why is an IDE running an install script at all?

ONEEYEMAN wrote:

Because my software is cross-database. And its still in development. When its ready I will fix it.

I do not understand this answer, but it does not pertain to your immediate problem, so I am not inclined to pursue it further.

ONEEYEMAN wrote:

OK, so the proper fix would be to set /usr/local/lib as a symlink to /usr/lib{64}. Is it right?

No.

Display posts from previous:

	Gentoo Forums Forum Index Portage & Programming	All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy