Date: Mon, 5 Apr 2004 00:04:04 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 337 ************************************************** Sunday 04 April 2004 Number 337 ************************************************** Subjects for today 1 Patching Berkeley DB : John Poltorak 2 Re: Building DLLs : Stefan Neis 3 GNU Autoconf, Automake and Libtool : John Poltorak 4 configure.in for ZLIB : John Poltorak 5 Re: Building DLLs : Stefan Neis 6 Re: Building DLLs : Thomas Dickey 7 Re: Targets in Makefiles : lamikr 8 Re: Autoconf v2.59 : Andreas Buening **= Email 1 ==========================** Date: Sat, 3 Apr 2004 16:19:57 +0000 From: John Poltorak Subject: Patching Berkeley DB There is a patch for Berkeley DB v4.1.25 here:- ftp://ftp.zolotek.net/os2/patch.db-4.1.25 This makes it build on OS/2 by running 'make install_os2'. What I would prefer is for it to work corretly when I just run make install. I guess that would work if I used this patch and just changed the names of a few makefile targets, but I'm not sure just waht to change. Can anyone advise? -- John **= Email 2 ==========================** Date: Sat, 3 Apr 2004 20:32:44 +0200 (CEST) From: Stefan Neis Subject: Re: Building DLLs On Thu, 1 Apr 2004, Knut St. Osmundsen wrote: > Stefan Neis wrote: > > > > share a "long" common prefix: gcc -Zdll ... complains about the > > symbols being identical, although they are not. Is that a limitation > > of a.out build (i.e. you just have to use -Zomf for such DLLs) or is > > there some special linker flag which would enable building a.out > > versions as well? > > Can you give examples of these long symbol names? And how long are > 'long' in this case? Sorry for the late reply, I had to get to my wxWindows box first and recreate the problem ... I get stuff like this: ... emxbind: export multiply defined: append__8wxStringPCc when in fact I'm trying to export three different symbols, namely: "append__8wxStringPCc" "append__8wxStringPCcT1" "append__8wxStringPCcUl" If I remove two of those symbols, I get a DLL... I should mention that this is with plain EMX (gcc-2.8.1), so updating emxbind to e.g. gcc-3.0.3 level might help? > I don't think a.out have a symbol length limitation worse than OMF, so > I'm curious about what trouble you're seeing. It's likely a linker bug, > and if it works with the OMF linkers you'll have to stick with using > that untill I get the binutils ld fixed. Also, OMF builds of DLLs work fine with Innotek, but not with plain EMX, which is complaining about multiply defined symbols again, interestingly those are different one than for the a.out build, i.e. I seem to have no more problems with similar names but weak symbols contained in several translation unit seem to be a problem. > There is no flag for building both a.out and omf binaries, that doesn't > make much sense IMHO. Actually, I meant to say that since OMF builds work just fine, is there a magic flag to make a.out builds work, too. Not at the same time, but as an alternative (assuming I have a working gdb, a.out builds would be my prefered debug target)... Regards, Stefan **= Email 3 ==========================** Date: Sat, 3 Apr 2004 19:51:59 +0000 From: John Poltorak Subject: GNU Autoconf, Automake and Libtool Has anyone ever come across this book:- ? http://sources.redhat.com/autobook/ Things seemed to have changed a great deal sine the book came out and I'm wondering how useul it would be in being able to get to grips with recent versions of Autoconf, Automake and Libtool... The whole book is online anyway, so I guess I can try reading it on my computer, but that isn't as easy as browsing through a book. I'd be interested to know if anyone has found the book useful. -- John **= Email 4 ==========================** Date: Sat, 3 Apr 2004 20:28:24 +0000 From: John Poltorak Subject: configure.in for ZLIB I get the feeling that the developers of ZLIB don't know how to use Autoconf/Automake and wondered how hard it would be to develop from scratch a configure.in and makefile.am file for ZLIB... Is there anything like a template available for such files? -- John **= Email 5 ==========================** Date: Sat, 3 Apr 2004 22:10:13 +0200 (CEST) From: Stefan Neis Subject: Re: Building DLLs On Sat, 3 Apr 2004, Stefan Neis wrote: > emxbind: export multiply defined: append__8wxStringPCc > > when in fact I'm trying to export three different symbols, namely: > "append__8wxStringPCc" > "append__8wxStringPCcT1" > "append__8wxStringPCcUl" > > If I remove two of those symbols, I get a DLL... > I should mention that this is with plain EMX (gcc-2.8.1), so updating > emxbind to e.g. gcc-3.0.3 level might help? Actually, I have similar problems with Innotek's gcc port (god, gcc-3.2.x really _is_ slow, compared to 2.8.1!). Here, the conflicting symbols seem to be e.g. "__ZN14wxBaseArrayInt5clearEv" "__ZN14wxBaseArrayInt5ClearEv" Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 6 ==========================** Date: Sat, 3 Apr 2004 15:25:01 -0500 (EST) From: Thomas Dickey Subject: Re: Building DLLs On Sat, 3 Apr 2004, Stefan Neis wrote: > On Sat, 3 Apr 2004, Stefan Neis wrote: > > > emxbind: export multiply defined: append__8wxStringPCc > > > > when in fact I'm trying to export three different symbols, namely: > > "append__8wxStringPCc" > > "append__8wxStringPCcT1" > > "append__8wxStringPCcUl" > > > > If I remove two of those symbols, I get a DLL... > > I should mention that this is with plain EMX (gcc-2.8.1), so updating > > emxbind to e.g. gcc-3.0.3 level might help? > > Actually, I have similar problems with Innotek's gcc port (god, gcc-3.2.x > really _is_ slow, compared to 2.8.1!). Here, the conflicting symbols seem > to be e.g. > "__ZN14wxBaseArrayInt5clearEv" > "__ZN14wxBaseArrayInt5ClearEv" Doesn't "nm -C" demangle the names? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 7 ==========================** Date: Sun, 04 Apr 2004 00:26:03 +0300 From: lamikr Subject: Re: Targets in Makefiles I don't think it will be too bad. It's only for apps which have >dependenies on other apps, ie both Zope and Mailman depend on Python >having being installed > > Mandrake Linux uses a program called urpmi for the dependency check during the installation. Urpmi is a command line extension for rpm and has been written in perl. If I call "urpmi galeon" urpmi would first download all other programs and libraries from where the galeon.rpm depends if they are not already installed. Dependencies are itself written into standard rpm files. more information can be found from the address www.urpmi.org Mika **= Email 8 ==========================** Date: Sun, 04 Apr 2004 00:52:33 +0100 From: Andreas Buening Subject: Re: Autoconf v2.59 John Poltorak wrote: > After removing the changes due to /bin/sh and $UNIXROOT I came up with the > attached diff.. Thank you very much! Bye, Andreas