Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.os.os2.programmer.porting > #250

Re: wget 1.14 - again this dynamic vs static thing, mainly

Show all headers | View raw

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.

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

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
-------------------------------------------------------------
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: news@netfront.net ---

Back to comp.os.os2.programmer.porting | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

wget 1.14 - again this dynamic vs static thing, mainly Lewis Rosenthal <lgrosenthal@2-de-sp-am-2rosenthals.com> - 2013-06-15 17:39 -0400
  Re: wget 1.14 - again this dynamic vs static thing, mainly Dave Yeo <dave.r.yeo@gmail.com> - 2013-06-15 20:18 -0700
    Re: wget 1.14 - again this dynamic vs static thing, mainly Lewis Rosenthal <lgrosenthal@2-de-sp-am-2rosenthals.com> - 2013-06-20 14:11 -0400
      Re: wget 1.14 - again this dynamic vs static thing, mainly Dave Yeo <dave.r.yeo@gmail.com> - 2013-06-20 17:15 -0700
  Re: wget 1.14 - again this dynamic vs static thing, mainly gianfli.cim@gmail.com - 2013-06-16 00:10 -0700
    Re: wget 1.14 - again this dynamic vs static thing, mainly Lewis Rosenthal <lgrosenthal@2-de-sp-am-2rosenthals.com> - 2013-06-20 14:44 -0400
      Re: wget 1.14 - again this dynamic vs static thing, mainly gianfli.cim@gmail.com - 2013-06-21 21:52 -0700

csiph-web