Due to a hard coded compiler name it is not possible to create shared libs on PA-Risc 64 Bit. (gcc does not support 64bit on this platform anyway)
Created attachment 5696 [details] configure.in patch for samba 3.4.x
Created attachment 5697 [details] configure.in patch for samba 3.5.x
Created attachment 5698 [details] configure.in patch for master
Did you set CC to use a certain compiler which is not the cc found in the search path or what is your current szenario? I agree that the LD="cc" is probably bad but I want to understand your bug first :-) About the hook which sets SHLD to "cc" in the $GCC case - I think hard coding that in this case is not the best option. Are all versions of gcc broken? Just for 64bit and not for 32bit? Or ist just the linker used by gcc a problem?
1) The way to compile 64Bit executables on HP-UX is: CC="cc +DA2.0w" configure .... 2) In the gcc case: The shared library flags provided are specific for the cc. The patch does not change this code path in any way. Changing SHLD to gcc would break gcc builds.
why don't you put the CFLAGS into $CFLAGS ? Does that not work for you?
this would not help, because CFLAGS will neither be propagated to the shared lib creation. A solution using CFLAGS would brake the gcc build, btw.
Created attachment 5700 [details] proposed patch but you said gcc doesn't support 64bit on that platform - then the cflags way to make a 64bit build will not matter, too or did I miss a point? To see how it should work take a look at the Solaris section in configure.in. We have so set the linker flags depending on which Does the attached patch work for you?
This proposed patch will brake gcc builds. It supplies gcc with option -b , which is HPUX cc compiler specific. (for gcc it should read -shared). But why fixing something which is not broken? Further Comment: Appending CFLAGS to LDSHFLAGS is not necessary since the default definition of SHLD is "\${CC} \${CFLAGS}" Please apply my proposed patch, it will not brake other things.
the current hpux stuff is definetely broken but your fix is not the way it should be even if it may fix your compiler/linker/architecture combination. Can you arrange a remote login to such a hp-ux machine with native and gnu compiler?
(In reply to comment #10) > the current hpux stuff is definetely broken but your fix is not the way it > should be even if it may fix your compiler/linker/architecture combination. So please tell us how to fix it. Your patches are broken, too. IMHO these scenaries are eagerly needed: Samba should support the native compile 32Bit and 64Bit on HP-UX both PA-Risc and Itanium. For the one without an compiler an option should exist to compile it with a freely available gcc (since it is not very easy to bootstrap a gcc on HPUX). AFAIK these scenarios do work ... But there an outstanding issue (with pread) to be reported (we talked already about it). > Can > you arrange a remote login to such a hp-ux machine with native and gnu > compiler? > Maybe, lets switch to private communications now.
I sent you a patch for testing some time ago but didn't hear back from you about it. In the mean time there have been a number of fixes been done in master. Unfortunately there is no IA64 HP-UX build farm machine to see the results of the s3 master changes. It would be great if you could test the latest master build on your IA64 box now and if you see problems paste the complete config.log.
hpisgr8 in the build farm looks nice so I expect it to be fixed. All the changes that have been made will be in the upcoming 3.6 release.
*** Bug 7732 has been marked as a duplicate of this bug. ***