Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
gcc upgrade
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Mon Mar 12, 2018 12:44 am    Post subject: gcc upgrade Reply with quote

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.
Back to top
View user's profile Send private message
ali3nx
l33t
l33t


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

PostPosted: Mon Mar 12, 2018 12:49 am    Post subject: Re: gcc upgrade Reply with quote

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!
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Mon Mar 12, 2018 1:07 am    Post subject: Reply with quote

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

Do I have to?

Thank you.
Back to top
View user's profile Send private message
ali3nx
l33t
l33t


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

PostPosted: Mon Mar 12, 2018 1:17 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Mon Mar 12, 2018 1:39 am    Post subject: Reply with quote

Hi,
What is the best way to recompile world?
Thank you.
Back to top
View user's profile Send private message
ali3nx
l33t
l33t


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

PostPosted: Mon Mar 12, 2018 1:49 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13051

PostPosted: Mon Mar 12, 2018 3:30 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Mon Mar 12, 2018 10:13 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Mon Mar 12, 2018 11:57 pm    Post subject: Reply with quote

Hu,
Because everything was compiling properly on gcc 5.4.

Thank you.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


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

PostPosted: Tue Mar 13, 2018 12:45 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


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

PostPosted: Tue Mar 13, 2018 12:49 am    Post subject: Reply with quote

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;
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


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

PostPosted: Tue Mar 13, 2018 1:08 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13051

PostPosted: Tue Mar 13, 2018 1:59 am    Post subject: Reply with quote

ONEEYEMAN wrote:
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.
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.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


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

PostPosted: Tue Mar 13, 2018 3:03 am    Post subject: Reply with quote

Hu wrote:
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.

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.
Back to top
View user's profile Send private message
ali3nx
l33t
l33t


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

PostPosted: Tue Mar 13, 2018 3:36 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


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

PostPosted: Tue Mar 13, 2018 3:24 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


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

PostPosted: Tue Mar 13, 2018 3:27 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Thu Mar 15, 2018 12:36 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Thu Mar 15, 2018 12:39 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13051

PostPosted: Thu Mar 15, 2018 1:18 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Thu Mar 15, 2018 3:19 am    Post subject: Reply with quote

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]
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Fri Mar 16, 2018 2:54 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13051

PostPosted: Sat Mar 17, 2018 12:46 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ONEEYEMAN
Advocate
Advocate


Joined: 01 Mar 2005
Posts: 2762

PostPosted: Sat Mar 17, 2018 1:46 am    Post subject: Reply with quote

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 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.


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?

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

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.

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.

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

Hu wrote:

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.


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

Thank you.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13051

PostPosted: Sat Mar 17, 2018 4:06 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    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