Hi there,
after I finally got nx to build on Mageia, I'm now working on x2goserver.
I already had to patch the Makefiles because of a few problems:
- they try to install several files directly into /etc
- they try to set owner and group to root Since you don't build rpm packages as root, that doesn't work.
When I'm done, I will send you my patches so you can look into them.
But now to my real problem: There's quite a list of files installed into /usr/lib instead of /usr/lib64, where they should be located. Now the question is, will it break anything, when I patch the Makefiles to install them into the correct dir?
Oliver
-- Oliver aka obgr_seneca
Mageia Community Council
i18n team - team leader
web team - substitute team leader
packaging team
http://www.mageia.org/ - Mageia, the magic continues
Hi Oliver,
On Sa 28 Jan 2012 17:27:57 CET Oliver Burger wrote:
[...]
When I'm done, I will send you my patches so you can look into them.
Great! Please make sure you always cross-check our Git repos: http://code.x2go.org/gitweb?p=x2goserver.git;a=summary
But now to my real problem: There's quite a list of files installed into /usr/lib instead of /usr/lib64, where they should be located. Now the question is, will it break anything, when I patch the Makefiles to install them into the correct dir?
I am not at all an expert on this, I can only report the latest
approaches in Debian here.
On systems /usr/lib is the default folder for libraries that are built
for the same architecture as the system itself. There also should be a
symlink from lib64 -> lib. For other architectures there can be other
lib folders (e.g. /usr/lib32 for ia32 stuff).
On multi-arch systems (like currently under development in Debian sid)
there are lib folders for each architecture
/usr/lib/<arch>/
So basically, installing code to /usr/lib should be fine.
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
2012/1/28 Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
I am not at all an expert on this, I can only report the latest approaches in Debian here.
On systems /usr/lib is the default folder for libraries that are built for the same architecture as the system itself. There also should be a symlink from lib64 -> lib. For other architectures there can be other lib folders (e.g. /usr/lib32 for ia32 stuff).
On multi-arch systems (like currently under development in Debian sid) there are lib folders for each architecture
/usr/lib/<arch>/
So basically, installing code to /usr/lib should be fine. It's a bit different in Mageia and iirc the other rpm based distros. Normally /usr/lib/ is used here for 32bit libraries, x86_64 is for 64bit libraries. This is especially neccessary if you have to install 32bit and 64bit versions of the same library next to each other.
But looking into some of those files, lib is hardcoded there, so it would need quite some patching to make them installable in lib64. But since all but x2goslitewrapper is actually noarch, it will perhaps not hurt much... Especially as different from what I had in mind, our build system does not block arch dependant 64bit binaries to be installed in /usr/lib :)
Oliver
On Sat, Jan 28, 2012 at 10:02 PM, Oliver Burger <obgr_seneca@mageia.org> wrote:
2012/1/28 Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
I am not at all an expert on this, I can only report the latest approaches in Debian here.
On systems /usr/lib is the default folder for libraries that are built for the same architecture as the system itself. There also should be a symlink from lib64 -> lib. For other architectures there can be other lib folders (e.g. /usr/lib32 for ia32 stuff).
On multi-arch systems (like currently under development in Debian sid) there are lib folders for each architecture
/usr/lib/<arch>/
So basically, installing code to /usr/lib should be fine. It's a bit different in Mageia and iirc the other rpm based distros. Normally /usr/lib/ is used here for 32bit libraries, x86_64 is for 64bit libraries. This is especially neccessary if you have to install 32bit and 64bit versions of the same library next to each other.
Debian solves this differently: all library packages that are supposed to be co-installable across archs get installed to /usr/lib/$triplet/lib.foo. This way, you can install sparc 64bit or arm packages on your 32bit i386 laptop. This can be useful for example for cross-compiling, etc.
But looking into some of those files, lib is hardcoded there, so it would need quite some patching to make them installable in lib64. But since all but x2goslitewrapper is actually noarch, it will perhaps not hurt much... Especially as different from what I had in mind, our build system does not block arch dependant 64bit binaries to be installed in /usr/lib :)
Yeah, probably the makefiles should be extended to make the the libdir ($PREFIX/$LIBDIR, with $LIBDIR being either /lib, /lib32 or /lib64) configurable.
-- regards, Reinhard
Hi Oliver, hi Reinhard,
On Sa 28 Jan 2012 22:07:23 CET Reinhard Tartler wrote:
On Sat, Jan 28, 2012 at 10:02 PM, Oliver Burger
<obgr_seneca@mageia.org> wrote:2012/1/28 Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
I am not at all an expert on this, I can only report the latest approaches in Debian here.
On systems /usr/lib is the default folder for libraries that are built for the same architecture as the system itself. There also should be a symlink from lib64 -> lib. For other architectures there can be other lib folders (e.g. /usr/lib32 for ia32 stuff).
On multi-arch systems (like currently under development in Debian
sid) there are lib folders for each architecture/usr/lib/<arch>/
So basically, installing code to /usr/lib should be fine. It's a bit different in Mageia and iirc the other rpm based distros. Normally /usr/lib/ is used here for 32bit libraries, x86_64 is for 64bit libraries. This is especially neccessary if you have to install 32bit and 64bit versions of the same library next to each other.
Debian solves this differently: all library packages that are supposed to be co-installable across archs get installed to /usr/lib/$triplet/lib.foo. This way, you can install sparc 64bit or arm packages on your 32bit i386 laptop. This can be useful for example for cross-compiling, etc.
But looking into some of those files, lib is hardcoded there, so it would need quite some patching to make them installable in lib64. But since all but x2goslitewrapper is actually noarch, it will perhaps not hurt much... Especially as different from what I had in mind, our build system does not block arch dependant 64bit binaries to be installed in /usr/lib :)
Yeah, probably the makefiles should be extended to make the the libdir ($PREFIX/$LIBDIR, with $LIBDIR being either /lib, /lib32 or /lib64) configurable.
Took a closer look now: each x2goserver Makefile that puts some stuff
to /usr/lib/x2go has a line
LIBDIR=$(PREFIX)/lib/x2go
You can simply override this var by calling something like this:
$ make PREFIX=/usr LIBDIR=/some/path/lib64 build
Is it that what you need?
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Took a closer look now: each x2goserver Makefile that puts some stuff to /usr/lib/x2go has a line
LIBDIR=$(PREFIX)/lib/x2go
You can simply override this var by calling something like this:
$ make PREFIX=/usr LIBDIR=/some/path/lib64 build
Is it that what you need? The Makefiles do provide that, but it will break x2goserver, since the include paths in the files are hardcoded. E.g. "use lib
echo -n \$(x2gobasepath)/lib/x2go;" in x2godbadmin. I don't know perl, but the eror message I get, lets me think, that as it is done in python, there are special paths defined for site
2012/1/28 Mike Gabriel <mike.gabriel@das-netzwerkteam.de>: packages: "Can't locate x2gologlevel.pm in @INC (@INC contains: /usr/lib/x2go /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.14.1 /usr/lib/perl5/vendor_perl/5.14.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.0 /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.12.3 /usr/lib/perl5/vendor_perl/5.12.2 /usr/lib/perl5/vendor_perl .) at /usr/sbin/x2godbadmin line 30."
So wouldn't it be best to have those "library" files located in a "perl site package" path? Of course I can have those files installed in /usr/lib/ as well or I can use some sed magic in the spec file, correcting those paths. But that would be a rather ugly workarround.
Oliver
Hi Oliver,
On So 29 Jan 2012 11:38:24 CET Oliver Burger wrote:
Took a closer look now: each x2goserver Makefile that puts some stuff to /usr/lib/x2go has a line
LIBDIR=$(PREFIX)/lib/x2go
You can simply override this var by calling something like this:
$ make PREFIX=/usr LIBDIR=/some/path/lib64 build
Is it that what you need? The Makefiles do provide that, but it will break x2goserver, since the include paths in the files are hardcoded. E.g. "use lib
echo -n \$(x2gobasepath)/lib/x2go;" in x2godbadmin. I don't know perl, but the eror message I get, lets me think, that as it is done in python, there are special paths defined for site2012/1/28 Mike Gabriel <mike.gabriel@das-netzwerkteam.de>: packages: "Can't locate x2gologlevel.pm in @INC (@INC contains: /usr/lib/x2go /usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.14.2 /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.2 /usr/lib/perl5/5.14.2/x86_64-linux-thread-multi /usr/lib/perl5/5.14.2 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.14.1 /usr/lib/perl5/vendor_perl/5.14.1/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.14.0 /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.12.3 /usr/lib/perl5/vendor_perl/5.12.2 /usr/lib/perl5/vendor_perl .) at /usr/sbin/x2godbadmin line 30."
So wouldn't it be best to have those "library" files located in a "perl site package" path? Of course I can have those files installed in /usr/lib/ as well or I can use some sed magic in the spec file, correcting those paths. But that would be a rather ugly workarround.
Now I get what your point is. This has to be addressed in our upstream
code. Not exactly sure how, though. I will discuss that with Alex on
Jabber the coming week.
Thanks!!! Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Mike Gabriel -
Oliver Burger -
Reinhard Tartler