Mailinglist Archive: opensuse-amd64 (449 mails)
| < Previous | Next > |
Re: [suse-amd64] 64-bit libs and 32-bit libs
- From: "Matt T." <Matt@xxxxxxxxx>
- Date: Mon, 11 Oct 2004 03:57:51 +0000 (UTC)
- Message-id: <200410111058.55400.Matt@xxxxxxxxx>
On Monday 11 October 2004 03:49, Joe Morris (NTM) wrote:
> Matt T. wrote:
> >But when you say that the apps have it "hard coded to only look in
> > /usr/lib (or /opt/kde3/lib instead of lib64)", then where is that
> > hardcoded??? I do some programming, even in C++, using kdevelop, and I
> > never did hardcode anywhere where to look for the libs.
>
> One example was ktail. Pasted here is the diff/patch to get it to build
> on x86_64.
>
> --- usr/src/packages/BUILD/ktail-0.6.1/configure 2002-07-03
> 18:56:04.000000000 -0500
> +++ home/joe/configure 2004-09-01 12:18:09.860103188 -0500
[snip]
>
> >As far as I know, the libs are needed when the apps get linked, after
> >compiling. The command to do so is specified in the makefile, by
> > configure. And configure is build by autoconf & Co.
>
> I know some programs already have a configure script. Most recent kde
> apps can use the handy libsuffix argument.
>
> >Now I'm just scratching the surface of kde programming, so I might have
> >misunderstood, but If I did get it more or less correctly, it means that
> >somewhere in the creation of configure and / or the makefile, the correct
> > lib path is not used.
>
> Sometimes I have seen the configure scripts is built, and have seen some
> of those (IIRC in the autoconf directory) that needed patching because
> of a hard coded /usr/lib that got passed on to configure or the
> Makefile. An example was dansguardian. I am not a programmer though,
> but I know what I needed in certain instances with certain programs to
> get them to build (rpms). So far, I think I have had good success after
> making patches to the programs after tracking down any errors, but i
> always only make changes to the programs (I don't honestly know enough
> to change the tools used to build). Since I have had a good success
> rate this way, I would assume that it may not be the tools, but as
> Andreas said, the programs
>
> >Joe, you say you patch the source, I assume you mean the c++ source, may I
> > ask you for an example where you did patch?
>
> See above.
Joe, according to this example you are patching the configure script, and not
the c++ source code.
When I program with kdevelop, I do write c++ code, but I do not write the
configure script. The configure script is created for me by kdevelop, which
uses autoconf & friends to do the work here.
Usually when we download an app as .gz or .bz etc., the configure script is
included. So yes, it looks as if it is the app and the programmer of the app,
but no, I think in most cases the configure script included with the app had
been created more or less automatically, using the tool.
That is why I think that these tools need to get fixed, so they produce a
configure script which works on 32 bit and on 64 bit systems.
Regards,
Matt
>
> --
> Joe Morris
> New Tribes Mission
> Email Address: Joe_Morris@xxxxxxx
> Registered Linux user 231871
> Matt T. wrote:
> >But when you say that the apps have it "hard coded to only look in
> > /usr/lib (or /opt/kde3/lib instead of lib64)", then where is that
> > hardcoded??? I do some programming, even in C++, using kdevelop, and I
> > never did hardcode anywhere where to look for the libs.
>
> One example was ktail. Pasted here is the diff/patch to get it to build
> on x86_64.
>
> --- usr/src/packages/BUILD/ktail-0.6.1/configure 2002-07-03
> 18:56:04.000000000 -0500
> +++ home/joe/configure 2004-09-01 12:18:09.860103188 -0500
[snip]
>
> >As far as I know, the libs are needed when the apps get linked, after
> >compiling. The command to do so is specified in the makefile, by
> > configure. And configure is build by autoconf & Co.
>
> I know some programs already have a configure script. Most recent kde
> apps can use the handy libsuffix argument.
>
> >Now I'm just scratching the surface of kde programming, so I might have
> >misunderstood, but If I did get it more or less correctly, it means that
> >somewhere in the creation of configure and / or the makefile, the correct
> > lib path is not used.
>
> Sometimes I have seen the configure scripts is built, and have seen some
> of those (IIRC in the autoconf directory) that needed patching because
> of a hard coded /usr/lib that got passed on to configure or the
> Makefile. An example was dansguardian. I am not a programmer though,
> but I know what I needed in certain instances with certain programs to
> get them to build (rpms). So far, I think I have had good success after
> making patches to the programs after tracking down any errors, but i
> always only make changes to the programs (I don't honestly know enough
> to change the tools used to build). Since I have had a good success
> rate this way, I would assume that it may not be the tools, but as
> Andreas said, the programs
>
> >Joe, you say you patch the source, I assume you mean the c++ source, may I
> > ask you for an example where you did patch?
>
> See above.
Joe, according to this example you are patching the configure script, and not
the c++ source code.
When I program with kdevelop, I do write c++ code, but I do not write the
configure script. The configure script is created for me by kdevelop, which
uses autoconf & friends to do the work here.
Usually when we download an app as .gz or .bz etc., the configure script is
included. So yes, it looks as if it is the app and the programmer of the app,
but no, I think in most cases the configure script included with the app had
been created more or less automatically, using the tool.
That is why I think that these tools need to get fixed, so they produce a
configure script which works on 32 bit and on 64 bit systems.
Regards,
Matt
>
> --
> Joe Morris
> New Tribes Mission
> Email Address: Joe_Morris@xxxxxxx
> Registered Linux user 231871
| < Previous | Next > |