Menu
▾
▴
fetchmail-users
|
From: Joe Acquisto-j. <jo...@j4...> - 2020-01-29 16:06:55
|
So, I continue to attempt to compile with tidbitd cleaned from internet searches even though I am sure someone on the list has a proper way to do this, aside from compiling on a 32bit machine. Building even a VM for that is problematic at the moment.
Edited Makefile as shown:
CFLAGS = -m32 -g -O2 -I/usr/kerberos/include
CPP = gcc -E
CPPFLAGS = -m32
LDFLAGS = -m32
make produces:
linux-jod1:~/fetchmail-6.4.1 # make
make all-recursive
make[1]: Entering directory '/root/fetchmail-6.4.1'
Making all in .
make[2]: Entering directory '/root/fetchmail-6.4.1'
make[2]: Leaving directory '/root/fetchmail-6.4.1'
Making all in po
make[2]: Entering directory '/root/fetchmail-6.4.1/po'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/root/fetchmail-6.4.1/po'
make[1]: Leaving directory '/root/fetchmail-6.4.1'
This, one presumes, is "ungood".
Thanks for any assistance.
--
+++++++++++++++++++++++
joea@@j4computers.com
https://www.j4computers.com
845-687-3734
+++++++++++++++++++++++
|
|
From: Peter P. <ro...@ri...> - 2020-01-29 16:40:57
Attachments:
signature.asc
|
On Wed, Jan 29, 2020 at 11:06:35AM -0500, Joe Acquisto-j4 wrote:
> So, I continue to attempt to compile with tidbitd cleaned from internet searches even though I am sure someone on the list has a proper way to do this, aside from compiling on a 32bit machine. Building even a VM for that is problematic at the moment.
>
> Edited Makefile as shown:
>
> CFLAGS = -m32 -g -O2 -I/usr/kerberos/include
> CPP = gcc -E
> CPPFLAGS = -m32
> LDFLAGS = -m32
>
> make produces:
>
> linux-jod1:~/fetchmail-6.4.1 # make
> make all-recursive
> make[1]: Entering directory '/root/fetchmail-6.4.1'
> Making all in .
> make[2]: Entering directory '/root/fetchmail-6.4.1'
> make[2]: Leaving directory '/root/fetchmail-6.4.1'
> Making all in po
> make[2]: Entering directory '/root/fetchmail-6.4.1/po'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/root/fetchmail-6.4.1/po'
> make[1]: Leaving directory '/root/fetchmail-6.4.1'
>
> This, one presumes, is "ungood".
This basically means that 'make' did not consider that it had anything
to do, since all the object and executable files were newer than all the
source files. If you only change the Makefile, then you should run
'make clean' or even, if the program supports it, 'make distclean' to
make sure that the next 'make' command will rebuild everything.
G'luck,
Peter
--
Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp...@st...
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
|
|
From: Ralph C. <ra...@in...> - 2020-01-29 16:56:28
|
Hi Joe,
> linux-jod1:~/fetchmail-6.4.1 # make
Try
make clean all
--
Cheers, Ralph.
|
|
From: Joe Acquisto-j. <jo...@j4...> - 2020-01-29 18:43:28
|
>>>
> On Wed, Jan 29, 2020 at 11:06:35AM -0500, Joe Acquisto-j4 wrote:
>> So, I continue to attempt to compile with tidbitd cleaned from internet
> searches even though I am sure someone on the list has a proper way to do
> this, aside from compiling on a 32bit machine. Building even a VM for that
> is problematic at the moment.
> . . . This, one presumes, is "ungood".
>
> This basically means that 'make' did not consider that it had anything
> to do, since all the object and executable files were newer than all the
> source files. If you only change the Makefile, then you should run
> 'make clean' or even, if the program supports it, 'make distclean' to
> make sure that the next 'make' command will rebuild everything.
>
> G'luck,
> Peter
>
>
Tried the suggestion offered. None ran error free. make distclean cleaned a bit too much, so I ended up deleting and re-extracting the tar file.
After a new ./configure, I edited the resultant Makefiile as noted earlier but got this result:
ddgnu-----
linux-jod1:~/fetchmail-6.4.1 # make
depbase=`echo socket.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -I. -I./libesmtp -m32 -m32 -g -O2 -I/usr/kerberos/include -MT socket.o -MD -MP -MF $depbase.Tpo -c -o socket.o socket.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from /usr/include/features.h:447:0,
from /usr/include/sys/types.h:25,
from fetchmail.h:13,
from socket.c:12:
/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory
# include <gnu/stubs-32.h>
^~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:1228: socket.o] Error 1
linux-jod1:~/fetchmail-6.4.1 #
-----
Just guessing, but is it telling me, essentially, that this missing gnu/stubs-32.h is the immediate problem?
joe a
--
+++++++++++++++++++++++
joea@@j4computers.com
https://www.j4computers.com
845-687-3734
+++++++++++++++++++++++
|
|
From: Joe Acquisto-j. <jo...@j4...> - 2020-01-29 19:17:08
|
>>
>>>>
>> On Wed, Jan 29, 2020 at 11:06:35AM -0500, Joe Acquisto-j4 wrote:
So, I continue to attempt to compile with tidbitd cleaned from internet
>> searches even though I am sure someone on the list has a proper way to do
>> this, aside from compiling on a 32bit machine. Building even a VM for that
>> is problematic at the moment.
>> . . . This, one presumes, is "ungood".
>>
>> This basically means that 'make' did not consider that it had anything
>> to do, since all the object and executable files were newer than all the
>> source files. If you only change the Makefile, then you should run
>> 'make clean' or even, if the program supports it, 'make distclean' to
>> make sure that the next 'make' command will rebuild everything.
>>
>> G'luck,
>> Peter
>>
>>
>
> Tried the suggestion offered. None ran error free. make distclean cleaned
> a bit too much, so I ended up deleting and re-extracting the tar file.
>
> After a new ./configure, I edited the resultant Makefiile as noted earlier
> but got this result:
> ddgnu-----
> linux-jod1:~/fetchmail-6.4.1 # make
> depbase=`echo socket.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/local/share/locale\" -I. -I./libesmtp
> -m32 -m32 -g -O2 -I/usr/kerberos/include -MT socket.o -MD -MP -MF $depbase.Tpo -c -o
> socket.o socket.c &&\
> mv -f $depbase.Tpo $depbase.Po
> In file included from /usr/include/features.h:447:0,
> from /usr/include/sys/types.h:25,
> from fetchmail.h:13,
> from socket.c:12:
> /usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or
> directory
> # include <gnu/stubs-32.h>
> ^~~~~~~~~~~~~~~~
> compilation terminated.
> make: *** [Makefile:1228: socket.o] Error 1
> linux-jod1:~/fetchmail-6.4.1 #
> -----
>
> Just guessing, but is it telling me, essentially, that this missing
> gnu/stubs-32.h is the immediate problem?
>
> joe a
>
> --
Found and installed the missing package(s), now get this result. Appears something is still trying 64bit? If so, no clue what to try.
----
gcc -m32 -g -O2 -I/usr/kerberos/include -m32 -o fetchmail socket.o getpass.o fetchmail.o env.o idle.o options.o daemon.o driver.o transact.o sink.o smtp.o idlist.o uid.o mxget.o md5ify.o cram.o gssapi.o opie.o interface.o netrc.o unmime.o conf.o checkalias.o uid_db.o lock.o rcfile_l.o rcfile_y.o ucs/norm_charmap.o pop3.o imap.o etrn.o odmr.o libfm.a strlcpy.o strlcat.o -lresolv -lssl -lcrypto
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/7/../../../libssl.so when searching for -lssl
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot find -lssl
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/7/../../../libcrypto.so when searching for -lcrypto
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot find -lcrypto
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/7/libgcc.a when searching for -lgcc
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot find -lgcc
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/7/libgcc.a when searching for -lgcc
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1064: fetchmail] Error 1
make[2]: Leaving directory '/root/fetchmail-6.4.1'
make[1]: *** [Makefile:1466: all-recursive] Error 1
make[1]: Leaving directory '/root/fetchmail-6.4.1'
make: *** [Makefile:912: all] Error 2
linux-jod1:~/fetchmail-6.4.1 #
-----
joe a.
--
+++++++++++++++++++++++
joea@@j4computers.com
https://www.j4computers.com
845-687-3734
+++++++++++++++++++++++
|
|
From: grarpamp <gra...@gm...> - 2020-01-29 19:40:01
|
> -lresolv -lssl -lcrypto > /usr/lib64... skipping incompatible Try pointing -I and -L at 32 bit versions of those, probably of kerberos too if you need that. |
|
From: Joe Acquisto-j. <jo...@j4...> - 2020-01-29 20:06:28
|
>>> >> -lresolv -lssl -lcrypto >> /usr/lib64... skipping incompatible > > Try pointing -I and -L at 32 bit versions of those, > probably of kerberos too if you need that. > > > _______________________________________________ > Fetchmail-users mailing list > Fet...@li... > https://lists.sourceforge.net/lists/listinfo/fetchmail-users Thanks, but I don't get what you mean. Not well versed in compilers, etc. I can muddle through with fair results on my own, but. Anyway, I see this in Makefile: BTW, I did run ./configure, fresh, after installing new packages and re-extracting the tarball. LEX_OUTPUT_ROOT = LIBICONV = -liconv LIBINTL = LIBOBJS = ${LIBOBJDIR}strlcpy$U.o ${LIBOBJDIR}strlcat$U.o LIBS = -lresolv -lssl -lcrypto LTLIBICONV = -liconv LTLIBINTL = LTLIBOBJS = ${LIBOBJDIR}strlcpy$U.lo ${LIBOBJDIR}strlcat$U.lo MAKEINFO = ${SHELL} /root/fetchmail-6.4.1/missing makeinfo . . . SHELL = /bin/sh SSL_CFLAGS = -DOPENSSL_LOAD_CONF SSL_LIBS = -lssl -lcrypto STRIP = USE_NLS = yes joe a. -- +++++++++++++++++++++++ joea@@j4computers.com https://www.j4computers.com 845-687-3734 +++++++++++++++++++++++ |
|
From: grarpamp <gra...@gm...> - 2020-01-29 21:06:26
|
>>> -lresolv -lssl -lcrypto >>> /usr/lib64... skipping incompatible >> >> Try pointing -I and -L at 32 bit versions of those, >> probably of kerberos too if you need that. Why not compile it directly on the 32bit box. Compiling a 32bit prog needs 32bit libs linked into it, not 64bit. gcc was looking at the 64bit libs and complained about them. Probably easier to download latest, or copy over old, precompiled 32bit libs of openssl and resolver than trying to compile them too from source as 32bit. They're usually in 32bit package repos of whatever OS. Also easier to add -static to LDFLAGS CPPFLAGS, else you'll probably have to copy all the compiled against 32bit libs over to the 32bit box into whatever hiers or into a dedicated private LD_LIBRARY_PATH dir. Maybe the OS already has a up to date 32bit fetchmail package binary users could manually extract and run. That's all userland, then there's kernel ABI... especially if crossing major kernel version nums. Uprev direction might require kernel rebuild with compat options, compat libs, etc. Downrev is more work. The work involved building into old prods usually triggers migration and a vow to keep updated. |
|
From: Joe Acquisto-j. <jo...@j4...> - 2020-01-29 21:30:34
|
>>>
> -lresolv -lssl -lcrypto
>>>> /usr/lib64... skipping incompatible
>>>
>>> Try pointing -I and -L at 32 bit versions of those,
>>> probably of kerberos too if you need that.
>
> Why not compile it directly on the 32bit box.
>
> Compiling a 32bit prog needs 32bit libs linked into it, not 64bit.
> gcc was looking at the 64bit libs and complained about them.
> Probably easier to download latest, or copy over old, precompiled
> 32bit libs of openssl and resolver than trying to compile them too from
> source as 32bit. They're usually in 32bit package repos of whatever OS.
> Also easier to add -static to LDFLAGS CPPFLAGS, else
> you'll probably have to copy all the compiled against 32bit libs
> over to the 32bit box into whatever hiers or
> into a dedicated private LD_LIBRARY_PATH dir.
> Maybe the OS already has a up to date 32bit fetchmail
> package binary users could manually extract and run.
> That's all userland, then there's kernel ABI...
> especially if crossing major kernel version nums.
> Uprev direction might require kernel rebuild with
> compat options, compat libs, etc. Downrev is more work.
>
> The work involved building into old prods usually
> triggers migration and a vow to keep updated.
>
>
The box it is running on has shortcomings, needs packages that cannot be got.
Everything needs refresh, bottom up.
Just trying to get a more up to day version of fetchmail on it for the time being.
May approach this another way.
--
+++++++++++++++++++++++
joea@@j4computers.com
https://www.j4computers.com
845-687-3734
+++++++++++++++++++++++
|
|
From: Matthias A. <mat...@gm...> - 2020-01-29 22:52:03
|
Am 29.01.20 um 22:30 schrieb Joe Acquisto-j4: >> -lresolv -lssl -lcrypto >>>>> /usr/lib64... skipping incompatible >>>> Try pointing -I and -L at 32 bit versions of those, >>>> probably of kerberos too if you need that. >> Why not compile it directly on the 32bit box. >> >> Compiling a 32bit prog needs 32bit libs linked into it, not 64bit. >> gcc was looking at the 64bit libs and complained about them. >> Probably easier to download latest, or copy over old, precompiled >> 32bit libs of openssl and resolver than trying to compile them too from >> source as 32bit. They're usually in 32bit package repos of whatever OS. >> Also easier to add -static to LDFLAGS CPPFLAGS, else >> you'll probably have to copy all the compiled against 32bit libs >> over to the 32bit box into whatever hiers or >> into a dedicated private LD_LIBRARY_PATH dir. >> Maybe the OS already has a up to date 32bit fetchmail >> package binary users could manually extract and run. >> That's all userland, then there's kernel ABI... >> especially if crossing major kernel version nums. >> Uprev direction might require kernel rebuild with >> compat options, compat libs, etc. Downrev is more work. >> >> The work involved building into old prods usually >> triggers migration and a vow to keep updated. >> >> > The box it is running on has shortcomings, needs packages that cannot be got. > Everything needs refresh, bottom up. > > Just trying to get a more up to day version of fetchmail on it for the time being. > > May approach this another way. So, I tried Fedora 31 on a 64-bit x86_64 computer with -m32, and had to install quite a few more RPMs for i686. Since I've stopped using SUSE ages ago, I don't know their names, but you'll likely need libgcc.i686, glibc.i686, glibc-devel.i686, openssl-devel.i686, openssl.i686 (or i586, respectively), and quite possibly others. Note that the fetchmail host cannot be "older" than the builder else you'll probably see issues with glibc versioned symblos not found - and I have zero clue how fit an old SUSE is for cross-building 32-bit code on a 64-bit host. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X