wget 1.14 - again this dynamic vs static thing, mainly

[Lewis Rosenthal]

Hi, all...

I'm at it again. One of these days, I may actually be able to get what I
want right out of the gate. Thanks again for bearing with me.

So, I pulled the source for wget 1.14. I am able to build it and get a
working wget.exe, with the following tweaks:

Using bash:

./configure --with-ssl=openssl --enable-threads=pth

Once that's done, I need to tweak src\Makefile to set PERL where I want it:

PERL = J:/perl5/bin/perl.exe

If I allow configure to use PERL_SH_DIR set to J:/usr/bin, I get:

j:/usr/bin/bash: cannot find J:userbin/perl

(or similar). I realize this is a shell thing with the path delimiter,
but no matter what I do, I can't get it to expand that properly, nor can
I simply copy perl.exe to, say, J:\userbin. Also, this comes about as a
result of my installing perl 5.16.1 via yum (I just installed rpm-build,
which grabbed that as a dep - I should have overridden it, as my
installed 5.14.2 in J:\perl5 works quite well).

Next, I run make, which stalls here:

redefinition of 'struct sched_param' in lib\sched.h

I get around this by commenting out from line 41 in the (then-created)
lib\sched.h:

# if !GNULIB_defined_struct_sched_param
struct sched_param
{
int sched_priority;
};
# define GNULIB_defined_struct_sched_param 1
# endif

I'd like a more elegant way of working around that, as well as an
understanding of what I just hacked out (and whether it might break
anything - though my admittedly minimal tests would seem to indicate
otherwise).

Running make again, I notice a slew of warnings related to intltool, e.g.:

log.h:44: warning: 'libintl_printf' is an unrecognized \
format function type

(I just added internationalization support on my last run, so I've just
started seeing these.) FWIW, log.h consists of:

----

#ifndef LOG_H
#define LOG_H

/* The log file to which Wget writes to after HUP. */
#define DEFAULT_LOGFILE "wget-log"

#include <stdio.h>

enum log_options { LOG_VERBOSE, LOG_NOTQUIET, LOG_NONVERBOSE, LOG_ALWAYS };

void log_set_warc_log_fp (FILE *);

void logprintf (enum log_options, const char *, ...)
GCC_FORMAT_ATTR (2, 3);
void debug_logprintf (const char *, ...) GCC_FORMAT_ATTR (1, 2);
void logputs (enum log_options, const char *);
void logflush (void);
void log_set_flush (bool);
bool log_set_save_context (bool);

void log_init (const char *, bool);
void log_close (void);
void log_cleanup (void);
void log_request_redirect_output (const char *);

const char *escnonprint (const char *);
const char *escnonprint_uri (const char *);

#endif /* LOG_H */

----

Logging seems to work for me. Is that issue perhaps the same as
http://lists.gnu.org/archive/html/bug-gnu-utils/2006-06/msg00050.html ?

And finally, directly related to the subject of this thread, when I'm
done, I get a working executable, with the following dependencies:

zlib-1.2.5-4.oc00.i386
openssl-1.0.0a-5.oc00.i386
libgcc446-4.4.6-15.oc00.i386
pcre-8.12-2.oc00.i386
os2-mpts-0.0.0-2.oc00.i386
libc-0.6.5-17.oc00.i386
intltool-0.41.1-3.oc00.noarch

Trying to circumvent the need for, say z.dll, specifying:

-llibz_s.a

throws an error that the file cannot be found:

No such file or directory for libz_s.a

(and it is, in fact, in J:\usr\lib). I've also tried specifying the full
path (with slashes, with and without the drive), and get the same result.

As with unzip, what I'd really like to end up with is a fairly portable
executable. tcpip32, libc065, and even gcc446 would be fine (tcpip32
would be kind of silly to statically link, as without a working IP
stack, wget is rather pointless), but zlib, pcre, openssl, and the intl
stuff would be nice to not have to have on hand.

Thoughts on how to get me unstuck?

;-)

TIA

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC www.2rosenthals.com
Need a managed Wi-Fi hotspot? www.hautspot.com
visit my IT blog www.2rosenthals.net/wordpress
-------------------------------------------------------------

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Dave Yeo]

Lewis Rosenthal wrote:
> Hi, all...
>
> I'm at it again. One of these days, I may actually be able to get what I
> want right out of the gate. Thanks again for bearing with me.
>
> So, I pulled the source for wget 1.14. I am able to build it and get a
> working wget.exe, with the following tweaks:
>
> Using bash:

Don't use bash. Personally I like [pdk]sh.exe, others like ash but ash
is missing some functionality (pdksh is also missing things like
beginlibpath and libpathstrict support as it's ancient)

>
> ./configure --with-ssl=openssl --enable-threads=pth
>
> Once that's done, I need to tweak src\Makefile to set PERL where I want it:
>
> PERL = J:/perl5/bin/perl.exe
>
> If I allow configure to use PERL_SH_DIR set to J:/usr/bin, I get:
>
> j:/usr/bin/bash: cannot find J:userbin/perl

I usually see that problem with \, try using double slashes or add the
PERL = line in your config.site and forget about it.

>
> (or similar). I realize this is a shell thing with the path delimiter,
> but no matter what I do, I can't get it to expand that properly, nor can
> I simply copy perl.exe to, say, J:\userbin. Also, this comes about as a
> result of my installing perl 5.16.1 via yum (I just installed rpm-build,
> which grabbed that as a dep - I should have overridden it, as my
> installed 5.14.2 in J:\perl5 works quite well).
>
> Next, I run make, which stalls here:
>
> redefinition of 'struct sched_param' in lib\sched.h
>
> I get around this by commenting out from line 41 in the (then-created)
> lib\sched.h:
>
> # if !GNULIB_defined_struct_sched_param
> struct sched_param
> {
> int sched_priority;
> };
> # define GNULIB_defined_struct_sched_param 1
> # endif

The place to modify this is in lib/sched.in.h, simplest is to add
#ifndef __KLIBC__ to line 24 and an #endif at the end of the file.
Ideally is to check if this is a problem with EMX and other compilers
and depending use __EMX__ or __OS2__. Of course the elegant way is to
test in configure.

>
> I'd like a more elegant way of working around that, as well as an
> understanding of what I just hacked out (and whether it might break
> anything - though my admittedly minimal tests would seem to indicate
> otherwise).

The code block needs to be disabled as we have it in libc.

>
> Running make again, I notice a slew of warnings related to intltool, e.g.:
>
> log.h:44: warning: 'libintl_printf' is an unrecognized \
> format function type
>
> (I just added internationalization support on my last run, so I've just
> started seeing these.) FWIW, log.h consists of:
>

[...]

>
> Logging seems to work for me. Is that issue perhaps the same as
> http://lists.gnu.org/archive/html/bug-gnu-utils/2006-06/msg00050.html ?

Probably. I don't have an kLIBC libintl installed here. I guess you
could change %LANG% IIRC and see if it works as expected but I don't
know much about internationalization.

>
> And finally, directly related to the subject of this thread, when I'm
> done, I get a working executable, with the following dependencies:
>
> zlib-1.2.5-4.oc00.i386
> openssl-1.0.0a-5.oc00.i386
> libgcc446-4.4.6-15.oc00.i386
> pcre-8.12-2.oc00.i386
> os2-mpts-0.0.0-2.oc00.i386
> libc-0.6.5-17.oc00.i386
> intltool-0.41.1-3.oc00.noarch
>
> Trying to circumvent the need for, say z.dll, specifying:
>
> -llibz_s.a
>
> throws an error that the file cannot be found:
>
> No such file or directory for libz_s.a

Linking with -l doesn't work that way the lib prefix and _s.a suffix are
ignored by the linker (does work if treating like an object file).
The correct way is to use LDFLAGS such as -Bstatic, -non_shared, -dn, or
-static. This only works for some versions of GCC. The other way is to
move the import lib out of the way so the linker can only find libz_s.a
when fed -lz. Same with the others if there are static libs installed.
You might have to rebuild things like pcre with configure
--disable-shared --enable-static. Not sure if openssl will really work
as static and it should be update-able anyways in case of security holes.
Statically linking libc is broken, for gcc I have set
GCCOPT=-static-libgcc in my environment. People shouldn't need umpteen
gcc dlls installed for the sake of a couple of bytes.
BTW, does GPL v3 allow distributing code linked to openssl? I know GPL
v2 doesn't. That's the problem with GPL, too strict.

>
> (and it is, in fact, in J:\usr\lib). I've also tried specifying the full
> path (with slashes, with and without the drive), and get the same result.
>
> As with unzip, what I'd really like to end up with is a fairly portable
> executable. tcpip32, libc065, and even gcc446 would be fine (tcpip32
> would be kind of silly to statically link, as without a working IP
> stack, wget is rather pointless), but zlib, pcre, openssl, and the intl
> stuff would be nice to not have to have on hand.
>
> Thoughts on how to get me unstuck?
>
> ;-)
>
> TIA
>

Dave

[gianf...@gmail.com]

Il giorno sabato 15 giugno 2013 23:39:08 UTC+2, Lewis Rosenthal ha scritto:

> I realize this is a shell thing with the path delimiter,
>
> but no matter what I do, I can't get it to expand that properly, nor can
>
> I simply copy perl.exe to, say, J:\userbin. Also, this comes about as a
>
> result of my installing perl 5.16.1 via yum (I just installed rpm-build,
>
> which grabbed that as a dep - I should have overridden it, as my
>
> installed 5.14.2 in J:\perl5 works quite well).

I've tryed it instead last week, but i've got a SSP.DLL problem (if i remember well, cannot run in OS/2 session), i've not investigate so much, backward to the 5.14 that works reasonably well (changed instead autoreconf 2.65 from Netlabs), but the output is the same.

[Lewis Rosenthal]

On 06/15/13 11:18 pm, Dave Yeo thus wrote :

> Lewis Rosenthal wrote:
>> Hi, all...
>>
>> I'm at it again. One of these days, I may actually be able to get what I
>> want right out of the gate. Thanks again for bearing with me.
>>
>> So, I pulled the source for wget 1.14. I am able to build it and get a
>> working wget.exe, with the following tweaks:
>>
>> Using bash:
>
> Don't use bash. Personally I like [pdk]sh.exe, others like ash but ash
> is missing some functionality (pdksh is also missing things like
> beginlibpath and libpathstrict support as it's ancient)
>

I'll take that as good advice. There are some things in a shell to which
I've become accustomed, probably most important is tab completion, as
paths have become longer and more involved. I can't even tell which
version of sh.exe I have installed, let alone whether it is pdksh or
bash (as opposed to bash.exe, which reports:

GNU bash, version 3.2.0(1)-release-(i386-ibm-os2)

both sh.exe and bash.exe on my system date from 2006 (not that that is
any real indication as to how old they really are):

3-18-06 20:26 62,326 124 sh.exe
12-04-06 18:13 423,573 124 bash.exe

Looking now, I see that KO uploaded his build of pdksh 5.2.14 in April.
I'll grab that and give it a spin.

>>
>> ./configure --with-ssl=openssl --enable-threads=pth
>>
>> Once that's done, I need to tweak src\Makefile to set PERL where I
>> want it:
>>
>> PERL = J:/perl5/bin/perl.exe
>>
>> If I allow configure to use PERL_SH_DIR set to J:/usr/bin, I get:
>>
>> j:/usr/bin/bash: cannot find J:userbin/perl
>
> I usually see that problem with \, try using double slashes or add the
> PERL = line in your config.site and forget about it.
>

Good tip about perl.site, as well as trying the double slashes. I'll
check out both of those. Thanks.

>>
>> (or similar). I realize this is a shell thing with the path delimiter,
>> but no matter what I do, I can't get it to expand that properly, nor can
>> I simply copy perl.exe to, say, J:\userbin. Also, this comes about as a
>> result of my installing perl 5.16.1 via yum (I just installed rpm-build,
>> which grabbed that as a dep - I should have overridden it, as my
>> installed 5.14.2 in J:\perl5 works quite well).
>>
>> Next, I run make, which stalls here:
>>
>> redefinition of 'struct sched_param' in lib\sched.h
>>
>> I get around this by commenting out from line 41 in the (then-created)
>> lib\sched.h:
>>
>> # if !GNULIB_defined_struct_sched_param
>> struct sched_param
>> {
>> int sched_priority;
>> };
>> # define GNULIB_defined_struct_sched_param 1
>> # endif
>
> The place to modify this is in lib/sched.in.h, simplest is to add
> #ifndef __KLIBC__ to line 24 and an #endif at the end of the file.
> Ideally is to check if this is a problem with EMX and other compilers
> and depending use __EMX__ or __OS2__. Of course the elegant way is to
> test in configure.
>

Thanks for the clarification. One of these days, I'll get the hang of
what's supposed to get fixed where and when.

>>
>> I'd like a more elegant way of working around that, as well as an
>> understanding of what I just hacked out (and whether it might break
>> anything - though my admittedly minimal tests would seem to indicate
>> otherwise).
>
> The code block needs to be disabled as we have it in libc.
>
>>
>> Running make again, I notice a slew of warnings related to intltool,
>> e.g.:
>>
>> log.h:44: warning: 'libintl_printf' is an unrecognized \
>> format function type
>>
>> (I just added internationalization support on my last run, so I've just
>> started seeing these.) FWIW, log.h consists of:
>>
> [...]
>>
>> Logging seems to work for me. Is that issue perhaps the same as
>> http://lists.gnu.org/archive/html/bug-gnu-utils/2006-06/msg00050.html ?
>
> Probably. I don't have an kLIBC libintl installed here. I guess you
> could change %LANG% IIRC and see if it works as expected but I don't
> know much about internationalization.
>

Okay.

Thanks so much for the excellent description of how the linker observes
options. I truly had *no* idea, Dave.

I agree 100% about gcc and it being ridiculous to require every user to
have all of that stuff on hand - particularly for small, single-use
applications.

As for licensing, apparently GNU Wget includes an exception allowing
OpenSSL to be used. From README:

Additional permission under GNU GPL version 3 section 7
If you modify this program, or any covered work, by linking or
combining it with the OpenSSL project's OpenSSL library (or a
modified version of that library), containing parts covered by the
terms of the OpenSSL or SSLeay licenses, the Free Software Foundation
grants you additional permission to convey the resulting work.
Corresponding Source for a non-source form of such a combination
shall include the source code for the parts of OpenSSL used as well
as that of the covered work.

Thanks for mentioning that, though. I had forgotten that OpenSSL used
the Apache 1.0 *and* SSLeay licenses.

>>
>> (and it is, in fact, in J:\usr\lib). I've also tried specifying the full
>> path (with slashes, with and without the drive), and get the same result.
>>
>> As with unzip, what I'd really like to end up with is a fairly portable
>> executable. tcpip32, libc065, and even gcc446 would be fine (tcpip32
>> would be kind of silly to statically link, as without a working IP
>> stack, wget is rather pointless), but zlib, pcre, openssl, and the intl
>> stuff would be nice to not have to have on hand.
>>
>> Thoughts on how to get me unstuck?
>>
>> ;-)
>>
>> TIA
>>
>

Thanks for all of the great info, Dave (got busy with other stuff, which
delayed my response). You're a pal.

Cheers

[Lewis Rosenthal]

On 06/16/13 03:10 am, gianf...@gmail.com thus wrote :

So, you have not checked yet whether you get the same error under 5.14
as under 5.16?

Just curious. I'm going to uninstall 5.16 as soon as I can get it
untangled (I really wanted to test building some rpms, and that seems to
be a dependency, but I haven't confirmed it, as yet).

Cheers/2

[Dave Yeo]

Lewis Rosenthal wrote:
>>> Using bash:
>> >
>> > Don't use bash. Personally I like [pdk]sh.exe, others like ash but ash
>> > is missing some functionality (pdksh is also missing things like
>> > beginlibpath and libpathstrict support as it's ancient)
>> >
> I'll take that as good advice. There are some things in a shell to which
> I've become accustomed, probably most important is tab completion, as
> paths have become longer and more involved. I can't even tell which
> version of sh.exe I have installed, let alone whether it is pdksh or
> bash (as opposed to bash.exe, which reports:
>
> GNU bash, version 3.2.0(1)-release-(i386-ibm-os2)

For actually using as a shell, bash may be better depending on the port.
I have at least 4 ports here, each with their pluses and minuses. For
running configure scripts, perl stuff and anything else that calls for
sh, [pdk]sh.exe. Helps sometimes to have it installed in \bin

>
> both sh.exe and bash.exe on my system date from 2006 (not that that is
> any real indication as to how old they really are):
>
> 3-18-06 20:26 62,326 124 sh.exe
> 12-04-06 18:13 423,573 124 bash.exe
>
> Looking now, I see that KO uploaded his build of pdksh 5.2.14 in April.
> I'll grab that and give it a spin.
>

Yes, make sure to use his build as he fixed a crash or 2
Dave

[gianf...@gmail.com]

Il giorno giovedì 20 giugno 2013 20:44:18 UTC+2, Lewis Rosenthal ha scritto:
> So, you have not checked yet whether you get the same error under 5.14
>
> as under 5.16?
>
>
>
> Just curious. I'm going to uninstall 5.16 as soon as I can get it
>
> untangled (I really wanted to test building some rpms, and that seems to
>
> be a dependency, but I haven't confirmed it, as yet).

No, i don't checked this, for me it was a moment, I only spent the time to install, run testperl and a few other commands like autoreconf knew that generate the error.