fetchmail-users — User questions and discussion

Re: [Fetchmail-users] gmail timeout using IMAP

[Matthias A. <mat...@gm...>]

Am 05.02.20 um 20:06 schrieb Joe Acquisto-j4:
> Well . . . oops?  Don't know how I  missed the port issue.  At some point the 
> "ssl" option was deleted from the user line.   
>
> That resolved the connection failure.      Working after a few fetch cycles and
> chasing a gmail issue.   The  ssl fingerprint seems to change, seemingly with what
> IP it happens to connect.

SSL fingerprints are mostly non-workable for those of the big sites that
use per-host certificates, and fetchmail won't let you list dozens, let
a lone use a secure hash (it uses MD5).

Be sure to install the Mozilla root certificates (most distributions
have packages such as ca-certificates or nss_root_ca) that integrate
with the default OpenSSL configuration such that the certificates can be
verified automatically, do not use --sslfingerprint, do not use
--nosslcertck (but do use --sslcertck on 6.3.x) and move on.

> While I do find almost immediate response when connecting (human eyeball time)

I suppose Google's non-SSL port (which would have had to use STARTTLS or
possibly risked broken clients volunteering their password over
unencrypted links) is firewalled and blackholes inbound traffic.

And yes, Google isn't exactly following the IMAP RFCs (standards) to the
letter, or even the traditional model of an IMAP server.

Re: [Fetchmail-users] gmail timeout using IMAP

[Joe Acquisto-j. <jo...@j4...>]

>Checked that "less secure" apps was still enabled.  Did find some "security 
> warnings" about suspicious access attempts and approved them.  That did not 
> resolve the issue.
>>
>> Many indications on the web that gmail is particularly reluctant to play 
> nice with others.
>>
>> FWIW there are several accounts defined in the same fetchmailrc file at 
> another provider that work just fine in the same fetch cycle.
> 
> If Ralph's answer (try ssl) doesn't help, we're at the point where it
> boils down to the canned answer, please provide output per
> <https://www.fetchmail.info/fetchmail-FAQ.html#G3> and mask your
> passwords. Generally I'd say, however, that a timeout < 30 s might be
> fraught with problems.
> 

Well . . . oops?  Don't know how I  missed the port issue.  At some point the 
"ssl" option was deleted from the user line.   

That resolved the connection failure.      Working after a few fetch cycles and
chasing a gmail issue.   The  ssl fingerprint seems to change, seemingly with what
IP it happens to connect.

While I do find almost immediate response when connecting (human eyeball time)
I set the timeout to 30 for the moment.

Thanks for the assistance, I'll look into improving the ssl business.

joe a.

Re: [Fetchmail-users] gmail timeout using IMAP

[Matthias A. <mat...@gm...>]

> Checked that "less secure" apps was still enabled.  Did find some "security warnings" about suspicious access attempts and approved them.  That did not resolve the issue.
>
> Many indications on the web that gmail is particularly reluctant to play nice with others.
>
> FWIW there are several accounts defined in the same fetchmailrc file at another provider that work just fine in the same fetch cycle.

If Ralph's answer (try ssl) doesn't help, we're at the point where it
boils down to the canned answer, please provide output per
<https://www.fetchmail.info/fetchmail-FAQ.html#G3> and mask your
passwords. Generally I'd say, however, that a timeout < 30 s might be
fraught with problems.

Re: [Fetchmail-users] gmail timeout using IMAP

[Ralph C. <ra...@in...>]

Hi Joe,

> fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 09:05:20 PM EST: poll started
> fetchmail: Trying to connect to 173.194.175.108/143... (log message incomplete)
...
> poll imap.gmail.com with proto IMAP timeout 10 envelope Delivered-to
>     user 'gue...@gm...', with password 'someword', is
>     'xma...@an...' here folder 'Inbox' fetchlimit 10
>     sslfingerprint '11:22:33:53:84:9C:EF:6C:E2:BF:AA:A8:2A:DD:EE:FF'

Port 143, mentioned above, is IMAP.  I don't know if Gmail every listen
on that.  You'll doing better using 993; see /etc/services for 993/tcp.
That's achieved with fetchmail's keyword ssl; and it has friends.
You've sslfingerprint above, so presumably you were down this path
before.

-- 
Cheers, Ralph.

Re: [Fetchmail-users] gmail timeout using IMAP

[Joe Acquisto-j. <jo...@j4...>]

>>>
> Having entered the modern era, I seek guidance on the following problem:
> . . . 
> fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 
> 09:05:20 PM EST: poll started
> fetchmail: Trying to connect to 173.194.175.108/143... (log message 
> incomplete)
> fetchmail: timeout after 10 seconds waiting to connect to server 
> imap.gmail.com.
> fetchmail: socket error while fetching from 
> gue...@gm...@imap.gmail.com
> fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 
> 09:05:30 PM EST: poll completed
> fetchmail: Query status=2 (SOCKET)
> . . . 
> 
> A snippet of fetchmailrc is below:
> 
> -----
> set logfile "/var/log/fetchmail.log"
> set postmaster "admin@[mydomain]"
> set nobouncemail
> set no spambounce
> set properties ""
> set daemon 240
> 
> poll imap.gmail.com with proto IMAP timeout 10 envelope Delivered-to
> 
>     user 'gue...@gm...', with password 'someword', is 
> 'xma...@an...' here folder 'Inbox' fetchlimit 10 
> sslfingerprint '11:22:33:53:84:9C:EF:6C:E2:BF:AA:A8:2A:DD:EE:FF'
> ------
> 
> This had been working during earlier testing, but stopped while.   I updated 
> to fetchmail 6.4.1, being the cautions fellow I am, yet, the problem 
> persists.  
> 
> Checked that "less secure" apps was still enabled.  Did find some "security 
> warnings" about suspicious access attempts and approved them.  That did not 
> resolve the issue.
> 
> Many indications on the web that gmail is particularly reluctant to play 
> nice with others.  
> 
> FWIW there are several accounts defined in the same fetchmailrc file at 
> another provider that work just fine in the same fetch cycle.  
> 
> Thanks in advance.
> 
> joe a
> 

BTW, the "timeout 10" was "timeout 120" in earlier testing, same result.

joe a.

[Fetchmail-users] gmail timeout using IMAP

[Joe Acquisto-j. <jo...@j4...>]

Having entered the modern era, I seek guidance on the following problem:
. . . 
fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 09:05:20 PM EST: poll started
fetchmail: Trying to connect to 173.194.175.108/143... (log message incomplete)
fetchmail: timeout after 10 seconds waiting to connect to server imap.gmail.com.
fetchmail: socket error while fetching from gue...@gm...@imap.gmail.com
fetchmail: 6.4.1 querying imap.gmail.com (protocol IMAP) at Tue 04 Feb 2020 09:05:30 PM EST: poll completed
fetchmail: Query status=2 (SOCKET)
. . . 

A snippet of fetchmailrc is below:

-----
set logfile "/var/log/fetchmail.log"
set postmaster "admin@[mydomain]"
set nobouncemail
set no spambounce
set properties ""
set daemon 240

poll imap.gmail.com with proto IMAP timeout 10 envelope Delivered-to

    user 'gue...@gm...', with password 'someword', is 'xma...@an...' here folder 'Inbox' fetchlimit 10 sslfingerprint '11:22:33:53:84:9C:EF:6C:E2:BF:AA:A8:2A:DD:EE:FF'
------

This had been working during earlier testing, but stopped while.   I updated to fetchmail 6.4.1, being the cautions fellow I am, yet, the problem persists.  

Checked that "less secure" apps was still enabled.  Did find some "security warnings" about suspicious access attempts and approved them.  That did not resolve the issue.

Many indications on the web that gmail is particularly reluctant to play nice with others.  

FWIW there are several accounts defined in the same fetchmailrc file at another provider that work just fine in the same fetch cycle.  

Thanks in advance.

joe a

Re: [Fetchmail-users] systemd start error

[Matthias A. <mat...@gm...>]

Am 04.02.20 um 06:45 schrieb Joe Acquisto-j4:
> Thanks for your reply and pointers.
>
> The solution to the immediate problem had to do with ownership of the file
> name provided by the variable ($FETCHMAIL_RC_PATH), which in this case
> was "/etc/fetchmailrc".  When ownership was changed to "fetchmail", the
> systemd startup magic was satisfied and fetchmail started upon system startup.
>
> Sorry I did not specify that the new OS is of current vintage and provided nearly
> up to date versions of fetchmail (6.3.26), Postfix and Spamassassin.

Careful with "nearly up to date" - there have been 250 change sets and
6½ years since 6.3.26. to 6.4.x, many of them significant, some for
performance, some for TLS support, and whatnot. 

<https://sourceforge.net/p/fetchmail/mailman/message/36773574/>

<https://gitlab.com/fetchmail/fetchmail/-/blob/8e10e1fe4fb5aacbed489255d94aeefcef075e81/NEWS#L77>


> I chose to use the OS packaged versions for ease of setup and will certainly
> update to the latest versions rather soon.
OS packaged versions means ask the OS vendor for support. I will not
support 6.3.26 on this list.
> [...]
> It all actually progressed much more smoothly than I had thought likely
> and has been working well for several days.
>
> Thank you for a solid product.

:-)

Re: [Fetchmail-users] systemd start error

[Joe Acquisto-j. <jo...@j4...>]

>>>
> Am 03.02.20 um 02:00 schrieb Joe Acquisto-j4:
>> Migrated to a new platform,  installed the provided package, fetchmail 
> 6.3.26 just to ease my pain.
>>
>> All works fine loading fetchmail manually but I cannot get fetchmail to 
> start on boot.   Just starting familiarization with systemd.
>>
>> This is what I get from systemctl status fetchmail:
>>
>> Feb 02 19:48:53 localhost systemd[1]: Started A remote-mail retrieval 
> utility.
>> Feb 02 19:48:53 localhost fetchmail-systemd-exec[13677]: $FETCHMAIL_RC_PATH 
> does not exist or cannot be read
>>
>> I moved /root/.fetchmailrc to /etc/fetchmail, where it seemed to be expected 
> to be.  Still objected.  Changed file permissions and was told it could only 
> be 700.  Set it back, same result.
>>
>> What could be the issue?  Ownership?
> 
> Joe,
> 
> I am sorry to write that this has just taken you further away from a
> solution because you brought unknown third-party launcher scripts to the
> table. Answering those questions you pose would amount to guesswork or
> massive remote debugging, and we can't help you on this list with a
> third-party package.
> 
> Reason, the systemd stuff that your outdated package has provided you
> with is not part of fetchmail, but has been provided by your package
> provider, whoever that is, you don't reveal it, so even users of that
> system wouldn't necessarily recognize it. I know nothing about it and
> will not support it. FETCHMAIL_RC_PATH is not from fetchmail either but
> also that third party systemd whatever.
> 
> Finally, "localhost" isn't a proper fully-qualified domain name, so the
> system isn't correctly set up, and I've just last week-end explained
> that to another user here:
> <https://gitlab.com/fetchmail/fetchmail/issues/12>, and in particular,
> <https://gitlab.com/fetchmail/fetchmail/issues/12#note_280354348> and
> <https://gitlab.com/fetchmail/fetchmail/issues/12#note_280567189>.
> 
> Setting up mail systems requires a careful, patient and iterative
> approach and not hasty reactions. Sorry again.
> 
> Cheers,
> Matthias
> 

Thanks for your reply and pointers.

The solution to the immediate problem had to do with ownership of the file
name provided by the variable ($FETCHMAIL_RC_PATH), which in this case 
was "/etc/fetchmailrc".  When ownership was changed to "fetchmail", the 
systemd startup magic was satisfied and fetchmail started upon system startup.

Sorry I did not specify that the new OS is of current vintage and provided nearly 
up to date versions of fetchmail (6.3.26), Postfix and Spamassassin.

I chose to use the OS packaged versions for ease of setup and will certainly 
update to the latest versions rather soon.   

Yes, there were some incomplete items, such as /etc/hosts entries while 
setting up and testing one bit at a time.   

The old system was in place and operational until the newer one was well
tested.

It all actually progressed much more smoothly than I had thought likely 
and has been working well for several days.

Thank you for a solid product.

joe a.

Re: [Fetchmail-users] systemd start error

[Matthias A. <mat...@gm...>]

Am 03.02.20 um 02:00 schrieb Joe Acquisto-j4:
> Migrated to a new platform,  installed the provided package, fetchmail 6.3.26 just to ease my pain.
>
> All works fine loading fetchmail manually but I cannot get fetchmail to start on boot.   Just starting familiarization with systemd.
>
> This is what I get from systemctl status fetchmail:
>
> Feb 02 19:48:53 localhost systemd[1]: Started A remote-mail retrieval utility.
> Feb 02 19:48:53 localhost fetchmail-systemd-exec[13677]: $FETCHMAIL_RC_PATH does not exist or cannot be read
>
> I moved /root/.fetchmailrc to /etc/fetchmail, where it seemed to be expected to be.  Still objected.  Changed file permissions and was told it could only be 700.  Set it back, same result.
>
> What could be the issue?  Ownership?

Joe,

I am sorry to write that this has just taken you further away from a
solution because you brought unknown third-party launcher scripts to the
table. Answering those questions you pose would amount to guesswork or
massive remote debugging, and we can't help you on this list with a
third-party package.

Reason, the systemd stuff that your outdated package has provided you
with is not part of fetchmail, but has been provided by your package
provider, whoever that is, you don't reveal it, so even users of that
system wouldn't necessarily recognize it. I know nothing about it and
will not support it. FETCHMAIL_RC_PATH is not from fetchmail either but
also that third party systemd whatever.

Finally, "localhost" isn't a proper fully-qualified domain name, so the
system isn't correctly set up, and I've just last week-end explained
that to another user here:
<https://gitlab.com/fetchmail/fetchmail/issues/12>, and in particular,
<https://gitlab.com/fetchmail/fetchmail/issues/12#note_280354348> and
<https://gitlab.com/fetchmail/fetchmail/issues/12#note_280567189>.

Setting up mail systems requires a careful, patient and iterative
approach and not hasty reactions. Sorry again.

Cheers,
Matthias

[Fetchmail-users] systemd start error

[Joe Acquisto-j. <jo...@j4...>]

Migrated to a new platform,  installed the provided package, fetchmail 6.3.26 just to ease my pain.

All works fine loading fetchmail manually but I cannot get fetchmail to start on boot.   Just starting familiarization with systemd.

This is what I get from systemctl status fetchmail:

Feb 02 19:48:53 localhost systemd[1]: Started A remote-mail retrieval utility.
Feb 02 19:48:53 localhost fetchmail-systemd-exec[13677]: $FETCHMAIL_RC_PATH does not exist or cannot be read

I moved /root/.fetchmailrc to /etc/fetchmail, where it seemed to be expected to be.  Still objected.  Changed file permissions and was told it could only be 700.  Set it back, same result.

What could be the issue?  Ownership?

joe a. 

Re: [Fetchmail-users] syntax error at user

[Joe Acquisto-j. <jo...@j4...>]

>

> 
>>>>
>> Am 29.01.20 um 23:43 schrieb Joe Acquisto-j4:
Decided to test 6.4.1 as 64 bit on a 64 bit machine. Copied .fetchmailrc 
>> from working machine and commented out all but one test user.
>>>
>>> Trying to run from command line or install as daemon get:
>>>
>>> "fetchmail:/root/.fetchmailrc:15: syntax error at user."
>>>
>>> I followed some online examples, changing user to -u, removing single quotes 
>> around user name, no change.
>>>
>>> The user name does take the form of "us...@do...".
>>>
>>> I have not found a document that specifically addresses .fetchmailrc syntax 
>> changes  although I may recall having seen one.
>> 
>> 
>> show us something that we can possibly help with...  but note you need
>> line that starts with "poll" or possibly "skip",
>> such a copy of the .fetchmailrc with the domain replaced by .example.org
>> and the password as XXXXXXXX.
>> 
>> You may want to add --keep to your command line.
>> 
> 
> This is a snipped of .fetchmail.rc
> 
> -------
> set nobouncemail
> set no spambounce
> set properties ""
> set daemon 240
> 
> poll mail.somehost.com with proto IMAP timeout 120 envelope Delivered-to
> 
> #    user 'xx...@xx...' there with password 'x' is 'xx...@xx...' folder 
> 'Inbox','Junk' fetchlimit 5   ssl sslfingerprint "blah"
>     smtphost  192.168.0.ddd preconnect "/bin/date >> /var/log/fetchmail.log"
> 
>     user 'aa...@xx...' there with password 'x2' is 'aa...@xx...' 
> here folder 'Inbox','Junk' fetchlimit 5  ssl sslfingerprint "blah"
>     smtphost  192.168.0.ddd preconnect "/bin/date >> /var/log/fetchmail.log"
> --------
> 
> Thanks.
> 

Operator malfunction.  I did not comment out smpthost, which seemed to be the issue.  

I realized this when thinking I would try to "escape" the dot in the user name or try a user without a dot.

One good thing about winter, my coat is always nearby . . .

There are still some issues, such as the secure connection failing as the string does not match, but 
we shall see.   

joe a.

-- 
+++++++++++++++++++++++
         joea@@j4computers.com
      https://www.j4computers.com
               845-687-3734
+++++++++++++++++++++++

Re: [Fetchmail-users] syntax error at user

[Joe Acquisto-j. <jo...@j4...>]

>>>
> Am 29.01.20 um 23:43 schrieb Joe Acquisto-j4:
>> Decided to test 6.4.1 as 64 bit on a 64 bit machine. Copied .fetchmailrc 
> from working machine and commented out all but one test user.
>>
>> Trying to run from command line or install as daemon get:
>>
>> "fetchmail:/root/.fetchmailrc:15: syntax error at user."
>>
>> I followed some online examples, changing user to -u, removing single quotes 
> around user name, no change.
>>
>> The user name does take the form of "us...@do...".
>>
>> I have not found a document that specifically addresses .fetchmailrc syntax 
> changes  although I may recall having seen one.
> 
> 
> show us something that we can possibly help with...  but note you need
> line that starts with "poll" or possibly "skip",
> such a copy of the .fetchmailrc with the domain replaced by .example.org
> and the password as XXXXXXXX.
> 
> You may want to add --keep to your command line.
> 

This is a snipped of .fetchmail.rc

-------
set nobouncemail
set no spambounce
set properties ""
set daemon 240

poll mail.somehost.com with proto IMAP timeout 120 envelope Delivered-to

#    user 'xx...@xx...' there with password 'x' is 'xx...@xx...' folder 'Inbox','Junk' fetchlimit 5   ssl sslfingerprint "blah"
    smtphost  192.168.0.ddd preconnect "/bin/date >> /var/log/fetchmail.log"

    user 'aa...@xx...' there with password 'x2' is 'aa...@xx...' here folder 'Inbox','Junk' fetchlimit 5  ssl sslfingerprint "blah"
    smtphost  192.168.0.ddd preconnect "/bin/date >> /var/log/fetchmail.log"
--------

Thanks.

-- 
+++++++++++++++++++++++
         joea@@j4computers.com
      https://www.j4computers.com
               845-687-3734
+++++++++++++++++++++++

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[Matthias A. <mat...@gm...>]

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.

Re: [Fetchmail-users] syntax error at user

[Matthias A. <mat...@gm...>]

Am 29.01.20 um 23:43 schrieb Joe Acquisto-j4:
> Decided to test 6.4.1 as 64 bit on a 64 bit machine. Copied .fetchmailrc from working machine and commented out all but one test user.
>
> Trying to run from command line or install as daemon get:
>
> "fetchmail:/root/.fetchmailrc:15: syntax error at user."
>
> I followed some online examples, changing user to -u, removing single quotes around user name, no change.
>
> The user name does take the form of "us...@do...".
>
> I have not found a document that specifically addresses .fetchmailrc syntax changes  although I may recall having seen one.


show us something that we can possibly help with...  but note you need
line that starts with "poll" or possibly "skip",
such a copy of the .fetchmailrc with the domain replaced by .example.org
and the password as XXXXXXXX.

You may want to add --keep to your command line.

[Fetchmail-users] syntax error at user

[Joe Acquisto-j. <jo...@j4...>]

Decided to test 6.4.1 as 64 bit on a 64 bit machine. Copied .fetchmailrc from working machine and commented out all but one test user.

Trying to run from command line or install as daemon get:

"fetchmail:/root/.fetchmailrc:15: syntax error at user."

I followed some online examples, changing user to -u, removing single quotes around user name, no change.

The user name does take the form of "us...@do...".

I have not found a document that specifically addresses .fetchmailrc syntax changes  although I may recall having seen one.



-- 
+++++++++++++++++++++++
         joea@@j4computers.com
      https://www.j4computers.com
               845-687-3734
+++++++++++++++++++++++

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[Joe Acquisto-j. <jo...@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. 



-- 
+++++++++++++++++++++++
         joea@@j4computers.com
      https://www.j4computers.com
               845-687-3734
+++++++++++++++++++++++

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[grarpamp <gra...@gm...>]

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

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[Joe Acquisto-j. <jo...@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.
> 
> 
> _______________________________________________
> 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
+++++++++++++++++++++++

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[grarpamp <gra...@gm...>]

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

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[Joe Acquisto-j. <jo...@j4...>]

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

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[Joe Acquisto-j. <jo...@j4...>]

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

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[Ralph C. <ra...@in...>]

Hi Joe,

> linux-jod1:~/fetchmail-6.4.1 # make

Try

    make clean all

-- 
Cheers, Ralph.

Re: [Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[Peter P. <ro...@ri...>]

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

[Fetchmail-users] compiling fetchmail as 32 bit on a 64 bit machine

[Joe Acquisto-j. <jo...@j4...>]

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

Re: [Fetchmail-users] updating

[Joe Acquisto-j. <jo...@j4...>]

Drawing board time.   The binary actually resides in /usr/local/bin/ despite what the conf showed at first casual glance.

There is an issue with the 32bit machine refusing to run the binary, which might relate to being compiled on a purpose built 
64 bit machine.  No good deed goes unpunished.

joe a.


>>>
> So, complied 6.4.1 on another box and copied it to running machine, rename 
> old binary and dropped in newly compiled one at /usr/bin/fetchmail, where the 
> start script shows it to be expected.
> 
> killed the running version, before renaming the old one and restarted with 
> the in place.  However, both the help file and /var/log/fetchmail.log show 
> verison 6.3.26.
> 
> This seems quite impossible, unless the binary looks elsewhere to read and 
> output that information.   Speaking as a programming layman/novice, this 
> seems unlikely.
> 
> joe a.
> 
> -- 
> +++++++++++++++++++++++
>          joea@@j4computers.com
>       https://www.j4computers.com 
>                845-687-3734
> +++++++++++++++++++++++
> 
> 
> _______________________________________________
> Fetchmail-users mailing list
> Fet...@li... 
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users

-- 
+++++++++++++++++++++++
         joea@@j4computers.com
      https://www.j4computers.com
               845-687-3734
+++++++++++++++++++++++