Bug 386170 - Strange prefix change in cmake or compilation
Summary: Strange prefix change in cmake or compilation
Status: RESOLVED NOT A BUG
Alias: None
Product: frameworks-kconfig
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.39.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Matthew Dawson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-25 08:28 UTC by shevegen
Modified: 2018-01-13 15:45 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description shevegen 2017-10-25 08:28:12 UTC
Hello.

I downloaded the kconfig framework program from here:

  https://download.kde.org/stable/frameworks/5.39/kconfig-5.39.0.tar.xz

I extract it then do this:

  cmake -DCMAKE_INSTALL_PREFIX=/usr

The error I get is:

CMake Error at cmake_install.cmake:400 (file):
  file cannot create directory: /usr/s/cmake/KF5Config.  Maybe need
  administrative privileges.


make: *** [Makefile:129: install] Error 1

---------

I have no idea why /usr/s/ is the prefix when I use /usr only as
prefix. It confuses me completely. I never had that with GNU 
autoconfigure either. Is there some stray prefix that gets inserted?

Because I can assure you to 100%, that I used manually this line:

  cmake -DCMAKE_INSTALL_PREFIX=/usr

so no idea why it suddenly becomes /usr/s/.
Comment 1 shevegen 2017-10-25 08:29:51 UTC
Btw the error message is also bogus.

I am the superuser, so I have no idea why the message tells me
"need administrative privileges". :)

I also created a file called s in "/usr/s" because I can not
explain the behaviour, so the above trigger is because of course
you can not create anything in the "directory" /usr/s - because
I made it a file. But this is not the issue anyway, the real
issue is why something in the build system assumes /usr/s/ as
the target prefix when /usr/ is used.
Comment 2 Christoph Feck 2017-10-25 19:43:44 UTC
Is the cmake command in comment #0 exactly as you use it? Note that cmake expects the source directory as the argument.
Comment 3 shevegen 2017-10-27 16:57:19 UTC
I wanted to add two more bits of information - not sure if they are
helpful, but additional information may be useful.

(1) My base system here on my main desktop machine, on which I also
reported the above situation, is slackware. But I compile the KDE
stack from source e. g. https://download.kde.org/stable/frameworks/5.39/
and https://download.kde.org/stable/applications/17.08.2/src/ and so
forth. I tend to use the /usr/ prefix normally but sometimes I also
use the GoboLinux versioned AppDir approach - so for example,
konsole would have the --prefix /Programs/Konsole/17.08.2, based on
the URL
  https://download.kde.org/stable/applications/17.08.2/src/konsole-17.08.2.tar.xz

The latter approach requires of me to handle the cmake-modules of KDE
e. g. at /usr/lib/cmake/ (such as KF5 etc...) and I can not exclude
that I am doing everything right of course. But on the other hand, I
also was able to compile everything necessary up to (and including)
konsole from source, and konsole was even running fine. \o/

(2) I noticed that, the "s/" target, may have to do with "lib/". I
noticed this when I was compiling via versioned AppDir prefix, so
rather than a lib/ or lib64/ directory, I suddenly had a s/ directory.

I do not know if the latter observation is of any real help but I
just reported it in the event that it may be useful to others. I
could be wrong but some other KDE-related programs now seem to
use lib/ rather than lib64/, so I assume that perhaps this may be
related. But I am guessing here really.

I think that, either way, if it would be possible, it would be nice
to be able to understand the problem on the commandline since it
was unexpected to me via --prefix. I wrote a script for the latter
programs that replaces "s/" with "lib/" but this did not fix the 
issue, I still got error reports on a weird "lib/s/" prefix
instead.

I am not 100% sure but I can not remember this problem in the earlier
KDE releases from a few weeks ago, so I guess that there may have been
some changes. But I am really just guessing here mostly, sorry -
hopefully it may still be useful to someone out there. :)
Comment 4 shevegen 2018-01-13 12:55:24 UTC
I think I finally solved this, so it can be closed.

A script that I used was doing an incomplete sed-operation; rather
than changing the prefix from lib64 to lib, there was an intermittant
/s/ applied resulting in prefix change from lib64 to s instead.

Not sure how to close this report; on github it's a lot easier 
to close :D *wink*
Comment 5 Rex Dieter 2018-01-13 15:45:13 UTC
closing at users' request