httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Khimenko Victor" <>
Subject Re: Solution for weird DSO issues
Date Fri, 23 Jul 1999 13:01:34 GMT
22-Jul-99 08:51 you wrote:

RE> In article <> you

>> We put a workaround into PHP a while ago which wrapped fclose in a static
>> function and we would pass that pointer instead.  And that solved it.
>> But after discussing the issue with H.J. Lu and getting some background on
>> these IO_new_fclose and IO_old_fclose calls that were put in for backwards
>> compatibility reasons he pointed out that we really should not be building
>> shared libs using ld -Bshareable.  We should be using gcc -shared.  And
>> sure enough, building the PHP DSO using gcc -shared solved the problems.
>> The direct quote from H.J. Lu was:
>>   Never, never, never, never call "ld" directly to generate DSO
>>   unless you know what you are doing. You should use "gcc -shared"
>>   instead of "ld -Bshareable". Please read
>> So, before we release Apache-1.3.7, I'd like to tweak apxs to use gcc
>> -shared instead of ld -Bshareable on systems where we build with gcc unles
>> someone objects.  Or Ralf, if you are listening, do you want to do it?

RE> I cannot do it myself, but I can review patches someelse contributes.  But we
RE> have to be carefully here: It's correct that "gcc -shared" is more correct
RE> than fiddling around with "ld" ourself, _BUT_ not all GCC installations
RE> support "gcc -shared", i.e. on a lot it's broken. So we cannot do a general
RE> "gcc => use -shared for DSO building" rule, of course. It has to be done on a
RE> per-platform basis. And even there it would be good to add a real-life test
RE> before, because especially under Linux systems there exists a wide range of
RE> GCC installations and I'm sure at least 20% are broken at "gcc -shared".

With GLibC 2.1 you can not compile mod_rewrite as DSO with `ld -Bshareable' but
can with `gcc -shared', for example (why? due lstat usage: lstat is not included
in shared version of libc but instead is included in libc_nonshared.a; gcc -shared
will link with libc_nonshared.a for you and will be loadable but
`ld -Bshareable' will make reference to lstat and since lstat can not be found
in neither in nor in httpd will become

RE> So when I would do it, I think src/Configure has to perform another DSO sanity
RE> check and determines that "$CC -shared" works the same way as the hard-coded
RE> "ld ..." call we should use it. Else we get into trouble, I think.

`ld -Bshareable' will NOT produce the same result as `gcc -shared'.
`ld -Bshareable' produce static binaries while `gcc -shared' will produce
dynamic binaries... At least with GLibC 2.1 ...

RE> But it has nothing to do directly with apxs, I think. It's just a matter of
RE> src/Configure to provide the correct (or more correct) values, isn't it?

No. apxs should be modified as well. You can specify -Wl,<option> to apxs.
If you are using `gcc -shared' you should keep -Wl there ... With this exception
all other things are just src/Configure modifications...

View raw message